Brahmanatha
asked on
SSH Keys Best Practices Guidance
This is not really a problem requiring a solution, unless you consider ignorance a problem. I am a newbie in the use of SSH keys. It's easy to find info on a) how to make them, b) how to install. But I'm still a bit in the dark on best practices of how to use them. So this is a "request for mentoring" post.
Please do not feel you need to limit your answers to the above scope. I looking for "best practices" from security veterans who make the use of SSH key a daily part of their working regimen. I may have to split the points across a lot of answers. If you had 15 minutes to tell someone the best thing to do, what would you tell them?
Thanks (from someone who learned it all since 1986, "just by doing" but lacks any formal computer science education.)
Context/Background:
Linux CentOS 6.2 Web server running plain vanilla web server with VirtualMin/WebMin wrapper/control panel. Server lives with GoGrid in their data center in San Franscisco, CA
All web site(s) content reside in /home/someuser/public_html
Admin can log in as root if he need to do anything anywhere outside of /home... which is actually very rare.
More typical daily requirement is done by logging in with SFTP in an FTP client, as a specific user into into one of the "web directories" (/home/ApplesAreFruitDomai
Goals: 1.) I want to set up ssh keys on the machine here (in hawaii) so that the users on the LAN are not necessarily having to enter a user name and password for every log in.
2. For some users on the LAN, I only want them to be able access 1 or 2 of the web sites in /home... not all of them.
3. Occasionally you have the typical requirement to install the keys of some remote developer "rajan" who lives in India/Brasil/Toronto etc.. to work on a single web site. then later revoke access.
What I know now: I create some key here on my local machine. copy the public key to the server, cd to a given directory then run the install command and I get an "authorized-keys" folder. mv the public key in there. All that much is info widely available on the net.
Questions
If you want an admin to be able to access *all* folders in /home, but nothing up the directory tree (no system file access) where do you put the authorized keys folder?
From the above you can see I assume that keys in a top directory grant access permissions to all keys in subdirectories below that one. Is this assumption correct?
The corollary is, to state the obvious, if we have "/home/BrillianMoon/.ssh/a
To put the question in a more vague open way: where is the best place to install authorized keys?
Please do not feel you need to limit your answers to the above scope. I looking for "best practices" from security veterans who make the use of SSH key a daily part of their working regimen. I may have to split the points across a lot of answers. If you had 15 minutes to tell someone the best thing to do, what would you tell them?
Thanks (from someone who learned it all since 1986, "just by doing" but lacks any formal computer science education.)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@jan: "you have no way to delineate what one access janedoe or johndoe have using the same account." True, but if I want a thin client on the desktop to do rSync with the server without requiring passwords. I don't think I have a choice. Right now the default set up by virtualMin is for all web files in /home/BrilliantMoon/ are set to owner BrilliantMoon, group BrilliantMoon. Now.. I suppose I could take a cue from arnold and add "Janedoe" to group "brilliantMoon" and set up a user /user/janedoe/.ssh/authori
re root log in: you are absolutely right.. I'll probably implement this by the end of next week.
Re White Listing IP's What about trusted team players logging in from a Java Cafe in Rio, and the ISP is using DHCP for assigning IP's from the block owned by the Cafe: This is a real use case I'm talking about here... My top man may have have bandwidth trouble at home (where he works) or just feel like he needs to get out of the house and goes to work in a nearby cafe with a legion of other Brasilian web wizards. I don't think the IP can be known in advance. There is more and more of this kind of roaming log in, even among our home team, with laptops being so portable, and open wireless networks springing up everywhere -- at the hospital, waiting in the dentist office, while traveling on the road in India with a mobile wireless web connection ISB modem/stick... you can even talk to your web server in San Francisco while driving from Rishikesh to Delhi! On on a United flight from Singapore to LA... (all real use cases where connectivity is available, and I want to safely enable access). Typically the kind of use I'm talking about will have my desktop client which will do rync to sync with files he is developing or posting... where a) we are not going thru a web UI like WordPress b) he also doesn't know anything about "terminal" .. he thinks "terminal" is a place airplanes go to... So I'm thinking the safest thing is to set him up with keys for those domains he's allowed to work with and then my desktop app simply does rync log ins under the hood and it all works. But "trusted IPs" may not be an option.
re root log in: you are absolutely right.. I'll probably implement this by the end of next week.
Re White Listing IP's What about trusted team players logging in from a Java Cafe in Rio, and the ISP is using DHCP for assigning IP's from the block owned by the Cafe: This is a real use case I'm talking about here... My top man may have have bandwidth trouble at home (where he works) or just feel like he needs to get out of the house and goes to work in a nearby cafe with a legion of other Brasilian web wizards. I don't think the IP can be known in advance. There is more and more of this kind of roaming log in, even among our home team, with laptops being so portable, and open wireless networks springing up everywhere -- at the hospital, waiting in the dentist office, while traveling on the road in India with a mobile wireless web connection ISB modem/stick... you can even talk to your web server in San Francisco while driving from Rishikesh to Delhi! On on a United flight from Singapore to LA... (all real use cases where connectivity is available, and I want to safely enable access). Typically the kind of use I'm talking about will have my desktop client which will do rync to sync with files he is developing or posting... where a) we are not going thru a web UI like WordPress b) he also doesn't know anything about "terminal" .. he thinks "terminal" is a place airplanes go to... So I'm thinking the safest thing is to set him up with keys for those domains he's allowed to work with and then my desktop app simply does rync log ins under the hood and it all works. But "trusted IPs" may not be an option.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@ arnold:
FYI... it seems you can set setfacl to make future folders and file inherit permissions... found this on Slash Dot
up vote 4 down vote accepted
I actually found something that so far does what I asked for, sharing here so anyone who runs into this issue can try out this solution:
d is default, which means for all future items created under that directory, have these rules apply by default. m is needed to add/modify rules.
FYI... it seems you can set setfacl to make future folders and file inherit permissions... found this on Slash Dot
up vote 4 down vote accepted
I actually found something that so far does what I asked for, sharing here so anyone who runs into this issue can try out this solution:
sudo setfacl -Rdm g:groupnamehere:rwx /base/path/members/
sudo setfacl -Rm g:groupnamehere:rwx /base/path/members/d is default, which means for all future items created under that directory, have these rules apply by default. m is needed to add/modify rules.
Note, the owner of the files, can remove the extended ACL this is why you should consider using a cron job that will reapply the Extended ACL.
ASKER
Thanks to everyone for helping on this. I believe I have a good understanding... I gave Andreas a slight few more points for address my "black hole" on keys directly, but all the other advice is extremely helpful...
At least enough clear information in my head that I can turn off root access right away. I'll great a user for myself right away for terminal log in and I can sudo as root from there as needed. (very rare that we need to touch the OS config).
Then starting with the SSH keys. I'll probably stick with the "shared keys" strategy that Andreas (and others on the LiveCode forum" because even if we use setfacl... users will still need to go through a prompt/login. Though it would be interesting to see if you put /home/arnold/.ssh/authoriz
At least enough clear information in my head that I can turn off root access right away. I'll great a user for myself right away for terminal log in and I can sudo as root from there as needed. (very rare that we need to touch the OS config).
Then starting with the SSH keys. I'll probably stick with the "shared keys" strategy that Andreas (and others on the LiveCode forum" because even if we use setfacl... users will still need to go through a prompt/login. Though it would be interesting to see if you put /home/arnold/.ssh/authoriz
ASKER
But I'm not only looking to allow login, but to build desktop thin client to do rSync ... so I think we need to use "shared keys" as someone else suggested to me (without a lot of info) I assume this means creating a ssh public key in /home/BrilliantMoon/.ssh/a
@ Andreas: I think you have the key Missing Brain Factor for me here: "No: a key in top directory will not grant access to subdirectories. The key will give access to all diectories the user has rights to access according to the filesystem ACLs. Users with a private key matching /home/BrillianMoon/.ssh/ private key can access all files BrillanMoon can access. Usually this files are the files in the home directory of the user and some files." OK, sheesh, that's simple and obvious enough.
Understood... can we expand on that?:
7) If remote users Lakshmi, Tom, Andre, Jan each have a key in /home/BrilliantMoon/.ssh/a
8) So another way to great a "group" would be to simply put Lakshmi's keys into 2 webdomain owner user folders if I want her to be able to access 2 domains. Right?
@jan: Yes, I'm allowing root log in now... and part of this whole discussion is to shut that down as soon as I get the SSH Keys thing working. It's a bit "scary" to look at the secure logs and see how aggressive the break in attempts are... non-stop (odd increase of hacking attempts from China... years ago I use to see lots from Russia. Thanks... I'll investigate lShell and ssh v2 ( don't know about the first, I think our box may already be configured for ssh v2... I will have to check.