[ale] Re: SSH

[Joe Knapka]

Sorry to reply to myself, but further investigation reveals that
I still do not fully understand how all this works. I cannot
seem to get the OpenSSH sshd to honor the authentication methods
I have configured for it to use. Also, what I said below about
the "RhostsRSAAuthentication" method is mostly wrong; it in fact
uses the client host's RSA key, not the user's. "RSAAuthentication"
uses the user key. The manner in which these various methods
interact is rather mysterious to me at the moment.

Sorry for the confusion,

-- Joe

Joe Knapka wrote:
> 
> What follows is my understanding of the SSH authentication process.
> I'm not a security expert, and I could be wrong, so I've CC'd this
> to ALE in case someone has corrections to make. Most of this
> is gleaned from various security FAQs and Bruce Schneier's "Applied
> Cryptography."
> 
> Chuck Huber wrote:
> >
> >
> > -----Original Message-----
> > From: Chuck Huber
> > Sent: Thursday, December 30, 1999 09:26
> > To: Chris Fowler; ', jknapka at charter.net'
> > Subject: SSH
> >
> > > From: Joe Knapka [mailto:jknapka at charter.net]
> > >
> > > > From: Chuck Huber
> > > >
> > > > > From: someone else
> > > > > ssh-keygen generates both public and private RSA keys. As I
> > > > > understand it, the client and server exchange RSA public keys,
> > > > > and use RSA to authenticate one another and agree on a secret
> > > > > session key.
> > > >
> > > > Pretty close.  I don't see a need for the client to have a
> > > > public key.
> > >
> > > Because the public keys are also used for mutual authentication.
> > > The host may allow connection only from certain trusted clients,
> > > identified by their public keys.
> > >
> > > Server: "Here's a random string I encrypted with your public key. Can
> > > you decrypt it?"
> > > Client: "Yes, here it is." Decrypts the string using its private key
> > > and sends it back to the server.
> > > Server: "Ah, then you must know your private key, which means you
> > > are who I think you are."
> >
> > This is interresting.  I don't ever recall generating a key pair on the
> > client.
> 
> You are (mostly) right, and I was somewhat wrong. Server authentication
> is performed via RSA host keys (and the corresponding public keys are
> saved in $(HOME)/.ssh/known_hosts on the client the first time a
> particular
> server is accessed - if the host key changes subsequently, ssh attempts
> will
> generate a warning to that effect). On the other hand, client
> authentication
> is done using either traditional hosts.equiv authentication, RSA
> authentication of the -user- (not the client machine), or both.
> 
> So you can configure sshd to accept connections only from specific
> machines, using /etc/hosts.equiv, but that is not secure, since is
> is easy to impersonate another machine.
> 
> Alternatively, you can make sshd demand a public key from the client,
> and conduct the conversation outlined above (or something similar).
> That public key will be the -user's- public key. If the client has
> the corresponding private key, it will be allowed to continue the login
> process. So in itself, this isn't particularly secure either, since
> anyone can generate a valid key pair (though of course they still need
> a user id and password on the server).
> 
> However, you can set "PasswordAuthentication" to "no" and
> "RSAAuthentication" to "yes" in /etc/sshd_config, in which case
> -only- users whose public key is known to the server (in the
> $(HOME)/.ssh/authorized_keys file of the user who is attempting
> to log in) will be allowed to log in. However, they are not, in this
> case, required to provide a password. As far as I can tell, there is
> no way to both require the user's public key to be known AND require
> the user to know his own password, which is not good, IMO. (Though
> possibly the server will demand the ssh-keygen passphrase when using RSA
> authentication - I've never tried it with a non-empty passphrase.)
> 
> In OpenSSH (but not the publically-available SSH 1.x), you can also
> force the client to be authenticated by its RSA -host- key by (a) adding
> the client host public key to the server's /etc/ssh/ssh_known_hosts, and
> (b) setting "IgnoreUserKnownHosts" to "yes" in /etc/sshd_config.
> Combined with /etc/hosts.equiv authentication, this is a pretty reliable
> way to ensure that only known client machines connect to the server.
> hosts.equiv ensures that only specific clients can connect, and
> ssh_known_hosts ensures that they really are who they say.
> 
> > Probably because I haven't configured sshd to restrict connections.
> 
> > I can see where the public key for the server may be obtained by the client
> > at connect time. This key may then be compared against a database local to
> > the client for host authentication.  From the conversation you described
> > above, it would appear that the server would need prior knowledge of the
> > client's public key, perhaps at sshd startup time and refreshed with SIGHUP?
> > If not, then how does the server obtain the client's public key?  The
> > objective here is to determine what configuration item's we'll have to store
> > on the (embedded system) server.  So far, it looks like we'll need a host
> > key pair, and a table of client public keys.
> 
> Yep.
> 
> > Also, is this entire process documented anywhere?  It seems that the man
> > pages have left out the process of authenticating clients.  While this
> > conversation is quite enjoyable, I hate to be bugging others with questions
> > that are already documented elsewhere.
> 
> I got most of this information from the sshd man page, the Schneier book
> (which doesn't discuss SSH particularly, but is a very good source
> for general security information), and the following web pages:
> 
> http://www.sunworld.com/sunworldonline/swol-02-1998/swol-02-security.html
> 
> http://www.rsasecurity.com/rsalabs/faq/sections.html
> 
> Happy New Year!
> 
> -- Joe
> 
> > Thanks,
> >         - Chuck
> 
> -- Joe Knapka
> * What happens when a mysterious force meets an inscrutable object?
> --
> To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.

-- Joe Knapka
* What happens when a mysterious force meets an inscrutable object?
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.