New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Haven't experienced exactly same scenario, but I think you should try some kind of automation for this task, for example by using ansible to change ssh keys on the remote hosts.
If you're prepared to trust an intermediate host with the private half of a keypair you should trust it to do agent forwarding. Just register a single SSH key on all servers and use forwarding for authentication from middle nodes.
I've simply never understood suggestions to improve security by using separate keys per server, especially if your local key is on something secure like a PIV card, YubiKey or in a GnuPG keyring.
And disabling password login should make Fail2Ban irrelevant for SSH, I do use it for other brute force vectors, and so yes do switch on SSH out of curiosity and to reduce logging, but I don't consider it a security step for SSH.
Why would you? Ansible host has its' own private key, and shares only public keys to the remote machines.
This is not related to this case. @sycot has multiple clients and IMO it is very bad to share same ssh key between different devices. The point is not in having different ssh keys for different servers.
That was kind of my point in suggesting forwarding. Your private key should be with you personally, or at least under your direct control, not stored on any ansible host or other client system at all (multiple or otherwise).
@sycot discussed accessing servers from multiple hosts, not from a single host with ansible loaded. Storing multiple different [private?] keys on those hosts adds a lot of failure points, using a single key in your possession via forwarding seems far more secure.
Though I agree with you if your use case does require staging private keys, a single one would not be wise, though I'd suggest remotely storing keys that way is not good practice.
I do think we may be interpreting @sycot's question from different angles.
It is. I don't get your point at all.
Question was how to manage ~/.ssh/authorized_keys on many servers, I answered that the best option is to manage it automatically with ansible playbook.
You mentioned agent forwarding, storing private keys locally etc etc. How is this related to the original question?
I agree, we definitely have our wires crossed, I don't see any mention of that original question about distributing public keys, your post now is the only one in the thread with the word 'authorized_keys' in it. Perhaps it got deleted.
I absolutely agree with you, ansible is an excellent solution for distributing public keys to authorized_keys files on remote servers.
All I saw (and still see) is a question from @sycot about managing keys when accessing many servers from different hosts, implicitly suggesting staged private keys. My suggestion was addressing that. You and I are not in disagreement, we're just answering different things.
sorry, I think I wasn't very clear and maybe use the wrong terminology in my original post. my question was meant to be about managing ssh keys for a variety of remote servers, and needing to access those remote servers, via key authentication, from different computers (ie home, work, mobile when on the go, etc).
it's much easier for me to have password authentication and I can just input the password from any client
edit: my bad, friends, I appreciate you both weighing in, and as I am always learning new things you both provided good insight
I use Crowdsec on VMs, routers, and dedis. Never noticed abnormal CPU or memory usage, I definitely recommend it over fail2ban. Crowdsec is the same thing but with community sourcing, and IMHO easier to configure. Fail2ban will work fine depending on your use case, but I don't see a reason not to use crowdsec personally.