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?

HTH

Notes:
-----


<http://www.openssh.org/security.html>

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

Points to:
<http://www.kb.cert.org/vuls/id/684820> 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.
<http://www.openbsd.org/security.html>

This 2006 Ubuntu bug on the question points to a useful paper on
High-performance SSH:
<https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/54180>

<http://www.psc.edu/networking/projects/hpn-ssh/none.php>




More information about the linux mailing list