FAS and public Key auth

[Toshio Kuratomi]

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