No subject

Thu Mar 18 17:34:04 MDT 2010

"Use the none cipher only for testing. ['none' only in SSH1, not v2]
Using the SSH-1 protocol with no encryption seriously weakens it:
 not only do you lose data privacy, but also you effectively lose server
authentication and integrity protection.
SSH-2 doesn't suffer from these problems.
In either case, however, password authentication isn't available, since
the password would be sent in the clear."

Their decisions seem validated in the low-number of reported problems
with it... There was the SSH1 key problem and the issue with
Debian/Ubuntu limited to generating 4096 unique server keys.

There is a patch out there for 'cipher-none' for the client.
[The ssh server needs to support 'none', it's part of the standard]

On another note, with SSL, the majority of the work is in setting up the
connection. Doing a Diffe-Helman key-exchange with RSA, if I understand
correctly. SSL then moves into a symmetric (shared-key) cipher that is
relatively quick to compute.

I've no idea if that is actually so in SSH.
There is a clue that startup costs are high with 'connection
multiplexing' features (-M & -O options).

Instead of looking to bypass all the security features in SSH, SSH v2
was rearchitected to allow "sub-systems" to be implemented easily.
This is how SFTP is done.

It seems to me the specific request here is for SSH to do something like
"Kerberized FTP" - a strongly authenticated setup phase, followed by
unencrypted transfers.

=> that would seem to possible with shell scripts using 'netcat' (nc)
and cpio/tar. The trick would be to use SSH to share some randomly
assigned port numbers, or to spawn a single-connection daemon.

IIRC, 'rsync' server supports its own unencrypted protocol.
Anyone used that for this sort of thing?




"OpenSSH was not vulnerable to client forwarding attacks in unencrypted
connections, since unencrypted connection support was removed at OpenSSH
project start."

Points to:
<> which I found offered no insight.

OpenBSD, which OpenSSH is part of, has a primary focus on *security*.
They are antsy about unencrypted connections - especially when they
could be hijacked.

This 2006 Ubuntu bug on the question points to a useful paper on
High-performance SSH:


More information about the linux mailing list