(rfc) too many keys, usecase?

[Cristian Ionescu-Idbohrn]

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,

[Jakub Jelen]

Post by Cristian Ionescu-Idbohrn
There is no /root/.ssh/authorized_keys on remote host, so I have to
authenticate with password.
# /usr/sbin/sshd -T | egrep permitroot
permitrootlogin yes
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
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,

[Cristian Ionescu-Idbohrn]

Post by Jakub Jelen

Post by Cristian Ionescu-Idbohrn
There is no /root/.ssh/authorized_keys on remote host, so I have to
authenticate with password.
# /usr/sbin/sshd -T | egrep permitroot
permitrootlogin yes
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
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?

Post by Jakub Jelen
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,

[Ben Lindstrom]

[..]

Post by Cristian Ionescu-Idbohrn

Post by Jakub Jelen

Post by Cristian Ionescu-Idbohrn
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

[Cristian Ionescu-Idbohrn]

Post by Cristian Ionescu-Idbohrn
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,

[Ángel González]

Post by Cristian Ionescu-Idbohrn
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,

*and* IdentitiesOnly yes. Remember that otherwise you can still hit

MaxAuthTries, even if the client was told the right key to use, it would try
other agent keys first.