security of SSH1 and SSH2 protocols

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
SSH2 uses diffie-helman key exchange to determine a symmetric key.
public key encryption (RSA or DSS) is used to verify the server
signature.  the server host public key is transmitted along with the
server signature which has been encrypted with the server host private
key.  if the server host public key matches what you have on file and
successfully decrypts to the server signature, you have a match.

SSH1 does it a bit differently.  in SSH1, the symmetric key is soley
generated by the client.  in SSH2, in contrast, neither side soley
generates the key - it's mutually arrived at after both sides generate
their own secret primes.

the SSH1 server sends its host public key (that the client is supposed
to cache) and another public key that's regenerated every hour by the
server.  the client receives these and encrypts the symmetric key with
both of these public keys.

my questions are as follows:

1. what about what SSH1 does is insecure?  wouldn't SSH1 be just as
secure if the regenerating public key wasn't sent?  an eavesdropper
still couldn't decrypt the symmetric key at that point and if the
client didn't check the host public key against its cache the
regenerating public key wouldn't offer any additional security as that
could be set to a value of the attackers chosing.  in this regard, it
and SSH2, with its use of diffie hellman key exchange, are about as
secure as one another.

so my question remains - what about SSH1 is insecure?

2. is signature verification necessary in SSH2 if public key
authentication is used?  you use signature verification to verify that
the server is the real one as only the real one would be able to sign
the signature of the message such that the cached public key could
decrypt.  if you use public key authentication, however, presumably,
only the server you're talking to will have your private key.  someone
spoofing the server, presumably, wouldn't have your private key,
themselves, and as such, they couldn't decrypt what you were sending
out.  in that way, the identity of the destination server could be

so my question remains - is signature verification necessary in SSH2
if public key authentication is used?

Re: security of SSH1 and SSH2 protocols

Quoted text here. Click to load it

The big security problems with SSH-1 are not in the key exchange
mechanism; they're elsewhere, such as the lack of a proper MAC in
the binary packet protocol and the sending of exact packet lengths
in cleartext.

There are minor issues with the SSH-1 key exchange mechanism, such
as the fact that key exchanges aren't completely independent (if an
attacker is able to factor the keys for one key exchange, they will
also be able to decrypt any other session started within the same
server-key lifetime), but it's not _too_ bad. RFC 4432 proposes an
SSH-1-like (i.e. RSA-based) key exchange method as an optional
component of SSH-2, since it has the practical advantage of doing
most of the computational work on the server (as opposed to Diffie-
Hellman which distributes the key exchange work equally between
parties) and hence is suitable for slow client machines such as
mobile devices.

I'd say the biggest advantage of SSH-2's approach is the
_decoupling_ of the server authentication step from the key exchange
step, meaning that one can be replaced without having to redesign
the other. If a fatal flaw were to be found in RSA, SSH-1 would be
completely hosed, but SSH-2 would just switch to a different host
key algorithm and the confidentiality of even previously recorded
sessions would be unimpaired. (The RFC 4432 method does not break
this decoupling, so it's still better than SSH-1's approach.)

Quoted text here. Click to load it

Not correct. Authentication in SSH-2 (both from server to client and
vice versa) is done by sending signatures, which don't affect the
encryption of the session. Somebody spoofing the server (in the
absence of host key verification) would have no trouble decrypting
your data, since all they'd need for that would be the
Diffie-Hellman exchange. They'd just receive a signature as part of
the encrypted data stream, and could simply pretend to have accepted
it and continue the session (assuming they could credibly invent
some subsequent server responses that looked like what you were

The public-key authentication in SSH-2 is a signature on some data
including the session key, which means that somebody doing a MITM
attack between you and the server could not reuse the signature you
sent to them to actually gain access to your account on the server.
In _that_ sense, public-key authentication reduces the need for
server authentication: with PK auth, you need not worry that logging
in to an unauthenticated server will let a MITM attacker in to the
real one, which is a worry you would have with password auth.
However, you do still have to worry that any data you type into the
subsequent session might be recorded in clear by the attacker, so if
you planned to type anything confidential _into_ your session (e.g.
passwords to log in to systems beyond that, or actual private
correspondence etc) you should still make sure to have checked the
host key first.
Simon Tatham         What do we want?        ROT13!

Re: security of SSH1 and SSH2 protocols

Quoted text here. Click to load it

Ah - ok.  I haven't actually read the public key authentication part
of the SSH specs and was just making an assumption on how it worked -
guess I was wrong, heh.

Anyway, thanks!

Site Timeline