Managing SSH Keys
-
Here is a simple way to think of it...
If the simple thing is to just copy the public key, that's what you should do. Public keys are meant to be copied.
Private keys should not be copied. If you want to copy a private key you should stop and consider if you really want to bypass the security of the user/machine pair. Some people do, but this is not using SSH to its secure potential.
-
I think I would get this easier with a simple example for 2 servers.
So lets say I have a jumpbox, and I want to "add" a server to it. I create a key pair on the jumpbox, then copy the public key to the server I am adding?
-
After that I can just type ssh <hostname> and jump right over the to the other box?
-
@anonymous said:
I think I would get this easier with a simple example for 2 servers.
So lets say I have a jumpbox, and I want to "add" a server to it. I create a key pair on the jumpbox, then copy the public key to the server I am adding?
Think of it this way.... you create one key pair for each user on the jump box and no more on the jump box. You would make them when you create the users, not when you add a server. Adding a server would not involve creating a key pair, only deploying the already existing public key(s).
-
@anonymous said:
After that I can just type ssh <hostname> and jump right over the to the other box?
Correct
-
So every box gets the same public key?
-
God I feel thick right now, Thanks for your help @scottalanmiller
-
Real world example of how NTG does this which I hope illustrates how to do this effectively for a "Key Managed Environment."
We have a "user deployment script" that we run on new CentOS boxes. The script has a list of users and their user IDs from the jump box (this does not have to be done but it makes user management so much better) and the script creates all of the users, creates their home directories, sets directory permissions, sets up default groups and finally copies the users' public keys into their .ssh directories. The public keys are hard coded into the script, it just "echos" them out to the file. That's all. Super simple and no matter how many servers we deploy, just one script with all of the public keys already in it. They don't change.
-
I got it now. So it really is one key per user.
-
@anonymous said:
I got it now. So it really is one key per user.
Oh yes. One key per user per source server. Not just for Jump boxes, this is "general SSH Key security theory.* There are cases where you might forego this like if you have a Jump server cluster. Each node in the cluster might share the same private key through a shared storage mechanism internally - that would be a good exception.
But by and large, every user makes their own key on every machine from which they will log into another machine using SSH keys.
-
You do not make a root key, except in extreme cases you want to avoid that. No one should ever log in as root except for emergencies. You want keyed access by user with sudo to root because then the OS can track the actual user end to end. You have confirmation of the source machine, the user and everything that they do after that point of contact.
-
For those with static IPs or static ranges.... you can lock SSH Keys per key to IP addresses, host addresses, etc. This is not a firewall step but an SSH Application Layer security mechanism akin to how Asterisk will let you lock an extension to a specific IP address or range. This will take your security to a whole new level if you are able to do it. Many people cannot. Often you can do it with some keys and not others.
-
@scottalanmiller said:
You do not make a root key, except in extreme cases you want to avoid that.
For the root account I was going to make the password super long, and make root only available via console access. Anything else I should consider?
-
I guess if I wanted to be super secure I could restrict SSH to the VPN interface only except for the jumpbox obviously =P
-
@anonymous said:
@scottalanmiller said:
You do not make a root key, except in extreme cases you want to avoid that.
For the root account I was going to make the password super long, and make root only available via console access. Anything else I should consider?
Is this for YOU or for a company? If this is for you, that's perfectly fine.
WWNTGD? We use an officer + breakglass system. This is approved and in the process of being implemented. We have super hard passwords like you mention. They go ON PAPER to two people - COO and the retired CFO. If someone needs access to the root passwords they have to go to one of those two people and "break the glass", literally ripping open paper so that the "seal" is broken. Once this happens, everyone is aware that the glass was broken, the root account is officially compromised and once the emergency is over the password is reset by either Art or myself, the passwords put into envelopes, sealed and handed over to the accountable parties.
It's a fairly standard system for high security passwords that are only needed in extreme emergencies. Easy to get, but obvious that they have to be immediately reset.
-
@anonymous said:
I guess if I wanted to be super secure I could restrict SSH to the VPN interface only except for the jumpbox obviously =P
Yes, for the ultimate in security you would...
- Use IPTables to lock SSH at the TCP level to only authorized IPs or ranges.
- Use SSH KEY IP Matching to lock individual keys to specific IPs
- Use Fail2Ban to still make sure that multiple attempts are not made from even authorized IPs
-
@scottalanmiller said:
@anonymous said:
@scottalanmiller said:
You do not make a root key, except in extreme cases you want to avoid that.
For the root account I was going to make the password super long, and make root only available via console access. Anything else I should consider?
Is this for YOU or for a company? If this is for you, that's perfectly fine.
WWNTGD? We use an officer + breakglass system. This is approved and in the process of being implemented. We have super hard passwords like you mention. They go ON PAPER to two people - COO and the retired CFO. If someone needs access to the root passwords they have to go to one of those two people and "break the glass", literally ripping open paper so that the "seal" is broken. Once this happens, everyone is aware that the glass was broken, the root account is officially compromised and once the emergency is over the password is reset by either Art or myself, the passwords put into envelopes, sealed and handed over to the accountable parties.
It's a fairly standard system for high security passwords that are only needed in extreme emergencies. Easy to get, but obvious that they have to be immediately reset.
LOL - I do the same thing for the domain Administrator account - the envelope lives in Safety Deposit Box down the street.
-
@scottalanmiller I guess you assume that they both will not have a house fire at the same time
-
@Dashrender said:
LOL - I do the same thing for the domain Administrator account - the envelope lives in Safety Deposit Box down the street.
Down the street? What happens in the case of natural disaster?
-
@anonymous said:
@Dashrender said:
LOL - I do the same thing for the domain Administrator account - the envelope lives in Safety Deposit Box down the street.
Down the street? What happens in the case of natural disaster?
Luckily if we lost our domain there would be little if anything lost other than time. Our main application is cloud based and on someone else's shoulder. If we have a natural disaster, having access to that password is the least of our concerns and probably means all of our infrastructure is gone - I'd be rebuilding everything. Frankly, at that point I'd be happy to be able to rebuild the whole thing from the ground up - might even ditch Windows domain controllers and move to Linux ones.
