Linux: Password-Less SSH Logins

Before go directly into password less SSH login, I would like to discuss about SSH login details.

SSH (Secure SHELL) is an open source and most trusted network protocol that is used to login into remote servers for execution of commands and programs.

There are various forms of authentication available to the Secure Shell. Those are:

1. Ordinary Password Authentication
2. Public Key Access
3. Public Key Access with Agent support [ssh-agent]
4. Public Key Access with Agent Forwarding [ssh-agent]

1. Ordinary Password Authentication

SSH supports access with a username and password. The user makes an initial TCP connection with the remote system and sends a username and password. The remote server validate username and password and allow access.

Pro:

• Easy to understand and setup

Con:

• User to enter a password, it means anybody is allowed to enter a password. This opens the door to wholesale password guessing by users.
• Requires password entry every time you connect to remote system.
• User connecting to many systems with different password and trying to remember many separate passwords for different remote systems is difficult.
• Raw password is not secure over the Internet.

2. Public Key Access

SSH supports public key access. Key-based authentication uses two keys, one “public” key that anyone is allowed to see, and another “private” key that only the owner is allowed to see. A user creates a pair of public and private keys.  When you log in to a computer, the SSH server uses the public key to “lock” messages in a way that can only be “unlocked” by your private key. The private key is kept on the computer you log in from (from machine) and is protected on the local machine (if your RSA key is stolen) by an encrypting passphrase, while the public key is stored on the ~/.ssh/authorized_keys file on all the computers you want to log in to (to machines). In general, the private keyfile are stored in ~/.ssh/id_rsa, and the public keyfile will have id_rsa.pub file name.

In general, key-pair (public key and private key) is generated by using “ssh-keygen -t rsa“. You need to install public key to every machines which you are going to login.

In AWS, key-pair (public key and private key) is generated by AWS while you are creating instances. By default, AWS will install public key to all instances you are creating. AWS provide private key in a .pem file.

Add public key to a remote machine using the following command:

$ ssh user@remote_server
$ cat ‘id_rsa.pub’ >> ~/.ssh/authorized_keys

OR

$ ssh-copy-id  user@remote_server

Repeat this step for each server you want to connect to.

You can see all public keys by executing the following command:
$ sudo cat ~/.ssh/authorized_keys

Note: You can not see private keys for security reason.

Pro:

• The same private key (with passphrase) can be used to access multiple systems: no need to remember many passwords.
• It is more secure than Ordinary Password Authentication.

Con:

• Requires one-time setup of public key on target system.
• Requires unlocking private key with secret passphrase upon each connection.

3. Public Key Access with Agent support

Now that we’ve taken the leap into public key access, we’ll take the next step to enable agent support. In the previous section, the user’s private key was unlocked at every connection request: this is not functionally different from typing a password, and though it’s the same passphrase every time (which makes it habitual), it nevertheless gets tedious in the same manner.

Fortunately, the ssh suite provides a broker known as a “ssh-agent” which can hold and manage private keys on your workstations, and responding to requests from remote systems to verify your keys. Agents provide a tremendous productivity benefit, because once you’ve unlocked your private key (one time when you launch the agent), subsequent access works with the agent without prompting.

The “ssh-agent” program is used to keep private keys. “ssh-agent” program closely work with “ssh-add” program to add and remove private key from it’s list. Use the “ssh-add” command to add keys to the ssh-agent. The following command is used for ssh-agent:

$ eval `ssh-agent`
$ ssh-add /home/ubuntu/bikash.pem

Note: Keep in mind ssh session will be lost upon shell exit and you have to repeat the above commands again.

Pro:

• Requires unlocking of the private key only once.
• Facilitates scripted remote operation to multiple systems.

Con:

• One-time cost to set up the agent.
• Requires private key on remote client machines if they’re to make further outbound connections. Example, if server1 connected to server2 and server2 in turn connecting to server3, then server1 and server2 both should have private key present into their machine.

4. Public Key Access with Agent Forwarding

With our ssh-agent in place, it’s time to enable the final piece of our puzzle: agent forwarding. In short, this allows a chain of ssh connections to forward key challenges back to the original agent, obviating the need for private keys on any intermediate machines. So only originating machine maintain private key.

This process can be repeated with even more links in the chain (say, if the user wanted to ssh from server A to server B), and it all happens automatically. It supports the full suite of ssh-related programs, such as ssh, scp (secure copy), and sftp (secure FTP-like file transfer).

This does require the one-time installation of the user’s public — not private! — keys on all the target machines, but this setup cost is rapidly recouped by the added productivity provided. Those using public keys with agent forwarding rarely go back.

How to Configure:

Ssh agent forwarding must be allowed on the client (ForwardAgent option in ~/.ssh/config) and on the server (AllowAgentForwarding option in sshd_config). Most of the latest linux versions allow agent forwarding by default.

Pro:

• Exceptional convenience
• DO NOT need to copy your private key into all machines.

Con:

• Requires installation of public keys on all target systems
• Requires a Tech Tip to understand

Passwordless SSH logins

Your aim

You want to use Linux and OpenSSH to automate your tasks. Therefore you need an automatic login from host A / user a to Host B / user b. You don’t want to enter any passwords, because you want to call ssh from a within a shell script.

How to do it

First log in on A as user a and generate a pair (public and private) of authentication keys. Do not enter a passphrase:

$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/a/.ssh/id_rsa): Created directory ‘/home/a/.ssh’. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/a/.ssh/id_rsa. Your public key has been saved in /home/a/.ssh/id_rsa.pub. The key fingerprint is: 3e:4f:05:79:3a:9f:96:7c:3b:ad:e9:58:37:bc:37:e4 a@A

Now use ssh to create a directory ~/.ssh as user b on B. (The directory may already exist, which is fine):

$ ssh b@B mkdir -p .ssh b@B’s password:

Finally append a’s new public key to b@B:.ssh/authorized_keys and enter b’s password one last time:

$ cat .ssh/id_rsa.pub | ssh b@B ‘cat >> .ssh/authorized_keys’ b@B’s password:

From now on you can log into B as b from A as a without password:

$ ssh b@B

Note: Depending on your version of SSH you might also have to do the following changes:

• Put the public key in .ssh/authorized_keys2
• Change the permissions of .ssh to 700
• Change the permissions of .ssh/authorized_keys2 to 640