(rfc) too many keys, usecase?

[Jakub Jelen]

On 04/14/2016 01:19 PM, Cristian Ionescu-Idbohrn wrote:
> There is no /root/.ssh/authorized_keys on remote host, so I have to
> authenticate with password.
>
> On the remote host:
>
> 	# /usr/sbin/sshd -T | egrep permitroot
> 	permitrootlogin yes
>
> Attempting:
>
> 	$ ssh root@<remotehost>
>
> shows:
>
> 	Received disconnect from <remotehost> port 22:2: Too many authentication failures for root
> 	packet_write_wait: Connection to <remotehost> port 22: Broken pipe
> 	mux_client_request_session: read from master failed: Broken pipe
> 	Failed to connect to new control master
>
> Yes, I do have a few keys in ~/.ssh and use ControlMaster:
>
> 	debug1: Offering RSA public key: <userhomedir>/.ssh/id_rsa
> 	debug1: Offering RSA public key: <userhomedir>/.ssh/id_rsa
> 	debug1: Offering RSA public key: <userhomedir>/.ssh/another_id_rsa
> 	debug1: Trying private key: <userhomedir>/.ssh/id_dsa
> 	debug1: Offering ECDSA public key: <userhomedir>/.ssh/id_ecdsa
> 	debug1: Offering ED25519 public key: <userhomedir>/.ssh/id_ed25519
> 	debug1: Next authentication method: keyboard-interactive
> 	Received disconnect from <remote> port 22:2: Too many authentication failures for root
>
> Yes, I know about MaxAuthTries and I used it as a workaround.  Still,
> I would imagine the remote server knows there's no point refusing the
> slient offered keys one after the other, as none will work.  Why then
> not telling the client there's no point trying, use password instead?
The server knows that there is no point in trying, but the (possibly 
malicious) client does not know that. And server is trying to tell the 
client the least possible amount of information (basic rule of security).

If you know that you don't want to authenticate using PK, you can 
disable this method using  -oPubkeyAuthentication=no option.

Regards,

-- 
Jakub Jelen
Security Technologies
Red Hat