SSH Logon Security



  • I've been in a few offline discussions with ML members about this, so figured I would start a topic on it.

    Obviously setting up something other than just a password (and then disabling password authentication) is a good idea for Linux logon security. (Well, any system, really.)

    There are in my mind three main options.

    1. SSH key without separate private key passphrase

    2. SSH key with private key passphrase

    3. Separate authenticator such as Google Authenticator

    In my thinking all of them provide a great layer of security over a plain password.

    However, while #1 is convenient, it does not provide protection if someone steals your key or computer.

    #2 and #3 are both forms of 2FA, but #2 you have full control over the chain of command.

    The members I have talked to all have a mix of these options. I was just wondering what everyone uses in their own systems, and why you've made the decision you have on this.



  • If the GA thing works like I think it does, you still control the whole chain. The GA code is produced by your own server. that is then synced into your GA app on your device.


  • Service Provider

    @BRRABill said in SSH Logon Security:

    However, while #1 is convenient, it does not provide protection if someone steals your key or computer.

    Not alone, but you can lock down your laptop or whatever to protect it, too. It doesn't have to be completely exposed, but you have to be aware that that info is there and a potential risk. But the risk of someone stealing your laptop and figuring out how to use that key are very low compared to someone attacking your password on an exposed service. If you are targeted by an espionage field agent and they know what you are an admin for and steal your laptop in order to get that key then yeah, that's going to be bad. But if it is just stolen at random, there is nearly zero risk.


  • Service Provider

    You can do #2 and #3 together, too. 3FA if you want :)


  • Service Provider

    You can add IP locks, too. Almost 4FA at that point.



  • @scottalanmiller said in SSH Logon Security:

    You can add IP locks, too. Almost 4FA at that point.

    Let's go for 5FA! :)



  • @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! :)

    Heck, let's throw in face recognition, fingerprint reader, and cornea scans, 7FA! The sky really is the limit.



  • Legit queston as I'm still a noob and going through @scottalanmiller Linux courses. Could you do port knocking in addition to IP locks, GA, and SSH key/passphrase for almost 5FA at that point?? Seems like all of those would be a hard to beat system.



  • @travisdh1 don't forget about a live blood sample.



  • I'm moving towards SSH key based authentication. I use MobaXTerm, which encrypts everything with a password, so laptop theft is not as big of a concern.

    But I also have separate SSH keys per device I operate from. So if one gets compromised, I can easily remove it.


  • Service Provider

    @jt1001001 said in SSH Logon Security:

    Legit queston as I'm still a noob and going through @scottalanmiller Linux courses. Could you do port knocking in addition to IP locks, GA, and SSH key/passphrase for almost 5FA at that point?? Seems like all of those would be a hard to beat system.

    Yup. It just gets more and more annoying to use ;)


  • Service Provider

    @dafyre said in SSH Logon Security:

    I'm moving towards SSH key based authentication. I use MobaXTerm, which encrypts everything with a password, so laptop theft is not as big of a concern.

    But I also have separate SSH keys per device I operate from. So if one gets compromised, I can easily remove it.

    That's important. Your key should always identify the device it is used from. Never share a private key.



  • @scottalanmiller said in SSH Logon Security:

    @dafyre said in SSH Logon Security:

    I'm moving towards SSH key based authentication. I use MobaXTerm, which encrypts everything with a password, so laptop theft is not as big of a concern.

    But I also have separate SSH keys per device I operate from. So if one gets compromised, I can easily remove it.

    That's important. Your key should always identify the device it is used from. Never share a private key.

    Yes, that is especially good to note for people just getting into this.

    Makes mitigation of a lost key so much easier.



  • 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 [email protected]
    

    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.


  • Service Provider

    @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.


  • Service Provider

    @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?


  • Service Provider

    @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? :D



  • 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.


  • Service Provider

    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.


Log in to reply
 

Looks like your connection to MangoLassi was lost, please wait while we try to reconnect.