HOWTO: ssh & scp: setup password-less login

Configure the Secure Shell (ssh) for Passwordless Login

What is the purpose ?

You will want to:

It is more secure to type a long passphrase once than a shorter password often,
It is more convenient to login or copy files without quoting a password,
You can keep a different secure & cryptic password for each machine without having to remember it each time.

The Big Picture

You generate a secure public key with its matching private key. The private key is protected (locked) by a long passphrase that only you know.
The public key only works with messages generated from your private key.
You install the public key on other (remote) machines.
You prove who your are to your local machine by typing your private passphrase, this unlocks your private key.
Your local machine connects to a remote machine using your unlocked private key.
The remote machines know that it must be you since only you know the passphrase to unlock private part of the key.
You use the same public keys for all remote machines (servers that you connect to).

There are a few practical details, but it is that simple.

In what follows there are two machines talked about:

W=Workstation, the machine with the keyboard that you use to connect to other machines;
S=Server, the remote machine that you want to login to; there will probably be several machines like this

You will make your life easier if you have the same username on both machines.

It is worth working hard today to learn the above and so be lazy tomorrow.

Key algorithm types

These are the different ways that the client authenticates itself to the server. What is recommended has changed over time; but older servers might not support newer algorithms. With some you can change the key length (-b option) ‐ bigger is better but slower.

dsa ‐ old, do not use unless needed to connect to an old server
rda ‐ OK but use a key length of 3072
ecdsa ‐ good, but some concerns of spy agency interference
ed25519 ‐ good but new (2014) so possible problems on old servers, key length option ignored

For more comments

Initial setup

Generate the public/private keys, do this on your Workstation:

W$ ssh-keygen -t rsa -b 3072
W$ ssh-keygen -t ed25519

This will ask you for a passphrase that you later given to ssh-add.
It will create in your .ssh directory:

id_rsa & id_ed25519 - these contains your private keys, to be kept secret
id_rsa.pub & id_ed25519.pub - these contains your public keys that you give to remote machines

(The file names reflect the key type)

Above is shown for two key types, do for all types that you need ‐ use the same passphrase for all of them.

You need to arrange that a ssh-agent program is started when you login and that it is known to the commands that you type. Since you may login on a plain console or via X (a GUI) you need to configure this twice in files in your HOME directory on your workstation.

Add to your .bash_profile on your workstation:

# So that ssh will work, take care with X logins - see .xsession
[[ -n $SHELL && -z $SSH_AGENT_PID && -z $DISPLAY ]] &&
	exec -l ssh-agent $SHELL -c "bash --login"

You might need to modify your workstation's .xsession ‐ on older systems where you are running xdm.
Try this without modifying .xsession, add it later if it does not work.

#!/usr/bin/bash
# This is called from /etc/X11/xdm
# Run ssh-agent (so that all children have $SSH_??? set) and then run the clients or xsession manager.
# -l is a bashism, so this assumes that you are running bash, if not just remove -l.

xsm=xsm
[ -x /etc/X11/xinit/Xclients ] && xsm=/etc/X11/xinit/Xclients
[ -x $HOME/.Xclients ] && xsm=$HOME/.Xclients

exec -l ssh-agent $SHELL -c "$xsm"

# should never get here; failsafe fallback
echo "Whoops! exec of '$xsm' failed from '$0'" >> .xsession-errors

exec -l $SHELL -c "xterm -geometry 80x24-0-0"
echo "Arrrgh! exec of 'xterm' failed from '$0'" >> .xsession-errors

exit 2

Setup for every Server that you connect to

The easy way is to run the command:

W$ ssh-copy-id S

Eg:

W$ ssh-copy-id server.example.com
W$ ssh-copy-id fred@server.example.com

You will need to use the second form if your username is different on the two machines.

If ssh-copy-id is not available on your machine (it is newish), you will need to do this by hand:
Copy your public key from your workstation into your HOME directory on the remote machine:

