ProxyCommand and sshd -i : Some Further Analysis

[Dan Kaminsky]

    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 :-)