(rfc) too many keys, usecase?
cristian.ionescu-idbohrn at axis.com
Fri Apr 15 03:53:43 AEST 2016
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
More information about the openssh-unix-dev