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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
