recent breakins

Tom Holroyd tomh at
Fri Jun 1 12:24:49 EST 2001


"The ssh client at SourceForge had been compromised to log outgoing names
and passwords, so the cracker was thus able get a shell on"

user's ssh --> SF's ssh -->'s sshd

So basically the user's password was entered in the clear to an untrusted
program (SF's ssh).  Never mind that the links were encrypted, the ssh
program on SF needed to know the user's password on, in the
clear.  Obviously, the user could have / should have run ssh locally to
connect directly to  But that's not the ideal solution.  The
ideal solution requires that passwords should never, ever, be allowed to
exist in the clear anywhere but on the user's local machine.  This is
doable now, over a single link, with SRP.

But what about multiple links?  It should be possible to forward
authentication requests back to the user's keyboard.  The SRP protocol can
be forwarded over any number of links, *even through a trojaned ssh*
without revealing any information that a cracker can use.

What mechanisms exist within ssh/sshd that would allow a remote sshd to
establish an authentication protocol conversation with a local ssh,
possibly over several links?  Remember that the goal is that the user's
password should never appear in the clear on any computer other than the
user's own.  Is this something that needs to be added to the agent?  Or
can it be done directly within ssh?

More information about the openssh-unix-dev mailing list