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.


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 (multiple sites)
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/ApplesAreFruitDomain/public_html/*)
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.


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/authorized-keys" then users coming in with matching private keys will only have access to the BrilliantMoon directory and sub tree folders/files. Please confirm
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.)
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

The admin (root) has full access to everything in the environment.
What you want is to use extended ACLS, and group memberships in combination with sudo to maintain a more controllable configuration.

For an admin to be limited to /home you would create a group to which this user belongs, the permissions on each directory and subdirectory will have to be 771 or 775 because besides granting the owner read/write/execute rights you need to grant the group the same rights. The last 1 or 5 means everyone has execute or read and execute rights.

The ssh keys only provide access they do not enforce/restrict what the user can do once logged in.
Usually, one would not allow remote root access.  Sudo is a tool that enables one to grant specific elevated rights to users, groups as needed.
andreasSystem AdminCommented:
You still have a little missunderstanding on how the keys work. The keys DOES not give access to directories. They give access to users (User IDs) and thus access to all files this user OWNS or this user has access rights too. This access rights are specified in ACLs of the filesystem. In many cases the standard unix ACLs for User Group and Others.

So each user has his private key in his .ssh directory in the home dirfectory. But the user also can access files in other locations if the file permissions allows them to do so. But usually a user only can have write access to files in his /home/username/ path and on some /dev/... devices and in the tmp folders.

1. To make an admin be able to access all files you need to do a little bit more work as just put a ssh key.
 You need to make a admin user and set up some sudo rules to allow this user to become the user on the system he wants. You need to be careful when doing this else the user might get root access.

2. No 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.
3. 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 in /tmp and other locations everyone can write some other tmp files and some files in /dev/

4. Best place is where sshd tries to find it. usually its ~/.ssh/authorized_keys but this can be configured in sshd_config
Jan SpringerCommented:
1) use "lshell" to configure restrictions for shell accounts by user and/or group

2) no.  keys are put into the ssh directory of the account being used to ssh or sftp

3) no. use "lshell"

4) do not allow root to log in via ssh.  force ssh v2.  add a section identifying those users allowed to ssh in to the server

5) use sudo (with or without password requirement) if necessary

6) if you use lshell, be sure to add that to /etc/shells
Simple Misconfiguration =Network Vulnerability

In this technical webinar, AlgoSec will present several examples of common misconfigurations; including a basic device change, business application connectivity changes, and data center migrations. Learn best practices to protect your business from attack.

BrahmanathaAuthor Commented:
@Arnold: while I understand your thought "What you want is to use extended ACLS, and group memberships in combination with sudo"  I don't think I want to start "messing" with the default permissions.  Too much "management" overhead. As a "plain vanilla web server"   /home/someWebSiteOwner/public_html  means that we have users set up which match the domain folder.  I can (and have in the past) created users in /home independent of the web domain owners/users' folders. They then have to have the password for root or one or another of the other web users to switch to work as that user depending on their clearance level.

 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/authorized_keys... and then pass the private key around inside your team... probably not the  best practice, now matter how trusted everyone is...

@ 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/authorized_keys/  (4 different keys)  when they log in they each "become" user "BrilliantMoon" Correct?   Can authorized keys have rational file names like ""  so that you know which key belongs which player?  I probably can find that info on the net.

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.
Jan SpringerCommented:
Everyone has their own key.  If users janedoe and johndoe want to log into the server using the "BrilliantMoon login id, that's no problem.  Their respective keys will go into the authorized_keys(2) file.  However, once logged into an account with its permissions, you have no way to delineate what one access janedoe or johndoe have using the same account.

And regarding root login, that has nothing to do with key authorization.

You *should not* allow root ssh login.  You *should* have a section called AllowedUsers in your sshd_config.  You *should* be using fail2ban which allows you to whitelist trusted IPs.
BrahmanathaAuthor Commented:
@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/authorized_keys/   and then when she logged in besides her own folder she could work in BrilliantMoon. but then I have to reset all permissions so that files can be edited by group (a pain)...

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.
Using setfacl is in addition to the existing setting not as a replacement.

The keys need to be generated by the people who need access as pointed out.

I do not beleive thin clients can authenticate using ssh keys as presumably the thin client loads the environment presenting the user with the login prompt.

Note that ssh keys is an authentication access method such that to disable remote root login in the sshd_config file should only be done after the sudo is setup and is functional.  Disabling remotehost login would mean root can only login from the console,(directly on the system) or using su - root.

Do not grant user sudo rights on any editor vi, nano, pico, emacs as they all have a key combo that envoys the shell which in sudo land will mean they have an elevated (root) rights in the shell.
BrahmanathaAuthor Commented:

setfacl never heard of it until today...I just looked it up. Very interesting...  are you saying that this is a way to give users permission *without* having to add them the group and change permissions globally?

i.e. if brilliantmoon is the default owner and group for web site /home/brilliantmoon/public_html and use "arnold" is *not* part of group brilliantmoon

and we do:

setfacl -O u-arnold rw /home/brilliantmoon/public_html

will arnold now be able to read and write files even though he is not in the group?  And... does this cascade down the directory tree below "public_html" ? Does arnold get access to all sub-directories?

This could be a very useful strategy!

Remote client App Access

The following works fine in LiveCode (and probably any language) if the machine running it has keys on the remote, and the keys do not require a password. There is no user interaction with the shell environment.  App UI has some button or menu item like "Upload Files" ... which triggers a sync of a local folder with a remote folder in two lines, followed by error checking feedback:

put format ( "rsync -avz \"" & tPathToLocalFile &"\" \"\"")  into tCmd
get shell(tCmd)
put the Result into tServerResponse
if tServerResponse <> empty then
   answer ("Please inform admin of this upload error: " & tServerResponse with "OK"
   exit to top
end if

Open in new window

Sudo Rights in Editors

All users have sudo rights at the moment and could become root if they knew the root password.  

I don't understand what this means "on any editor"  how is that different from the user having sudo in the shell.

"Do not grant user sudo rights on any editor vi, nano, pico, emacs as they all have a key combo that envoys the shell which in sudo land will mean they have an elevated (root) rights in the shell."

But, now I'm thinking I should turn off sudo perms for the default web site home folder users... "brilliantMoon" etc.. and then create specific users like "arnold" and give him sudo right... because really: No one should be doing anything as root except myself and one other person and an occasional tech support operation.
Sudo uses the user's password to authenticate not root's.
Su uses root's password to authenticate for rights elevation.

Setfacl does not cascade without the use of the -R option. Setting permissions on a folder, would still require even with setfacl to have access rights through /home and /home/briliantmoon.

You could instead of using -u to grant individual rights, use the same -g group name rwx (execute bit needed on folders to allow the user access)

The setfacl set rights are not inherited, such that you would likely need to set a cron that will reapply them this deals with access to user created directorys.
The suggestion dealing with editors deals and sudo applies when you provide limited rights to a user/group
I.e. Usera/groups can only manage user specific tasks, not the entire she'll/complete system .........
 Sudo is not suitable for filesystem access rights control; that should be left to the file system access tools. Sudo is for a controlling root level functions on the system such allowing a user to manipulate system function/settings.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
andreasSystem AdminCommented:
Yes you are correct, each users public key in the key file of BrilliantMoon will becme that user if they login to the server as BrilliantMoon. Once inside the server they only have access to files the user BrilliantMoon has. They cant move up the home tree and access other files unless ACLs allow it.

So If you dont want to implement ACLs and Sudo the "All Admin" always need to reconnect to work in the context of the desired user. With sudo you could avoid this. The admin user logs on to his own accoutn and can sudo su - username and change to the allowed users contexts. But this will not allow file upload directly to the account, you need t take the rute over /tmp then sudo and then get if back from /tmp.

If you set ACLs with group permissions you need to take care the original user will not loose write acces sto files the admin will replace while admin works with his own acount (not sudo). as the file ownership will be the admin user then and according to file ACLs created by the admin user the usual user might have no write access.

besides sudo configuration you also can use the local admin users ssh key added to the users he need need access to. Then admin can do ssh user@localhost to work as that user. This way admin user also can directly upload files from his home to the user and the ACLs are set directly with user as the owner.
BrahmanathaAuthor Commented:
@ 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:

sudo setfacl -Rdm g:groupnamehere:rwx /base/path/members/
sudo setfacl -Rm g:groupnamehere:rwx /base/path/members/

Open in new window

R is recursive, which means everything under that directory will have the rule applied to it.
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.
BrahmanathaAuthor Commented:
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/authorized_keys  and then used setfacl to give arnold permissions to read and write to /home/brilliantmoon/public_html.   what would happen... could he make new folders? would they still be accessible to brilliantmoon?  but testing that should be obvious.  I'll do my home work on the net for setfacl if it looks like a tool I'll need later
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Security

From novice to tech pro — start learning today.