[plug] Novel way to port forward over ssh

[Craig Ringer]

On Tue, 2005-01-04 at 10:50 +0800, Bernard Blackham wrote:
> On Mon, Jan 03, 2005 at 11:59:54PM +0800, Craig Ringer wrote:
> > > And if you were paranoid, you could utilize the command= option on
> > > ssh keys to *only* allow certain commands.
> > 
> > I've actually run into a really weird problem with doing that.
> > Bizarrely, ssh is doing LF->CRLF conversion on the output stream when
> > sending data from a command that was run using 'command=' in
> > authorized_keys. If the command is run as the normal command argument on
> > ssh rather than forced in authorized_keys, the line ending conversion is
> > not done.
> > 
> > The server is running Debian Woody, so I'll be upgrading sshd soon to
> > see if that fixes it.
> 
> That's seriously bizarre. I've been running nightly rsync/ssh
> backups to a woody server running 1:3.4p1-1.woody.3 using this
> method and have never noticed any problems.

Indeed. I was pretty surprised too, but couldn't argue with the results.
I wrote a script to compare a binary transferred using other means to
one transferred using ssh with a key whose authorized_keys entry looks
like:

command="cat thebinary" id-rsa <blah>

and confirmed that the file transferred over ssh has had newlines
converted. It _only_ happens with a forced command ; if I remove the
'command=' entry on the authorized_keys file and specify the same
command on the ssh command line, the problem goes away.

I'll be testing between two totally different machines soon to see if
it's something somehow local to the server (which is woody, previously
potato).

> > I've found other reports of some of the symptoms of this (such as
> > corrupt gzip data) but no reports of it being identified as line ending
> > conversion. Nonetheless, I've been able to confirm that's what's
> > happening ... mighty strange.
> 
> Out of interest, what exact versions are on the client/server sides?

Server:

craig at www:~$ ssh -V
OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3, SSH protocols 1.5/2.0, OpenSSL
0x0090603f

Client:

ssh[craig at bucket craig]$ ssh -V
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f

The client is RH8. I've had a SuSE 9.2 (I'm not sure of the ssh version)
user who has a login and restricted key on the server also report
regular corruption of tar files, which is what first caused me to notice
the problem. There are no other users transferring binary data over ssh
to worry about.

I've also observed it with the ssh client on FC1, which I no longer have
on hand to check the version of.

-- 
Craig Ringer