[ale] Re: SSH

[Joe Knapka]

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.