Till Maas wrote:
On Thu May 22 2008, Mike McGrath wrote:
On Thu, 22 May 2008, Till Maas wrote:
On Thu May 22 2008, Mike McGrath wrote:
Client tries to ssh to Server A
Server A generates a random number, encrypts it with pub, sends it to
the client
The client decrypts this number with private key and sends it back to
A.
Bam! Shell.
The public key authentication does not work this way.
Side note about this for my own education. Can you fill in the blanks?
Because I know what is there is accurate, just not complete.
I do not understand what you ask me to do. Do you want me to explain the ssh
public-key authentication? I already explained in very short, if you want
more detail, you better look into the rfcs, because I would basically copy it
to add more detail:
1st phase: create a session encryption key and a uniqe session identifier
(hash H in the rfc):
http://www.ietf.org/rfc/rfc4253.txt
page 22 lists all the information that the hash is computed of which includes
the host key
2nd phase: authentication:
The clients signs the hash H from above and some other information like the
user name and sends it to the server, a full list of the signed information
can be found on page 9 of rfc 4252:
http://www.ietf.org/rfc/rfc4252.txt
Note: I have not read the rfc's or openssh source code/docs.
It seems like this would be open to attack in the special case where the
user has never logged into 1) The server they think they're connecting
to 2) The machine the malicious server is actually trying to
authenticate them against. In this scenario the client doesn't have
host keys for either of the remote machines so it's unable to verify
that the malicious server is lying to it.
I wouldn't think that's a huge issue, just noting that it exists.
-Toshio
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
