Re: Explanation of SSH
From: Richard E. Silverman (res_at_qoxp.net)
Date: 06/26/04
- Previous message: all mail refused: "Re: Redirect 127.0.0.1 to host IP?"
- In reply to: Bill Unruh: "Re: Explanation of SSH"
- Next in thread: oscar_at_jbexNOSPAM.com: "Re: Explanation of SSH"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 26 Jun 2004 16:12:51 -0400
> ]Please either point me to a web page; or enable my understanding of
> ]the following; or even both.
http://www.snailbook.com/protocols.html
> ]Steps in SSH connection setup;
> ]1. Client issues SSH command and names server
> ]2. "Shopper" says "server sends back its public host and server keys
> ]to client". You what? Surely there is only one public key it sends
> ]back, and "host and server keys" means just one public key?
>
> Usually.
No, this is wrong. First, be aware that there are two major versions of
the SSH protocol, 1 and 2. It sounds as if the description you read is of
SSH-1, which is unfortunate because SSH-1 is long since deprecated and
falling out of use (albeit slowly). In SSH-1, the "host key" is the
long-term asymmetric keypair used to identify an SSH server, while the
"server key" is an ephemeral keypair -- typically replaced once per hour
by the server, never stored anywhere, and used to provide forward secrecy
for the symmetric keying material.
> ]3. Client adds server key(s?) to its knownhosts file if it isn't there
> ]already.
It's important to distinguish between how SSH (the protocol) works, and
the details of particular implementations. The protocol says nothing
about "known-host files," or even how to store keys on disk. An SSH
client should verify that the host key it receives corresponds to the
machine the user intended to contact. One simple way is to have a file of
name/key associations: the known-hosts file. If the key at hand is
missing, an SSH client may give the user the option of adding the present
key/name association to the file -- perhaps the key's fingerprint
is available to check, or perhaps the user is willing to incur the risk of
an MITM attack on this connection, given the circumstances.
The known-hosts mechanism is simple, but clumsy and unscalable. In
environments where more infrastructure is available, SSH can fall back on
existing services for host (and user) authentication/authorization:
e.g. Kerberos or an X.509 PKI.
> ]4. Shopper says, "Client generates 256 bit random number which it
> ]encrypts using server and client public keys." What is the 256 bit
> ]random number? Is this the client's private key?
No; you're confusing two separate phases of the SSH protocol. The
description is still talking about setup of the secure channel, in which
only the host is authenticated. If the client has an asymmetric keypair,
it's for user authentication, which hasn't happened yet -- and it may not
have such a key, if for instance it uses password authentication rather
than publickey.
The "256-bit key" is the shared secret for securing communication on this
SSH connection.
Also, again, this description is of SSH-1; SSH-2 is modular with respect
to this part of the protocol (the "key exchange" portion of SSH-TRANS), so
different things might happen -- and even the most common exchange method
in SSH-2 is more sophisticated and secure than this.
-- Richard Silverman res@qoxp.net
- Previous message: all mail refused: "Re: Redirect 127.0.0.1 to host IP?"
- In reply to: Bill Unruh: "Re: Explanation of SSH"
- Next in thread: oscar_at_jbexNOSPAM.com: "Re: Explanation of SSH"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
