This section is already implemented for new user when the account was setup
Protecting SSH Keys (or X509 Certificates) on AFS
This section applies to user's with home area in AFS In general, it applies to users at U-M, but not at MSU.
If you have private information stored in AFS areas you have to be very careful. Your local system will respect the file protections you set (via chmod) but other systems very well may not! AFS has its own methodology of protection information stored in AFS. Unfortunately AFS doesn't set protections (ACLs) on individual files but rather on directories. ACL stands for Access Control List.
To secure private keys (or X509 keys) in AFS you need to do some work. I recommend creating a new subdirectory in your home area (in AFS). Make sure you have tokens as your AFS user and create a new directory:
- mkdir ~/.private
- chmod -R 744 ~/.private
This will setup a "private" directory tree in your AFS home area. Now we need to protect it via AFS ACLs. You can use the fs listacl command to see the current protection:
[smckee@umopt1 ~]$ fs listacl .private
Access list for .private is
Normal rights:
usatlas:umtestbed rlidwka
system:administrators rlidwka
system:anyuser rl
smckee rlidwka
This is not what we want at all. We need to remove ALL other AFS user access except our own. To do this we specify our own desired ACL followed by the -clear option:
- fs setacl .private smckee rlidwka -clear
This gives us:
[smckee@umopt1 ~]$ fs setacl .private smckee rlidwka -clear
[smckee@umopt1 ~]$ fs listacl .private
Access list for .private is
Normal rights:
smckee rlidwka
Good! Now only we can see this directory. Also if we create any new subdirectories they will inherit the same AFS ACL (which is what we want). Lets make one to hold our private SSH key and move it there:
- mkdir .private/.ssh
- mv .ssh/id_rsa .private/.ssh/id_rsa
Last step is to link to this new location from the old one:
- ln -s .private/.ssh/id_rsa .ssh/id_rsa
Make sure the unix file system protection is still 400:
- chmod 400 .private/.ssh/id_rsa
That's it. Your key should be secured now and only useable by you. By the way, this also works well for X509 certs (just treat your .globus/userkey.pem as you did the id_rsa file)
--
WenjingWu - 06 May 2019