Using keys
There are a lot of things you can do with computers to create security, that's why Security is a process, not a product. One such thing is to use SSH Keys to authenticate with a remote host, rather than typing in your password all the time. Of course, using SSH Authentication keys is convenient as well.
Secure Shell Key Authentication[edit | edit source]
Setting up SSH Key Authentication allows a user account to connect from one server to another without requiring a password login. This can be utilized for applications (e.g. Nagios monitoring other servers), as well as for publish scripts that move files around servers as well as individual users.
Procedure[edit | edit source]
- If you are an administrator, please assume the role of the user for whom you are setting up this service.
sudo su user
- Ensure the user has a
~/.ssh/
directory with appropriate permissions. It must allow the user access for RWX, and group and other permissions must not be writable. Typically, 755 is a good setup. If they don't have one, thenNote that the actual identity files should NOT be readable by anyone but the user becausemkdir ~/.ssh/ && chmod 755 ~/.ssh
ssh-add
ignores identity files if they are accessible by others. That means files like id_rsa should be 600 and id_rsa.pub should be 644 - Create a new private/public key pairing for the user. Type: RSA, Bits: 1024, File:~/.svn/identity[.pub]
ssh-keygen -t rsa -b 1024 -f ~/.ssh/identity
- Copy the contents of ~/.ssh/identity.pub so you can paste it in a file on the remote server.
- Login to the remote server and assume the role of the user for whom you are setting up this service in step 1 above.
- On the remote server, ensure the user account also has a
~/.ssh/
directory with the same permissions as in step 2 above. - Open a Text Editor and edit ~/.ssh/authorized_keys
- Paste the public key from step 4 above into this file, on one line only.
- Try logging in from the first server to the second without using a password.
Troubleshooting[edit | edit source]
Check /var/log/auth.log
on the remote server for details if this doesn't work as expected.