openssh unix dev - Sep 2020 - SFTP seems to require the public key file - why?

We migrated a server a few days ago, and the private keys we use to connect
to customers got moved as well. However, some of our automated sftp batches
were failing with authentication errors. Looking into the verbose output, I
noticed that even though ~/.ssh/config is explicitly configured to use a
specific identity file, sftp was presenting every key known to the
ssh-agent, in order. This particular customer had their daemon configured to
only allow 3 attempts. When we connected from the old server, sftp presents
the configured identity file first. I also noticed that at the beginning of
the output, it complained about not being able to find the public key file.
We extracted the public key from the private key file (giving ssh-keygen the
passphrase), and the issue resolved. To wit, sftp presented the correct
identity to the server first.

 

My question is, why does this happen? Why is the client's public key needed
to connect to a server? Why doesn't the client present the requested
identity first if the public key is not present? For other servers that we
connect to, there is no configured maximum login attempts; verbose output
shows sftp present each identity until it finds the correct one, which is
accepted and authentication is successful. Obviously, the public key isn't
cryptographically NECESSARY to authenticate.

 

Additionally, why is the public key portion of the private key file
encrypted by the passphrase? Shouldn't it be in plaintext so it's easy
to
extract?

 

 

Regards,

Karl Peterson

karl.peterson at gmail.com wrote:
> Why is the client's public key needed to connect to a server?
It isn't strictly needed if the connection does succeed in some cases..

> Why doesn't the client present the requested identity first if the
> public key is not present?
I guess that this is more by accident than anything else, but I agree
that it would be desirable to have the client behave the same in both
cases. It is both an unneccessary information leak and a potential
usability issue (as in your case).

For now you can use 'IdentitiesOnly yes' in .ssh/config to tell ssh
(thus also sftp) to only offer the explicitly configured identities.

> Additionally, why is the public key portion of the private key file
> encrypted by the passphrase?
The public key isn't stored in the private key file, it is
mathematically derived from the decrypted private key.


//Peter

On 9/28/20 11:58 AM, Peter Stuge wrote:
> karl.peterson at gmail.com wrote:
>> Why is the client's public key needed to connect to a server?
> 
> It isn't strictly needed if the connection does succeed in some cases..
> 
> 
>> Why doesn't the client present the requested identity first if the
>> public key is not present?
> 
> I guess that this is more by accident than anything else, but I agree
> that it would be desirable to have the client behave the same in both
> cases. It is both an unneccessary information leak and a potential
> usability issue (as in your case).
> 
> For now you can use 'IdentitiesOnly yes' in .ssh/config to tell ssh
> (thus also sftp) to only offer the explicitly configured identities.
> 
> 
>> Additionally, why is the public key portion of the private key file
>> encrypted by the passphrase?
> 
> The public key isn't stored in the private key file, it is
> mathematically derived from the decrypted private key.
This is no longer true with the new OpenSSH key file format. But this
functionality using these public keys is very fresh.

Regards,
-- 
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.