SSHLoginSetup

This document might seems long because of many explanations but the basis of ssh remote loging, password or passwordless is really simple, as explained in the Principles paragraph below

Purpose of this document :

Give some explanation and be a reference to setup SSH login on a server, or "password-less" login between server.
Each time I need to do this I dig the net to find some good and clear explanation, and often end up having to untangle confusing ones or dangerously working but overcomplicated one. More importantly most of those are unclear about the WHY we do things and I tend to think that not understanding is the worst thing you can do in "security".

Audience

This document assume you know what SSH is, the broad principle of private/public key authentication and you know you way around a UNIX command line. The scope may extend later if this document prove useful and my laziness does not overcome me ... chances are slim :)

This document assume you use the OpenSSH implementation that is, by far, the most common and audited SSH implementation on UNIX systems.

Installing [[http://www.openssh.org/|OpenSSH]] if needed is not in the scope of this document.
Use your favorite package tool in case [[http://www.openssh.org/|OpenSSH]] is not already installed on your flavor of UNIX.

Terminology

Through this document we will call "origin or source computer" the computer you want to log FROM and "remote or target computer" the one you want to log in.

The goal is to be able to open a ssh shell FROM the origin computer inside the remote computer.

A key pair is the matching set of numeric keys generated together and correlated mathematically produced by the SSH machinery.

Principles

The principles are simple :
* we need to generate or use an already generated key pair.
* then we need to put the public key from the key pair on the remote computer, in the "keyring" (a file) of the user we will log into on the remote computer
* and we need to tell SSH to use the private key of the key pair (stored safely on the local computer) to log into the remote computer)

Generating the key pair

If you already have a key pair you should know what your public key is and what your private key is.
If you are generating the key pair on windows using putty, remember that the key format is not standard and that you need to use "puttyGen" to format the putty keys into the open-ssh format (just load the key ring and you can copy the key from the main windows, refers to putty manual if you need to).

To generate a new key pair type on the unix command line :

First go into the home directory of the user we want to connect with (from the source computer)

SourceComputer> su userNameYouWantToConnectWith
SourceComputer> cd ~

You computer and account must be prepared for SSH use, some file and directories must be created. Generally this is done when you install OpenSSH or done in the base configuration of your Unix installation. Check how to configure a user account for SSH use if it is not the case.

If the following explanation does not work please check [[how to configure a user account for SSH use]] first.

Generating the key ring proper :

we suppose we are in the .ssh directory in the home directory of the user we want to connect with from the source computer, if not :
SourceComputer> su userNameYouWantToConnectWith
SourceComputer> cd ~/.ssh
then
SourceComputer> ssh-keygen -t dsa keyfilename

• The -t dsa part tells ssh to create the keys to the dsa cryptographic standard.
• ssh-keygen will ask questions mostly about the password you want to use to protect the private key, if you want passwordless authentification you must give none by pressing enter. That means your private key _use_ will not be protected and so must be kept in a SAFE place. To tell it another way, **anybody** with access to that private key file can access every computer you have allowed access to (without a password) with the public key associated. We'll see later on how to use ssh-agent to be able to put a password on it and type this password only once in a given session.
• _keyfilename_ is the base name ssh-keygen will save your private and public key to. You should give a meaningfull name "webserversKeys" or "RemoteComputer_RemoteUserKeys" or whatever you want. The public key will be stored in a file with the same name with ".pub" appended to it.

Note : man ssh will give you many other options, for instance to specify all options from the command line for scripting, or generate stronger, longer, harder to crack but more processor intensive keys to use.

Putting the public key in place on the **remote** server (the one we want to log-*in*)

The remote user you want to use to log into the remote computer must also follow the ~/.ssh directory preparation mentioned above and here : [[how to configure a user account for SSH use]]

now is the tricky part (not hard but sometime tricky), you must copy the public key, that is the one stored in the file keyfilename.pub generated above inside the ~/ssh/authorized_keys2 file belongin to the remote user on the remote computer. You should do that securely.
You can do that :
* By copying the content of the keyfilename.pub on a new line inside it through and editor beware of line endings, the key is on one line without breaks be sure to pey attention to that. In the ~/ssh/authorized_keys2 file each key is on one very long line.
* By ssh-ing (scp) the file up on the aforementioned directory and appending it to the ~/ssh/authorized_keys2 (and using this last time the password of the remote user on the remote computer, of course).
something like
SourceComputer> scp keyfilename.pub  remoteUserName@RemoteComputerNameOrIP
password asked
to securely transfert the file and then
SourceComputer> ssh remoteUserName@RemoteComputerNameOrIP
password asked
RemoteComputerPrompt> cat keyfilename.pub >> authorized_keys2
RemoteComputerPrompt> exit
SourceComputer> ...
To apppend the public key to the remote computer keyring.

That's it !!

Login into the remote computer

you can now log in or make transfer to the remote computer like so :
ssh -i keyfilename RemoteUserName@RemoteComputerNameOrIP
** No password asked ** (if you did not put one on the keys you generated)

What about that -i option above and this id_dsa and id_dsa.pub files I sometime read about in other places ?

the -i option tells ssh (or the ssh tools like scp and such) to use one particular identity file. That is one particular private key.
That's it.
The same there is a default file for "foreign" public keys (~/ssh/authorized_keys2) there is a default file for private keys called id_dsa
When you generate the key you can just type inside the properly configured, permission wise, ~/ssh/ directory :
SourceComputer> ssh-keygen -t dsa
and you'll end up with a id_dsa and id_dsa.pub key pair.
You then just transfert the id_dsa.pub key into the remote user keyring (in its ~/ssh/authorized_keys2) on the remote computer, like we did above.
And you can then "ssh" inside the remote computer under the remote user account with :
SourceComputer>ssh RemoteUserName@RemoteComputerNameOrIP
and get :
RemoteComputerPrompt>

The fingerprint matter ...

The first time you log into a remote computer from a given local computer with a ssh tool, you will be presented a long ascii chain called a fingerprint that uniquely identify the remote computer in its current incarnation (OS, IP etc ...). The message will be presented as a warning asking you if you want to add that signature to the local repository of trusted computers. If you say yes you will never be asked again that question for that particular remote computer as long as its configuration does not change (OS, IP ...).
If you say "only this once" you'll be asked the question again next time and if you flat out refuse (never) then you will not be able to connect to the remote computer.
Most time you can answer yes because the timing is such that you know that it is you that asked for the remote connection on that particular remote computer you control. Being paranoid you could log in the remote computer securely (on the console for the truly paranoids ) and look up the fingerprint there and check the one you are asked about is the same ...

Much more important in my book is when a fingerprint you previously accepted does not match for a given remote computer.
That means something as changed on the remote computer : IP change, OS change, file change (crash) or tampering (security breach).
you THEN must be cautious to analyze the reasons of the change and not accept the new fingerprint blindly.
In case of doubts ....

Currently redacting

Fully password-less is BAD : ssh-agent to the rescue

Letting your private keys be without a password is a security risk : anyone that gets a hold of it can then log in (or decrypt if you use the key for encryption) any computer account you set this key public part up on.
It means that if, unfortunately, your computer is hacked you can't trust the keys anymore and have to revoke them and set up new keys again and deploy them again .... plus it means the security of other computers on your network might be compromised, and that time without "cracking" them since the bad guy had "the keys of the kingdom" (at least the password-less login user account kingdom).

But typing a pass-phrase for each use is boring, so the pass-phrase tend to get shorter and thus easier to guess or crack with time, and it is sometime unpractical when unattended logging is expected (for instance in the case of AEgir remote management of apache and database servers).

Enter SSH-Agent : SSH-Agent allow you to load the private keys into a key-ring once for a given session or a given up-time, depending on how you invoke it.
The security trade off is the following : as long as the session is not ended or the computer no rebooted, any use of the private key is possible once the pass-phrase as been typed, but the private key remains password protected and somewhat protected in memory too by ssh-agent. A motivated attacker with memory access, either physical or logical could access the key-ring in memory, but he would need to gain root access first to pull this off.
It is a good trade-off.

For now I forward you to a few excellent sources on the subject, I may sum them up here if it prooves of interest to people.

General ssh et ssh-agent configuration :
http://mah.everybody.org/docs/ssh#run-ssh-agent
Especially the start up scripts here are very useful :
http://mah.everybody.org/docs/ssh-agent-startup

SSH-Agent for daemon
http://binblog.wordpress.com/2008/12/31/using-the-ssh-agent-from-daemon-...

Currently redacting