SSH Logon Security
-
Another good question... Is there an easy way to share a key repository? Say that I have 50 linux machines... do I need to manually put my key on all 50 of them, or is there a way to manage one central set ?
-
@dafyre said in SSH Logon Security:
Another good question... Is there an easy way to share a key repository? Say that I have 50 linux machines... do I need to manually put my key on all 50 of them, or is there a way to manage one central set ?
You just need to distribute the public key and append it to the authorized_keys on each host you want access to. You could also keep a central copy of an authorized_keys file to be distributed by your management platform, I think that's how NTG manages their keys. You've also got the manual method if you have a limited number of machines to manage, which is what I use as I've only got 8 machines to manage, and very little turnover that they need updating.
Copy your public key to another ssh enabled host:
ssh-copy-id user@remoteip
That won't work till you've already logged into the remote machine with ssh, the devs do as much as humanely possible to make sure you compare the remote machine key to the one your presented the first time you login via ssh.
-
@dafyre said in SSH Logon Security:
Another good question... Is there an easy way to share a key repository? Say that I have 50 linux machines... do I need to manually put my key on all 50 of them, or is there a way to manage one central set ?
NFS home directories is common. Or push them out with scripts or a DevOps tool.
-
@travisdh1 said in SSH Logon Security:
You could also keep a central copy of an authorized_keys file to be distributed by your management platform, I think that's how NTG manages their keys.
Yup, central script right now. Moving to Salt in the future.
-
So with an encrypted endpoint (laptop with FDE, bitlocker, etc) the assumed risk of key theft is very low.
Under what circumstances would you recommend a passphrase on the private key? I guess it all varies. If there is access to it, passphrase it. But when would there ever be access to it?
-
@BRRABill said in SSH Logon Security:
So with an encrypted endpoint (laptop with FDE, bitlocker, etc) the assumed risk of key theft is very low.
Under what circumstances would you recommend a passphrase on the private key? I guess it all varies. If there is access to it, passphrase it. But when would there ever be access to it?
Yeah, depends how vulnerable the end point is, how valuable the access is, etc. I'm certainly not putting a passphrase on my lab key. But production, very easily I would. I only work from home and my computer is very safe and in a different country than the things that it accesses. Someone breaking into my house to get the SSH key from my laptop is absurd. But if I was to work from a coffee shop, whoa baby I'd have that passphrased for sure. One second looking away someone could use your key to do something bad. So... all depends on both ends.
-
@BRRABill said in SSH Logon Security:
So with an encrypted endpoint (laptop with FDE, bitlocker, etc) the assumed risk of key theft is very low.
Under what circumstances would you recommend a passphrase on the private key? I guess it all varies. If there is access to it, passphrase it. But when would there ever be access to it?
If you're going from a Linux system to a Linux system you can store the key's passphrase in the keyring and it would auto unlock for that session.
We have limited keys set up and use Kerberos for everything. That way we can set a life on the ticket and people can't be stupid and share keys or accidentally copy them somewhere else.
-
@BRRABill Really! Is there anything like 5FA?
-
If you're running FreeIPA/Identity Management you get the OTP functionality out of the box. So both SSH and console logins require the OTP for 2FA.
We use SCAP for hardening rules and it has a decent SSH section. Things like limiting disabling root logins, ciphers, max SSH sessions, timeouts, strict mode checking, privilege separation, encrypted X11, etc.
-
@BRRABill said in SSH Logon Security:
In my thinking all of them provide a great layer of security over a plain password.
Yes. Without a key, the password you type is sent encrypted over the network to the remote machine. With a key it is a challenge response method like with kerberos. The password is never sent over the network.
-
@BRRABill said in SSH Logon Security:
@scottalanmiller said in SSH Logon Security:
You can add IP locks, too. Almost 4FA at that point.
Let's go for 5FA!
You could almost get there with user locking. My jump box only allows a certain user group that doesn't have the sudo or su ability. So if you are coming from the outside the only users that can SSH in have no way to elevate privileges or change users.
-
@dafyre said in SSH Logon Security:
Another good question... Is there an easy way to share a key repository? Say that I have 50 linux machines... do I need to manually put my key on all 50 of them, or is there a way to manage one central set ?
Our Identiry Management stuff holds the public key in LDAP and the users can authenticate against that (if the machine is joined to the domain). Most users are using kerberos but we have a few set up with keys because of applications that run for long times.
Also like Scott said, I'd you have NFS or SAMBA mounted home directories it will just work.
But both of these do away with the one key per machine philosophy.
-
We have some boxes that have no SSH. We use Salt. If we need SSH, we can turn it on and lock it down for the user in question and shut it down when the need is no longer there.