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