Openssh for Windows

Jim Knoble jmknoble at pobox.com
Thu Jul 31 05:25:04 EST 2008


Circa 2008-07-30 04:58 dixit Corinna Vinschen:

: On Jul 29 14:00, Jim Knoble wrote:
: > Circa 2008-07-29 06:08 dixit Corinna Vinschen:
: > : [...] But I'm still feeling rather uncomfortable with the idea to
: > : have two-way encrypted password stored somewhere in the system.
: > 
: > You could encrypt the user's password using the user's SSH public key.
: > Then the private key could be used to both authenticate and decrypt the
: > password.  It's a bit cumbersome if there are more than a few keypairs
: > used to access the account, but ... just a thought.
: 
: That's an interesting idea but the problem is that the user context
: change is generic code buried within the seteuid call.  It has to work
: with all sorts of applications changing the user context, not just with
: sshd.  Therefore, a generic solution is required.

Hmm.  That definitely sounds more complex than one would want it to be.
The generic solution really sounds like Kerberos.

: I'm not overly encryption savvy.  Is it at all possible to store a
: two-way encrypted password in a safe way, using a known encryption
: mechanism, storing it in a known location?  Even if another key is
: used on every machine?

It depends on what risks are acceptable to you.  Unless the user enters
the encryption key itself or a passphrase for the key, then the
encryption key must be stored in what is effectively plaintext, either
in permanent (disk) or volatile (RAM) storage.  Thus, an attacker who
gains sufficiently privileged access to disk or RAM (e.g., through a
rootkit) would effectively gain access to the plaintext password as
well.

That's why i suggested using the SSH private key, as it can be made to
depend on a private passphrase stored separately from the encrypted
password.  Darren Tucker's response that sshd doesn't really know the
private key makes that more difficult; sshd would have to ask the client
to decrypt the encrypted password and send the plaintext password back
to the server.  That sounds overly complex.

To make it simpler, the server could ask the user for the encryption key
or a passphrase for the encryption key, as part of a two-step
authentication method.  But that's effectively the same as just asking
the user for the actual password, which is what happens now with the
"net use" command....

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: C6F31FFA  >>>>>>  http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+


More information about the openssh-unix-dev mailing list