Hi, Using OpenSSH 2.9p2 (2.5.2 was also bad), I've noticed data loss on Linux when: 1) ssh -n flag is used, and 2) ssh jobs are run from cron (effectively causing the same as above). What is done, is a command basically like: ssh [-n] -c blowfish -p 722 -i rsakey -l pwget passwdserver passwd > passwd.tmp 2> /tmp/log ie, retrieve dynamically created passwd-file from passwdserver using rsa keys. The server is SSH 1.2.25 or the like (yeah, I know it's broken, but can't be changed at the moment). The diff of ssh -v -v -v is: --- log Fri Jul 20 13:18:42 2001 +++ log.cron Fri Jul 20 13:02:01 2001 @@ -41,13 +41,12 @@ debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 -debug1: Requesting X11 forwarding with authentication spoofing. -debug1: Remote: X11 forwarding disabled in server configuration file. -Warning: Remote host denied X11 forwarding. debug1: Sending command: passwd debug1: Entering interactive session. +debug1: fd 0 setting O_NONBLOCK debug1: fd 1 setting O_NONBLOCK debug1: fd 2 setting O_NONBLOCK -debug1: Transferred: stdin 0, stdout 155303, stderr 0 bytes in 1.6 seconds -debug1: Bytes per second: stdin 0.0, stdout 95576.3, stderr 0.0 +debug1: Sending eof. +debug1: Transferred: stdin 0, stdout 155303, stderr 0 bytes in 1.5 seconds +debug1: Bytes per second: stdin 0.0, stdout 100654.4, stderr 0.0 debug1: Exit status 0 When run from cron, or with -n, you get "Sending eof." which truncates the data. Any ideas? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
> The server is SSH 1.2.25 or the like (yeah, I know it's broken, but can't > be changed at the moment).Wellllll...there's this cute little trick that works because of SSHD's blissful lack of root dependancy: ssh -o 'ProxyCommand ssh user at host openssh/sshd -i' user at host Two conclusions to reach from this trick: 1) I have way too much fun with ProxyCommand 2) Unless you give a user a *really* restricted shell, sshd_config will *never* be the right place to put your security constraints. As for the larger issues...does the incorrect buffering behavior still manifest itself without the -n? In SSH1 and SSH2? With and without TTY? Yours Truly, Dan Kaminsky, CISSP www.doxpara.com
the data get's truncated? who's sending EOF? the client? so $ ssh -n host cat file > file2 fails on linux? every time? On Fri, Jul 20, 2001 at 01:22:24PM +0300, Pekka Savola wrote:> Hi, > > Using OpenSSH 2.9p2 (2.5.2 was also bad), I've noticed data loss on > Linux when: > 1) ssh -n flag is used, and > 2) ssh jobs are run from cron (effectively causing the same as above). > > What is done, is a command basically like: > > ssh [-n] -c blowfish -p 722 -i rsakey -l pwget passwdserver passwd > passwd.tmp 2> /tmp/log > > ie, retrieve dynamically created passwd-file from passwdserver using rsa > keys. > > The server is SSH 1.2.25 or the like (yeah, I know it's broken, but can't > be changed at the moment). > > The diff of ssh -v -v -v is: > > --- log Fri Jul 20 13:18:42 2001 > +++ log.cron Fri Jul 20 13:02:01 2001 > @@ -41,13 +41,12 @@ > debug3: clear hostkey 0 > debug3: clear hostkey 1 > debug3: clear hostkey 2 > -debug1: Requesting X11 forwarding with authentication spoofing. > -debug1: Remote: X11 forwarding disabled in server configuration file. > -Warning: Remote host denied X11 forwarding. > debug1: Sending command: passwd > debug1: Entering interactive session. > +debug1: fd 0 setting O_NONBLOCK > debug1: fd 1 setting O_NONBLOCK > debug1: fd 2 setting O_NONBLOCK > -debug1: Transferred: stdin 0, stdout 155303, stderr 0 bytes in 1.6 seconds > -debug1: Bytes per second: stdin 0.0, stdout 95576.3, stderr 0.0 > +debug1: Sending eof. > +debug1: Transferred: stdin 0, stdout 155303, stderr 0 bytes in 1.5 seconds > +debug1: Bytes per second: stdin 0.0, stdout 100654.4, stderr 0.0 > debug1: Exit status 0 > > When run from cron, or with -n, you get "Sending eof." which truncates the > data. > > Any ideas? > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > >
More Fun With SSH's Generic Functionality Encapsulation:
Did some work playing around w/ ProxyCommand and inetd mode. The
command line syntax is a bit hairier, something along the lines of:
ssh -o 'ProxyCommand ssh user at host "cd /home/user/openssh; \
sshd -f sshd_config -h newkey -i"' \
ssh user at host-newkey
Some notes:
1) You *have* to generate a new ssh key for the sshd to use, as a normal
user shouldn't ever be able to read the host key. "ssh-keygen -f
newkey"
works nicely--server host keys and user identities are essentially
identical. On the flip side, the client has to be told it's connecting to
another host-id. Security is still maintained by the ProxyCommand hostkey
check, though, and the new key will be stored and checked for in the future.
2) Specify the new SSH key when executing the userspace sshd. The -h
option to sshd lets you do this.
3) You *may* have to specifically provide an sshd_config if one cannot
be found; I haven't checked. The -f option to sshd lets you do this.
4) Remember that paths and variables are (rightfully) very tightly set
when doing remote command execution--so you've gotta provide an absolute
path to the ssh daemon. $HOME won't work, neither will ~. But if you
directly execute /home/user/openssh/sshd, you'll *also* need to give the
full path for the sshd_config and the newkey. An alternative is found by
cd'ing to the directory of your choice and then executing your commands from
there. This works surprisingly well--you don't even need to do annoying
things like ./sshd, even though ./ doesn't appear in the default path. I
haven't tested this across many platforms, however, and ./ is almost
guaranteed to actually work.
5) Yes, you can specify multiple commands in a row and separate them
with a semicolon; just be sure to quote the entire mess so it hits the
remote shell invocation rather than your local shell. Among other things,
this is nice for things like:
tar cf - | ssh user at host "cd /path/to/untar/to; tar xf -"
6) Just for reference, "inetd mode" just causes sshd to run over
stdin/stdout. Conveniently, ssh works quite well for doing 8 bit clean
forwards of stdio, and ProxyCommand requires nothing more than an 8 bit
clean forward.
7) If your platform lacks /dev/random *and* a decent deployed build of
openssh, you're going to have problems with finding /etc/ssh_prng_cmds.
I'll fix this "soon".
8) I don't think passwords are going to work too well in the userspace
sshd. I'll do some work in this regard--probably we can specify a drop down
to /bin/login in this context, definitely SRP will work fine--but if you're
doing craziness at this level, the least you can do is set up some public
keys. :-)
9) Unlike some other hacks I'm working on, I don't think this is a
good
candidate for any kind of syntax cleanup. You're effectively saying
"route
this ssh connection through an sshd executed on the remote side, and tell it
to use this key and that config file, oh and this is where to find that ssh
daemon." To be blunt, there's *so* little to make default that the
full
syntax is probably more concise than any alternative. Plus this is really
more of a neat hack than something that's going to see heavy usage.
I've *really* got quite a bit of SSH writing to do this weekend;
I'll
try to document and develop this hack a bit further. Bug me w/ requests or
comments if you like.
Yours Truly,
Dan Kaminsky, CISSP
http://www.doxpara.com
P.S. Extreme SSH = Fun :-)