<

SSH access using public key

Published on
10,989 Points
5,589 Views
4 Endorsements
Last Modified:
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
Comment
Author:Kerem ERSOY
  • 2
  • 2
4 Comments
 
LVL 26

Expert Comment

by:arober11
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 :)'"
0
 
LVL 30

Author Comment

by:Kerem ERSOY
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.
0
 
LVL 30

Author Comment

by:Kerem ERSOY
I know of no distros which would allow publicly write access to group and others by default.
0
 
LVL 26

Expert Comment

by:arober11
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.
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Join & Write a Comment

Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
How to Install VMware Tools in Red Hat Enterprise Linux 6.4 (RHEL 6.4) Step-by-Step Tutorial

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month