scp -S, sftp -S (was: Re: port forwarding trouble)

[Frederik Eaton]

On Wed, Aug 03, 2005 at 01:13:30AM +0200, Peter Stuge wrote:
> On Tue, Aug 02, 2005 at 05:39:59PM +0100, Frederik Eaton wrote:
> > > As Peter Stuge noted earlier, you can use HostKeyAlias to specify
> > > the real name of the host you're connecting to over the forward.
> > 
> > So, I could just write a wrapper that always passes "-o
> > HostKeyAlias=host:port" to ssh to get around the bug?
> 
> That, or add the following to ~/.ssh/config or /etc/ssh/ssh_config
> 
> Host tunnelhost
>   HostKeyAlias real.host.name
>   HostName localhost
>   Port 2222
> 
> And then connect to it using:
> 
> ssh tunnelhost
> 
> Repeat for as many tunnelhosts as you want, just change Host,
> HostKeyAlias and Port for each.

OK. The reason I'm doing this is that I'm finally getting around to
writing an ssh wrapper which fixes all of the gripes I have with ssh.
(Well, to be precise I wrote one earlier in zsh and now I'm writing a
better, cleaner version in Haskell.) So always specifying a -o
HostKeyAlias=X option on the command line is something I can do
automatically.

Now, as I'm investigating interactions with various programs, I've run
into a problem: the -S option to sftp and scp lets you give the name
of an executable to use instead of ssh, but doesn't let you specify
arguments to pass to that executable (as does rsync's -e option).

Furthermore, if scp executes another scp instance remotely, then it
does not propagate its own -S value to the remote instance - it seems
to me that it should at least be possible to configure scp to do this,
even if it isn't the default.

I am willing to fix both of these problems in openssh, and update the
documentation, if people think it would be a good idea.

Frederik

P.S. The features of my ssh wrapper:

(a) Separation of command arguments is preserved. 

$ ssh localhost sh -c "echo hi"

$ fssh localhost sh -c "echo hi"
hi

(b) Ports can be specified in the host name (with "=" or ":"), and a
string of hosts can be specified by joining them with "+". This is
quite useful for logging onto hosts which live behind a firewall.
(Below, the ofb.net admins didn't want to make the forwarded port
externally accessible)

$ fssh ofb.net+localhost:42224 hostname
taisa
$ fssh ofb.net+localhost:42224 sh -c "echo hi"
hi

(c) Host aliases can be defined with a script ~/.host_alias:

$ ~/.host_alias taisa
ofb.net+localhost:42224
$ fssh taisa sh -c "echo hi" 
hi

My version of the .host_alias script produces different results
depending on current network location, so that as I move my laptop
around I can use the same names to refer to the same hosts, without
sacrificing efficiency in the cases when I am on the same subnet as
those hosts by using the appropriate shortcuts when possible.

(d) The mapping from hosts to host keys takes port number into
account. For instance, the previous command invokes 'ssh' as:

ssh -o 'HostKeyAlias=ofb.net' ofb.net -- "ssh -o 'HostKeyAlias=localhost:42224' -p 42224 localhost -- \"sh -c 'echo hi'\""

...

All of this makes it possible for me to use things like cvs and rsync
rather transparently across tunnels and firewalls just by configuring
the appropriate environment variables (CVS_RSH, RSYNC_RSH). However,
as noted above, there are still some wrinkles that I would like to
smooth out.