From aanantha at riverbed.com Fri Jan 8 10:17:50 2010 From: aanantha at riverbed.com (Ahilan Anantha) Date: Thu, 7 Jan 2010 18:17:50 -0800 Subject: [PATCH] detect and kill stuck connections to clients/server Message-ID: <4B4695CE.6020207@riverbed.com> Hi folks, I hacked in OpenSSH style "Server Alive" and "Client Alive" messages into dropbear. In OpenSSH, the ServerAliveInterval and ServerAliveCountMax options cause the client to send "global requests" to the server with the name "keepalive at openssh.org" with the flag "want reply" set to 1. When an SSH server sees the message they fail to recognize it and issue a "failure" response to the client. It appears the OpenSSH people purposely used a request name nobody else would use to guarantee that the server does nothing except send back an error. If the client does not receive ServerAliveCountMax consecutive responses to its requests, it disconnects. The default value of ServerAliveCountMax is 3. The interval at which the client sends requests is controlled by ServerAliveInterval. But its default value is 0 which disables the feature. So it's a heart beat. It lets the client know to disconnect if the server disappears off the network. "Client alive" works the same way. There's a ClientAliveCountMax and ClientAliveInterval. And in this case the client responds to the keepalive at openssh.org requests. In dropbear, however, the "global requests" only get serviced when ENABLE_SVR_REMOTETCPFWD is defined in because the only global requests supported are for tcp forwarding. And the client doesn't service any global requests. So an OpenSSH client can use server alives against a Dropbear server if remote TCP forwarding is compiled in. But an OpenSSH server sending client alives would very quickly disconnect a Dropbear client. I patched dropbear and dbclient to always respond to global requests, but only handle the "tcpip-forward" and "cancel-tcpip-forward" messages when it's enabled. And like OpenSSH it sends failure for the "ping at dropbear" requests for consistency with any other SSH server that doesn't know what these requests are. To turn on server/client alives, you pass the "-A" option to dbclient/dropbear. That sets the interval. But to change the number of responses that can be missed, you have to do that via the options.h file. I ran out of letters in the alphabet to choose from. I tried to avoid reorganizing the code. Which means the changes aren't as clean as they should be. And it's not well tested so beware. Ahilan -------------- next part -------------- A non-text attachment was scrubbed... Name: dropbear-0.52-serveralives.patch Type: text/x-patch Size: 23309 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20100107/3379575a/attachment.bin From denisesballs at thecybersource.com Wed Mar 10 23:35:06 2010 From: denisesballs at thecybersource.com (Jesse Jarzynka) Date: Wed, 10 Mar 2010 10:35:06 -0500 Subject: SSH not disconnecting for non-root user Message-ID: <4B97BC2A.4050607@thecybersource.com> Hello all, First post, but hoping maybe you guys can help. I'm sure you know VMware ESXi server uses dropbear as an SSH server. I'm having an issue where any non-root user I create on the system is not disconnecting properly. If I ssh in as the root user, and type "exit" or scp a file, it completes fine. If I ssh in as the non-root user I create, and type "exit" or scp a file, it just hangs there forever after completing. This is a problem because I'm making a script to scp a file off the server regularly as the non-root user and it's just hanging after completing. Another odd thing is that if I use the SSH shortcut "~." it does exit cleanly. Not sure if maybe something is trying to run on exit? The non-root user has write access to it's home directory and everything so I'm not sure where to look. Any ideas? Here is the line in /etc/inetd.conf that starts the daemon: ssh stream tcp nowait root /sbin/dropbearmulti dropbear ++min=0,swap,group=shell -i -K60 Thanks, Jesse From ianw at vmware.com Thu Mar 11 04:05:54 2010 From: ianw at vmware.com (Ian Wienand) Date: Wed, 10 Mar 2010 12:05:54 -0800 Subject: SSH not disconnecting for non-root user In-Reply-To: <4B97BC2A.4050607@thecybersource.com> References: <4B97BC2A.4050607@thecybersource.com> Message-ID: <4B97FBA2.2070600@vmware.com> Hi, This list isn't a good place to ask VMware questions. In general, on ESXi ssh login is not supported. non-root ssh login is even more not supported :) Drop me a private mail with what version you're using and some more details about where you're copying to, I'll take a quick look -i Jesse Jarzynka wrote: > Hello all, > > First post, but hoping maybe you guys can help. I'm sure you know VMware > ESXi server uses dropbear as an SSH server. I'm having an issue where > any non-root user I create on the system is not disconnecting properly. > If I ssh in as the root user, and type "exit" or scp a file, it > completes fine. If I ssh in as the non-root user I create, and type > "exit" or scp a file, it just hangs there forever after completing. This > is a problem because I'm making a script to scp a file off the server > regularly as the non-root user and it's just hanging after completing. > Another odd thing is that if I use the SSH shortcut "~." it does exit > cleanly. Not sure if maybe something is trying to run on exit? The > non-root user has write access to it's home directory and everything so > I'm not sure where to look. Any ideas? Here is the line in > /etc/inetd.conf that starts the daemon: > > ssh stream tcp nowait root /sbin/dropbearmulti > dropbear ++min=0,swap,group=shell -i -K60 > > Thanks, Jesse From blubkin at vmware.com Tue Mar 23 15:16:47 2010 From: blubkin at vmware.com (Bela Lubkin) Date: Tue, 23 Mar 2010 07:16:47 +0000 (UTC) Subject: SSH not disconnecting for non-root user References: <4B97BC2A.4050607@thecybersource.com> Message-ID: Jesse Jarzynka wrote: > First post, but hoping maybe you guys can help. I'm sure you know VMware > ESXi server uses dropbear as an SSH server. I'm having an issue where > any non-root user I create on the system is not disconnecting properly. > If I ssh in as the root user, and type "exit" or scp a file, it > completes fine. If I ssh in as the non-root user I create, and type > "exit" or scp a file, it just hangs there forever after completing. This > is a problem because I'm making a script to scp a file off the server > regularly as the non-root user and it's just hanging after completing. Jesse, I have a theory, but it depends on your being wrong about what happens when you manually ssh in and run something. It would only apply to remotely invoked commands, i.e. `ssh host ls`. Any chance you got mixed up? The theory has to do with a possible race condition. It also has a second huge hole, which is that I can't explain why it would act differently for root vs. not-root. Still... It's trivial to test. Instead of doing `ssh host ls`, try `ssh host 'ls; sleep 1'`. If I'm right, that should terminate cleanly for both users. If you can, conduct this experiment and show me what happens. Besides allowing a fix at our end, this would also give you a crude but workable workaround. > Another odd thing is that if I use the SSH shortcut "~." it does exit > cleanly. Not sure if maybe something is trying to run on exit? The > non-root user has write access to it's home directory and everything so > I'm not sure where to look. "~." is a command to your local ssh client. If it's determined to exit, it will succeed in doing so. The trouble with your remote command exit is that the server end is never telling the ssh client (on your end) that the connection is done. It has no reason to exit; it has no intelligence to determine that a remote `ls` or `exit` should end more quickly than `sleep 10000`. >Bela< From blubkin at vmware.com Tue Mar 23 19:01:00 2010 From: blubkin at vmware.com (Bela Lubkin) Date: Tue, 23 Mar 2010 11:01:00 +0000 (UTC) Subject: SSH not disconnecting for non-root user References: <4B97BC2A.4050607@thecybersource.com> Message-ID: I wrote: > It's trivial to test. Instead of doing `ssh host ls`, try > `ssh host 'ls; sleep 1'`. If I'm right, that should terminate > cleanly for both users. Managed to test this myself, no help. I can see in the traces that only the root case reaches "enter sigchld handler". So far no sensible theory about why. >Bela< From denisesballs at thecybersource.com Tue Mar 23 21:19:10 2010 From: denisesballs at thecybersource.com (Jesse Jarzynka) Date: Tue, 23 Mar 2010 09:19:10 -0400 Subject: SSH not disconnecting for non-root user In-Reply-To: References: <4B97BC2A.4050607@thecybersource.com> Message-ID: <4BA8BFCE.5040409@thecybersource.com> Ok, thanks for the check Bela. You might want to check with Ian Wienand on this list who is also @vmware. He e-mailed me privately with what he thought the problem was. On 03/23/2010 07:01 AM, Bela Lubkin wrote: > I wrote: > > >> It's trivial to test. Instead of doing `ssh host ls`, try >> `ssh host 'ls; sleep 1'`. If I'm right, that should terminate >> cleanly for both users. >> > Managed to test this myself, no help. I can see in the > traces that only the root case reaches "enter sigchld handler". > So far no sensible theory about why. > > >> Bela< >> > From bunk at stusta.de Wed Mar 24 23:06:25 2010 From: bunk at stusta.de (Adrian Bunk) Date: Wed, 24 Mar 2010 17:06:25 +0200 Subject: [dropbear patch] update the xauth path Message-ID: <20100324150625.GA12664@localhost.pp.htv.fi> Since /usr/X11R6 might not even even anymore as a symlink it is better to assume the default location for xauth is in /usr/bin/ --- options.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/options.h b/options.h index def8ccb..e271839 100644 --- a/options.h +++ b/options.h @@ -220,7 +220,7 @@ etc) slower (perhaps by 50%). Recommended for most small systems. */ /* The command to invoke for xauth when using X11 forwarding. * "-q" for quiet */ #ifndef XAUTH_COMMAND -#define XAUTH_COMMAND "/usr/X11R6/bin/xauth -q" +#define XAUTH_COMMAND "/usr/bin/xauth -q" #endif /* if you want to enable running an sftp server (such as the one included with -- 1.5.6.1