Managing SSH Keys
-
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.
-
@anonymous said:
@scottalanmiller I guess you assume that they both will not have a house fire at the same time
Let's hope not! Not just that, that they don't both have one at the same time AND that we don't lose our normal admin access at the same time. It's not two things but three that would have to happen at once.
-
@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?
Things that cause loss of keys or accounts and things that cause loss of data are almost never related. Can be, of course, but there is almost no chance of that.
-
How often should I change my SSH keys? Only when I think they are exposed, or every X years?
-
@anonymous said:
How often should I change my SSH keys? Only when I think they are exposed, or every X years?
Every few years is fine. I know huge shops that never, ever change them. Just be sure to use really long ones, like 4096 bits.
-
@scottalanmiller said:
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.
Did you manually write the users, uid's, and gid's in or does it pull them from /etc/passwd?
-
I manually wrote the script, it does not pull from anywhere. We use the script as the master, not one of the servers. Sounds "manual" but the other option is to just move the manual process somewhere else.
We match user IDs to, of all things, PBX extensions. Odd, but it works.
-
@scottalanmiller said:
I manually wrote the script, it does not pull from anywhere. We use the script as the master, not one of the servers. Sounds "manual" but the other option is to just move the manual process somewhere else.
We match user IDs to, of all things, PBX extensions. Odd, but it works.
I was just curious since you said "from the jump box."
I might end up doing this, it sounds fairly simple. What about the root password when you create a new server? How do you add that if it's in the envelope?