W$ scp ~/.ssh/id_rsa.pub ~/.ssh/id_ed25519.pub S:~

S$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
S$ cat ~/id_ed25519.pub >> ~/.ssh/authorized_keys
S$ rm ~/id_rsa.pub ~/id_ed25519.pub
S$ chmod 600 ~/.ssh/authorized_keys
S$ chmod 700 ~/.ssh

Note the 'z' in authorized_keys.
You may need to edit .ssh/id_rsa.pub so that the name YourLogin@workstation.example.com at the end of the line matches the name that is seen when you connect to the server.

Day to day use of ssh

If you have not got ssh-agent running (via .bash_profile or .xsession as above) you start it:

W$ ssh-agent bash

Every time after you login to your workstation you must prove who you are to your ssh-agent, the ssh-add program will talk to your ssh-agent:

W$ ssh-add

When it prompts you, you type the passphrase that you typed to ssh-keygen.
You do not need to do this again unless you logout of your workstation.

To login, using the same username, to another machine from your workstation:

W$ ssh -X server.example.com

The -X option will allow you to run X (GUI) applications on the server and have them display on your workstation, the X traffic will be encrypted by ssh.

To copy a file to another machine:

W$ scp SomeFile.txt server.example.com:
W$ scp SomeFile.txt server.example.com:/tmp
W$ scp SomeFile.txt server.example.com:/tmp/FileFromWorkstation.txt

The first copies to your home directory on the remove machine.
Note that the trailing colon (':') is very much needed.

It helps if you have the same usernames on all machines, but if you can't manage this you put server_username@ before the other machine name, eg:

W$ ssh -X fred@server.example.com
W$ scp SomeFile.txt fred@server.example.com:

If it doesn't work ...

A few things to check:

Check that you can login using ssh, although you may need to use a password. If you cannot do this — you have bigger problems.
Check the permissions on the various files and directories as mentioned above
ACLs (Access Control Lists) can cause problems, check what there is on the HOME directory and the other files with getfacl:
```
      getfacl $HOME $HOME/.ssh HOME/.ssh/authorized_keys
```
SELinux can cause problems if a file is not correctly labeled. This may well happen if the user's HOME directory was created by hand (perhaps copied from another machine). Check the audit file (eg /var/log/audit/audit.log). Read a description of such a problem. You may be able to fix SELinux labels thus:
```
      restorecon -R -v /home
```

Your private ssh configuration file

You can, but don't have to, put individual machine options into your own configuration file. Most of the time you do this to save yourself typing, not infrequently remove servers need special options.
Create a plain text file called .ssh/config, it should not be writable by anyone else:

W$ touch ~/.ssh/config
W$ chmod 600 ~/.ssh/config

Entries in there begin with Host nick-name, this allows you to use nick-name for the remote server instead of its probably longer name. You can also have generic options, but I am not talking about that.

Useful options in the configuration file

HostName: the complete DNS name of the machine. You can also put IP addresses (but try to avoid this since it breaks when the networking guys change things)
Port: sometimes the server admins will have the ssh server listening on a different TCP port. This can increase security in a small way
User: useful if the username on the server is different from what you use on the workstation
ForwardX11: has the same effect as the -X option, ie allows GUI applications on the server to display on to your workstation

Example showing all of the above (but you only use the ones that you need):

Host web-server
        HostName hosting_cloud.example.com
        Port 2020
        User alainw
	ForwardX11 yes

To connect using the nick-name:

W$ ssh web-server

Want to have different options for different servers, just add a new set with the Host option.

Other things of interest

License and copyright

You may used these files as the basis your own (or organisation's/company's) project(s) (under whatever licence that you see fit). You may not claim ownership or copyright of any substantially unmodified files. Acknowledgement would be appreciated, but is not necessary.

These demonstrations are made available in the hope that they are useful. There may be errors: there is no warranty at all, use at your own risk.

Return to tutorial home.

If you want any help using the above, or have any comments or suggestions, please contact us.