Managing SSH Keys
-
@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?
-
Oh wait, I reread it. So you have an envelope for each server?
-
@johnhooks said:
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?
Lots of choices there. You could have the password memorized by a trusted party who makes it. I've worked places where the envelope was digital and handled automatically. Or you can have an envelope for each machine, of course. Or do it by groups. There is no super simple answer. A single, shared root password for an SMB is generally best. Something that you can automate or semi-automate for builds and then store somewhere. Whoever types it in has to be assumed that they have memorized it even if it seems unlikely. So unless you have it fully automated and hidden from all humans, someone "knows" the password.
-
@johnhooks said:
Oh wait, I reread it. So you have an envelope for each server?
For us it will be groups because we have groups that make sense to share and some that don't. So a hybrid approach.
-
Just adding this note as it was asked about breakglass passwords... one of the things that we are doing to make breakglass passwords easier to manage is setting them in a system template so that every system created with that template gets the same secret root password and no need for the person creating the new system to know the password!
