SSH access using public key

Kerem ERSOYNetwork and IT Manager
CERTIFIED EXPERT
Published:
Updated:
Daily system administration tasks often require administrators to connect remote systems. But allowing these remote systems to accept passwords makes these systems vulnerable to the risk of brute-force password guessing attacks. Furthermore there are some tasks that require automated non interactive logon to a remote system such as a backup file transfer to a remote system. The use of SSH addresses all these problems. SSH could be configured to accept only public key verified users to logon to a certain system. SSH keys also support password verification to check if the user is authorized to use the access key. This password may be omitted to allow an automated access. This is also good for scripted operations. Since the other alternative would be to enter the password directly into the script which must be avoided for all expenses because it is a huge security risk.

Lets create a ssh key pair for logon.

First of all you need to logon to the remote system. Once you've logged on and your placed in your home directory you're ready to go:

Initiate key generation using the ssh-keygen program. ssh-keygen is for creating a public/private key pair that will be used for logon. ssh-keygen allows the creation of key pairs using DSA or RSA algorithms.  DSA keys must be exactly 1024 bits to allow FIPS-186-2 compliance. RSA keys could be 768-4096 bits in length. The default is 2048 bits. Generally DSA keys are preferred because DSA was always an open standard while RSA was protected by patents which were expired in 2000. For the time being there are CERT reports indicating to some vulnerabilities with DSA and ECDSA algorithms. It seems that RSA is safe against these vulnerabilities. But as I told earlier RSA keys are not widely used in the open community since DSA was always preferred  due to it was always open-source.

Throughout the examples I'll prefer RSA keys in that it seems they are more susceptible to exploits for the time being.

The command such as this will start key generation:

 
# ssh-keygen -t rsa -C "kerem@company key20090602"

Open in new window


Here -t switch is the type of the resulting key it could be either DSA or RSA. Here I'll stick with RSA for the reasons I've explained above.
-C switch is also very useful it allows you assign a text label to your key so it will be easy for you to identify your keys.
It will respond with:

 
Generating public/private rsa key pair.
                      Enter file in which to save the key (/home/kerem/.ssh/id_rsa):

Open in new window


Hit enter here to accept the default filename (id_rsa) and the default location ($HOME/.ssh). It will then continue with:

 
Enter passphrase (empty for no passphrase):
                      Enter same passphrase again:

Open in new window


Here's where the ssh-keygen asks you for a password. You can either hit enter twice and leave the password empty. While this could be useful to automate tasks requiring remote access it could be a potential security risk if the keys are compromised. Following the password the keys will be created and placed under  $HOME/.ssh directory. The program will respond with this and quits:

 
Your identification has been saved in /home/kerem/.ssh/id_rsa.
                      Your public key has been saved in /home/kerem/.ssh/id_rsa.pub.
                      The key fingerprint is:
                      f6:61:a8:27:35:cf:4c:6d:13:22:70:cf:4c:c8:a0:23 kerem@company key20090602

Open in new window


Congratulations the key generation task is over. SSH is very sensitive to file and directory permissions. If it does not like directory permissions for .ssh it will abort key authentication during initial handshake and silently continue with other authentication methods resulting in you would only be able to login using your account password not the password you'd assigned during key generation. This would also preferred automated scripts to fail since authentication without password is not possible. Assuming that you're already located in your home folder use a command like this:

 
# chmod -R 600 .ssh 

Open in new window


This will set the .ssh directory and files under it to rwx------ which is necessary for folders and private keys. As an increased security measure I've applied it to the public key too.

The next step is to locate the the .ssh folder and make arrangements for logon there. Please execute these commands:

 
# cd .ssh
                      # cat id_rsa.pub >> authorized_keys

Open in new window


These commands will allow the newly created key appended to the file called authorized_keys. The reason I've preferred to append is to protect the keys that might have been placed in the file earlier. If we'd copied it directly instead this would destroy any existing key.

Once more execute

 
# chmod 600
                      # ssh -i id_rsa localhost

Open in new window


If everything is okay you'll get a password prompt if you've set one and logged to the system

Now the operation is complete and verified too. You'll need to transfer the keys over to your system and need to remove the private key from the target system. During the authentication the client should have the private key (id_rsa) while all the server needs to have is the $HOME/.ssh/authorized_keys file. Transfer id_rsa and id_rsa to the target system now and remove the id_rsa.

Cheers,
K.
4
6,818 Views
Kerem ERSOYNetwork and IT Manager
CERTIFIED EXPERT

Comments (4)

CERTIFIED EXPERT
Top Expert 2010

Commented:
One omission, your HOME directory can't be group or publicly writable, so don't forget to:

chmod go-w $HOME


Also on the Public key distribution front the following may help:

# Create the necessary directory structure on the remote Host
cd  $HOME/.ssh
ssh  user@remote.host  "mkdir .ssh && chmod 700 .ssh  && chmod go-w \$HOME"

# Enter the remote password

# Add your Public key, to the remote hosts authorized_keys file

cat id_dsa.pub | ssh user@remote.host  "cat - >> .ssh/authorized_keys"

# Enter the remote  password

# Test the connection.
ssh user@remote.host  "echo 'If you haven't had to enter a password the key pair has worked :)'"
Kerem ERSOYNetwork and IT Manager
CERTIFIED EXPERT

Author

Commented:
Thank you for the comment. I am working on Enterprise Linucies and they set home directories with 700 by default. But recently I have noted that Distros like Ubuntu fails to do that and actually the permission setting on the directory might be required.
Kerem ERSOYNetwork and IT Manager
CERTIFIED EXPERT

Author

Commented:
I know of no distros which would allow publicly write access to group and others by default.
CERTIFIED EXPERT
Top Expert 2010

Commented:
Agree, I'm not aware of a PUBLIC Linux, or Unix, distribution with a default umask other than 0022, but have worked in several environments were the default site build has a umask of 0002, or the home directories of the generic  Web static content, Tomcat, mySQL, Oracle, JBOSS, Weblogic, Websphere ..... ID's have had group write access granted to there $HOME, principally to enable Developers, Administrators or batch jobs, to deploy code and content into folders below the $HOME, so always worth checking.

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.