A server stack is the collection of software that forms the operational infrastructure on a given machine. In a computing context, a stack is an ordered pile. A server stack is one type of solution stack — an ordered selection of software that makes it possible to complete a particular task. Like in this post about How to specify identity when using SSH agent? was one problem in server stack that need for a solution. Below are some tips in manage your linux server when you find problem about linux, ssh, certificate, ssh-keys, ssh-agent.
I’ve got a slightly unusual use-case…
I’m using SSH via certificates, (where the authentication mechanism isn’t just a signature from a private key, but also presentation of a signed cert).
I have many endpoints/servers and different environments that I access in the same session, thus my
ssh-agent is “loaded” with many identities at a time.
I’m using the
ssh-agent as it provides a number of niceties like
The issue I’m hitting is, my VM endpoints all have an
MaxAuthTries set to a low value. This cannot be changed. What I’ve noticed is, when the agent has many identities (certs/keys) added to it, and I try to connect to a given endpoint, the agent seems to loop through all added identities, trying each in turn, which is sometimes triggering the
MaxAuthTries rule, resulting in
Too many authentication failures.
So my question is, whilst using the
ssh-agent is there a way to specify which identity it’s got which it should use?
I want to use the
ssh-agent but don’t want it to cycle through each identity trying each one.
I thought of using a hosts config file, but it’s going to be a manual effort given the number of blades I maintain.
I’ve tried the
-o flag, but this seems to not look at loaded identities in the agent, and instead try to find them “locally” – where locally is the current SSH context.
Thanks for reading…
Can you make a distinction based on hostname? If so, you can try putting the following in ~/.ssh/config.
Host *.domain1.com User <your_username> IdentityFile <certificate> Host *.domain2.com User <your_username> IdentityFile <certificate>
This solution is as mentioned in the comment from the OP only workable if there is some kind of logic in the names of the hosts. With this I mean being able to determine the to be used key from the hostname, domainname, … of what you are connecting to.