Date: Tue, 19 Sep 2006 16:26:15 -0700 From: Chuck Swiger <cswiger@mac.com> To: Darrin Chandler <dwchandler@stilyagin.com> Cc: questions@freebsd.org Subject: Re: sshd brute force attempts? Message-ID: <8AB47C58-3A82-438C-9482-24655EB46665@mac.com> In-Reply-To: <20060919223808.GF18329@zloy.stilyagin.com> References: <20060919165400.A4380@prime.gushi.org> <20060919212242.97964.qmail@web83102.mail.mud.yahoo.com> <20060919223808.GF18329@zloy.stilyagin.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 19, 2006, at 3:38 PM, Darrin Chandler wrote:
> I think this isn't needed, and is somewhat silly. Like all (decent)
> implementations of pubkey, the key is only used to authenticate and
> exchange a symetric session key. So the pubkey sees little actual use,
> compared with the session key.
>
> Anyone who knows better please correct me.
That's about right. The (typical) 1024-bit RSA or DSA keypair is
only used during the initial authentication stage; the symmetric
authentication negotiated during the initial phase (typically 128-bit
3DES, or now AES128 or AES256) is used for the rest of the connection.
SSHv2 protocol does an initial negotiation to figure out the best
symmetric encryption and message-digest algorithm that both sides
support (SSH2_MSG_KEXINIT), they then perform a Diffie-Helman group
exchange (see RFC-4419, describing the SSH2_MSG_KEX_DH_GEX_REQUEST
stage) to negotiate a shared secret which is signed by the host key
of the server in order to provide reasonably strong host-based
authentication.
Only if that passes (ie, the client tests the signature using the
public host key for the server), do the sides proceed to do user
authentication via the SSH2_MSG_NEWKEYS stage, where the client uses
the user's private key to sign the shared secret (well, actually, an
"exchange hash" containing the shared secret and other things like
the version # strings as well as the host key), which the server then
checks to see is valid by using the public key of that user (ie, in
~/.ssh/authorized_keys) to decrypt and compare with the shared secret
("exchange hash") they negotiated in the first stage.
The full gory details are in RFC-4253 & 4254.
--
-Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8AB47C58-3A82-438C-9482-24655EB46665>