Data Centers

SSH sessions without a password


Quite frequently there is a need to transfer files from one server to another without input from the console. The prime example of this would be a backup script using scp or rsync over ssh to transfer files to a holding area ready to be sent to tape. The problem with using scp or rsync commands to transfer files is that the ssh carrier requires a password to be entered before a ssh tunnel is created. If you're kicking backup scripts off via the crontab then the process will eventually time out and the backup will fail. Fortunately a simple solution exists which is to allow key-based authentication negating the need for a username/password challenge.

First of all, it's important to understand that keys can be generated for both version one and version two protocols. Version one uses an RSA key and version two uses a DSA key--I'll cover both types in the examples below.

Step 1: Generate a key.
The first step is to generate a pair of keys (one public and one private) on the local system. 

For SSHv1 we need to generate an RSA key pair:

# ssh-keygen

For SSHv2 we will generate a DSA key pair:

# ssh-keygen -t dsa

When prompted for a location, simply accept the default. Leave the pass phrase blank. A pair of keys will be generated in ~/.ssh/ called either id_rsa/id_rsa.pub or id_dsa/id_dsa.pub; the file ending in .pub is the public key and this is the file we need to transfer to the remote system.

Step 2: Move the public key to the remote computer 

Enter the ssh directory:

# cd ~/.ssh

Now copy the public key to the remote system:

SSHv1:

# scp ./id_rsa.pub username@remoteip:/tmp

SSHv2:

# scp ./id_dsa.pub username@remoteip:/tmp

Replace 'username' with the username you want to log in to the remote system with and replace 'remoteip' with the IP address of the remote host. You will be prompted for a password.

We now need to open up an SSH session to the remote host.

Step 3: Importing the keys

Now using a console session on the remote system we need to navigate to the .ssh directory:

# cd ~/.ssh

For authentication using SSHv1, the public key needs to be imported to the file 'authorized_keys'; for SSHv2, the authorisation file is called 'authorized_keys2'.

# cat /tmp/id_rsa.pub > ~/.ssh/authorized_keys
# cat /tmp/id_dsa.pub > ~/.ssh/authorized_keys2

That's it.

Step 4: Testing

Log off of the remote machine and try to reconnect:

# ssh remoteip

The SSH session should automatically connect without asking for a password. As a further test, try to send a file over using scp:

# scp ~/.ssh/id_rsa.pub username@remoteip:/tmp

The file should be transferred without prompting for the remote user's password.

Step 5: Cleaning up

Once everything is working, reconnect to the remote server and remember to delete the key files that were transferred to the /tmp partition.

# rm /tmp/*.pub

The above is a simple example of utilising key-based authentication in conjunction with SSH. Because the above steps will allow full access to the remote machine with no need for a password, it's important to connect from a trusted source. How far you want to go to secure this is a matter of preference. On the one hand, if you use the same passwords for accounts on multiple servers then the fact that one has been breached would mean that all others have also been breached, so there isn't really any additional risk introduced. On the other hand, you may be using key-based authentication to connect systems that use different passwords; in this case, the risk of multiple systems being breached is significantly increased.

There are precautions that can be taken. By adding some flags to the authorized_keys file we can restrict what actions a specific client can execute while connecting using keys. Here's an example:

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/bin/scp –r –t /tmp/test" KEY

This should precede the current key entry (represented by KEY). The above restricts any connection made with the relevant key so that only /usr/bin/scp can be executed. This example also disallows any types of traffic forwarding.

A useful tool called Authprogs allows easier implementation of these restrictions by acting as a middle man and allowing per-host settings to be applied via an easy-to-read configuration file. The program also creates logs and generates custom error messages, which make it quite easy to troubleshoot during the initial setup. I haven't managed to get this working perfectly; my issue comes from the fact that some backup files are named differently each day (e.g., 01022007dbdump.dmp and 02022007dbdump.dmp the next day). I have tried to use wildcards in the configuration file, but as of yet it hasn't worked as expected.

I hope this has proven useful, and I would be very interested to hear whether or not others have been able to restrict remotely executed commands where the desired command string is not static. Leave a comment to let me know how you would accomplish this task.

15 comments
jacob
jacob

> Version one uses an RSA key and version two uses a DSA key This is partially correct. Version 2 also supports an RSA key pair as of SSH2 3.0. It's actually the current default in OpenSSH. Where you get confused in your instructions is in reference to creating and managing version 1 keys. Both id_dsa* and id_rsa* are, by default, SSH version 2 keys, DSA and RSA, respectively. SSH version 1 used a default key name of identity and a public key name of identity.pub. For an SSH2 RSA key pair you can do either one of these commands. You can also add a "-f file_name_for_new_key" to put the key in some specific file other than the default. ssh-keygen ssh-keygen -t rsa For an SSH2 DSA key pair: ssh-keygen -t dsa Finally, if you must generate an SSH1 key pair, do this: ssh-keygen -t rsa1 ...and install a firewall outside the server you're connecting to that doesn't allow public ssh connections. SSH1 is just too vulnerable to attack.

