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
Cristian Ionescu-Idbohrn wrote:> On Thu, 14 Apr 2016, Jakub Jelen wrote: >> On 04/14/2016 01:19 PM, Cristian Ionescu-Idbohrn wrote:[..]>>> 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? >Same argument could be applied to why I bother to present a password prompt if all the server accepts only public keys. By not doing it, I reduce the possible attack service a hacker has to break into my server. Knowing that keys aren't except for the server or for an individual user it leaks information that an attacker can use against me. This is the same reason why a few years ago we went through painful effort to stop ssh from short-cutting out of bad authentications attempts. Because it leaked a bit of information an attacker could detect to shift their attack method. *shrug* My solution to this "issue" was to stop generating keys with standard id_{rsa,dsa,etc} names. And use something more useful "id_rsa_work" "id_rsa_play" .. etc.. Then I specify via ~/.ssh/config which key is to be served to a server. As I honestly never liked the "throw ssh keys at the server and see which one sticks" feature of the SSH RFC. It feels like a lazy way of key administration. It was great when you are learning, but sucks when you start collecting dozens of ssh keys for different community, work, personal, and friend's servers. All of them being completely different so you can keep good isolation habits (e.g. If I leave a community I want to do rm -rf .ssh/id_rsa_communityname* and know for a fact that I no longer have the key and it improves my confidence that I'm not going to lose it, and thus causing a possible compromise if the community doesn't do their own due diligence on removing my account or key). The above also linked with ssh-agent and locking/unlocking ssh keys has how I've lived for 10+ years now, and have never ran into this problem. Honestly, it is better to learn to manage your SSH keys properly. - Ben
On Thu, 14 Apr 2016, Ben Lindstrom wrote:> Cristian Ionescu-Idbohrn wrote: > > > > 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?...> This is the same reason why a few years ago we went > through painful effort to stop ssh from short-cutting out of bad > authentications attempts. Because it leaked a bit of information an > attacker could detect to shift their attack method....> Then I specify via ~/.ssh/config which key is to be served to a > server. As I honestly never liked the "throw ssh keys at the server > and see which one sticks" feature of the SSH RFC. > It feels like a lazy way of key administration. > > It was great when you are learning, but sucks when you start > collecting dozens of ssh keys for different community, work, > personal, and friend's servers. All of them being completely > different so you can keep good isolation habits (e.g. If I leave a > community I want to do rm -rf .ssh/id_rsa_communityname* and know > for a fact that I no longer have the key and it improves my > confidence that I'm not going to lose it, and thus causing a > possible compromise if the community doesn't do their own due > diligence on removing my account or key).Now, that sounds like a good idea. I'll do that, I think. Serve selected key(s) to selected servers, throuh ~/.ssh/config, using the IdentityFile option. A little more administration, but not heavy at all. Thanks. Cheers, -- Cristian