Open main menu

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

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

  1. If you are an administrator, please assume the role of the user for whom you are setting up this service.
    1. sudo su user
  2. 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, then
    mkdir ~/.ssh/ && chmod 755 ~/.ssh
    
    Note that the actual identity files should NOT be readable by anyone but the user because 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
  3. Create a new private/public key pairing for the user. Type: RSA, Bits: 1024, File:~/.svn/identity[.pub]
    1. ssh-keygen -t rsa -b 1024 -f ~/.ssh/identity
      
  4. Copy the contents of ~/.ssh/identity.pub so you can paste it in a file on the remote server.
  5. Login to the remote server and assume the role of the user for whom you are setting up this service in step 1 above.
  6. On the remote server, ensure the user account also has a ~/.ssh/ directory with the same permissions as in step 2 above.
  7. Open a Text Editor and edit ~/.ssh/authorized_keys
    1. Paste the public key from step 4 above into this file, on one line only.
  8. Try logging in from the first server to the second without using a password.

Troubleshooting

Check /var/log/auth.log on the remote server for details if this doesn't work as expected.