svn.vara.prasad
svn.vara.prasad

Hi, We can do all the above in couple of steps if you are using ubuntu. Here are the steps.. NAME ssh-copy-id - install your identity.pub in a remote machine???s authorized_keys SYNOPSIS ssh-copy-id [-i [identity_file]] [user@]machine Example : ssh-copy-id -i /root/.ssh/identity.pub user@machine Thanks

Jaqui
Jaqui

Using a "wheel group" you can limit access to admin rights to members of the group, that have used a public / private key pair for authentication. I'll pull the directions I have for setting ssh to require it for this use and post them later.

Styopa
Styopa

edit the sshd configuration on the remote host to prohibit password authentication. Then no-one can connect without an authorised private key.

stress junkie
stress junkie

This article presents the use of ssh keys in a nice concise way. Anybody who wants to try ssh can see from this article that it is not complicated or difficult. Too often we put off learning a new function or tool because the available documentation spends endless time explaining the theory and all of the possible permutations when all that we want is a list of the commands and a brief description of what they do. Now can we get ssh on Windows? A quick search on Google suggests that there are several possibilities including Cygwin, SSH For Windows at sourceforge.net, and the original OpenSSH package itself. A recent article by George Ou recommends using Putty. I would love to see a quick "How To" for ssh on Windows. I would particularly be interested in seeing how to encrypt the Windows remote desktop application in ssh.

DanLM
DanLM

It's insecure... There is no reason not to go with ssh2. I liked the article though... I use keys for logging into all the servers I have access to. One, its just plane safer. Two, it makes it much easier for me to create some obscure password that I will never remember. I don't have to, I use the keys. And the brute force kiddies will be spinning their wheels for ever trying to figure out my password. Also, as a side note. Because more and more people try to use public/private keys on servers. Some system admins do change that authorized_keys file name in the sshd_config. I did it on the box's I have root control over. That's just a security percausion some admins take. Dan

cmiller5400
cmiller5400

You DO realize that this article is over 2 years old...

Jaqui
Jaqui

Compile sshd with the match keyword patch http://bugzilla.mindrot.org/show_bug.cgi?id=1180 , and use it to ensure that members of the admin group can only log in using public / private key authentication. Also make these users a member of the wheel group, and ensure that only they can su - check out /etc/pam.d/su. For example, in /etc/ssh/sshd_config add: Match Group admins PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no In /etc/pam.d/su ensure the following is uncommented: # Uncomment the following line to require a user to be in the "wheel" group. auth required /lib/security/$ISA/pam_wheel.so use_uid use this method to ensure that admins can only log in using public/private keys and have access to perform admin functions while (hopefully) ensuring that "normal" users cannot mess about. This also has the advantage that if any user uploads their own keys to ~/.ssh that they will not be able to gain admin rights!!!

Justin Fielding
Justin Fielding

Have you ever locked yourself out like this? For example needed to connect from an unauthorised remote host for some emergency work and not had the key available?

Justin Fielding
Justin Fielding

Thank you, I know how frustrating it can be as a sysadmin when completing what should be a relatively simple task takes forever due to the documentation going in to too much detail and giving few practical examples. While it would be nice to study every word of every man page and forum; in the real world we have to get things done in a more reasonable amount of time! I try to post in this format from time to time (dd with netcat, OpenBSD for IPSec etc) because things often don't need to be as complex as they are often made to appear.

Justin Fielding
Justin Fielding

I agree that there is no reason to use ssh1, I simply wanted to show both examples so that people understand the difference. Thanks for the tip on changing the file name. I guess I hadn't really worried about it as for that to be an issue the server first has to be breached. I do agree that it's a good practise and will start doing this myself.

stress junkie
stress junkie

Happily neither I nor any of my clients have any need of telnet so I haven't implemented ssh anywhere yet. Your post filled in the gap between ssh and pam for me. Now I just have to try it out. :D

DanLM
DanLM

lol, no lie. forgot the password because I always use pub/private keys. Forgot my encrypted thumb drive, because thats where I keep my key and putty. It does happen. Dan

DanLM
DanLM

I know some server admins don't want you using ssh keys, and that's why they change it. Usualy that is on machines where you might only have an account for a web page or irc. I dont know justin, I'm just getting paranoid as I get older. The less freedom I let a user account have on a machine, the better I feel. Unless I tell you you can have pub/private keys, I don't want you having them. Even if you do know what the default file name is. But, I still am going to use it because I have control. If that makes any sence. Dan

Jaqui
Jaqui

great tool for granting the console terminal sessions, without the risks asociated with unrestricted su access. It's also a great lockdown tool for enabling remote admin access, with a control on who can gain the access, something most organisations can use in regular operations.

Editor's Picks