openssh unix dev - Apr 2016 - (rfc) too many keys, usecase?

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?


Cheers,

-- 
Cristian

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

On Thu, 14 Apr 2016, Jakub Jelen wrote:
> 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).
Right.  Still, how much more damage could a malicious client do if it
ware presented with a password prompt?  Is it worth annoying the
non-malicious clients or push the admin into ticking up MaxAuthTries?
> If you know that you don't want to authenticate using PK, you can
> disable this method using -oPubkeyAuthentication=no option.
Yes, if I know.


Cheers,

-- 
Cristian