(rfc) too many keys, usecase?

Cristian Ionescu-Idbohrn 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
all.  Thanks.



More information about the openssh-unix-dev mailing list