ssh

SSH (Secure Shell) is a UNIX-based command interface and protocol for securely getting access to a remote computer. SSH is actually a suite of three utilities - slogin, ssh, and scp - that are secure versions of the earlier UNIX utilities, rlogin, rsh, and rcp. SSH commands are encrypted and secure in several ways. Both ends of the client/server connection are authenticated using a digital certificate, and passwords are protected by being encrypted.

SSH is the most common way to access remote Linux and Unix-like servers. A very common use of SSH is for Github account service.

Basic Syntax

$ ssh remote_username@remote_host

SSH is a secure communication protocol, it works by connecting a ssh client to a ssh server, the most popular implementation of SSH in Linux is OpenSSH,
it provides a ssh command as the ssh client and sshd as the ssh server. In windows, an open source ssh client PuTTy can be used.
Make sure the sshd server is already running on the remote_host before we connect to it.

On Ubuntu 16.04, use sudo systemctl start ssh to start the sshd server if it is not started.

SSH server Configuration

$ sudo vim /etc/ssh/sshd_config

Below are some most common settings

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

The host keys declarations specify where to look for global host keys.

LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

LoginGraceTime specifies how many seconds to keep the connection alive without successfully logging in.

It may be a good idea to set this time just a little bit higher than the amount of time it takes you to log in normally.

PermitRootLogin selects whether root is allowed to log in.

In most cases, this should be changed to “no” when you have created user account that has access to elevated privileges (through su or sudo) and can log in through ssh.

strictModes is a safety guard that will refuse a login attempt if the authentication files are readable by everyone.

This prevents login attempts when the configuration files are not secure.

X11Forwarding yes
X11DisplayOffset 10

These parameters configure an ability called X11 Forwarding. This allows you to view a remote system’s graphical user interface (GUI) on the local system.

This option must be enabled on the server and given with the SSH client during connection with the -X option.

Login using SSH with Keys

By default username/passwords are required to login to a remote system, but it could be tedious every time when we need to login to the remote server, we can set up key-based authentication to enable passwordless login.

How Does Key-based Authentication Work?

Key-based authentication works by creating a pair of keys: a private key and a public key.

The private key is located on the client machine and is secured and kept secret.

The public key can be given to anyone or placed on any server you wish to access.

When you attempt to connect using a key-pair, the server will use the public key to create a message for the client computer that can only be read with the private key.

The client computer then sends the appropriate response back to the server and the server will know that the client is legitimate.

This entire process is done in the background automatically after you set up keys.

Create SSH Keys

$ ssh-keygen -t rsa

By default, this command will generate a key pairs id_rsa.pub and id_rsa in ~/.ssh directory.

RSA key and ED25519 key are considered strong enough, we can have more options when we generate them:

$ ssh-keygen -t rsa -b 4096 -o -a 100
$ ssh-keygen -t ed25519 -o -a 100

We can specify another name using -f option

$ ssh-keygen -f test -C "test key"


$ cd ~/.ssh
$ ls
-rw-r--r-- 1 alex alex  807 Nov  9 20:55 authorized_keys
-rw------- 1 alex alex 1679 Nov  9 22:01 id_rsa
-rw-r--r-- 1 alex alex  396 Nov  9 22:01 id_rsa.pub

As shown, the id_rsa file is readable and writable only (600) to the owner. This is how it should be to keep it secret.

How To Transfer the Public Key to the Server

(1) Manually copy to remote server

$ cat ~/.ssh/id_rsa.pub | ssh hostname "cat >> ~/.ssh/authorized_keys"

Now when ssh to the remote machine, it should ask you for your key passphrase instead of your password. If it doesn’t, it could be that the permissions and mode of the authorized_keys file and .ssh directory on the remote server need to be set more restrictively. You can do that with these commands on the remote server:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

(2) Automatically copy to remote server

$ ssh-copy-id remote_host

This will start an SSH session, which you will need to authenticate with your password.

After you enter your password, it will copy your public key to the server’s ~/.ssh/authorized_keys file, which will allow you to log in without the password next time.

Client-Side Options

See debug info of login, very helpful when we failed to login.

$ ssh -v remote_host
debug1: identity file /home/chris/.ssh/id_rsa type 2
...
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/chris/.ssh/id_rsa
...
debug1: Authentication succeeded (publickey)

Some optional flags may need to match the settings in the remote host’s sshd configuration.

For instance, you if you changed the port number in your sshd configuration, you will need to match that port on the client-side by typing:

$ ssh -p port_number remote_host

If you only wish to execute a single command on a remote system, you can specify it after the host like so:

$ ssh remote_host command_to_run

Using the ssh-agent program

The true usefulness of using key based authentication comes in the use of the ssh-agent program. Usually, the ssh-agent program is a program that starts up before starting X windows and in turn starts X windows for you. All X windows programs inherit a connection back to the ssh-agent, including your terminal windows like Gnome Terminal, Konsole, xfce4-terminal, aterm, xterm and so on. What this means is that after you’ve started up X windows through ssh-agent, you can use the ssh-add program to add your passphrase one time to the agent and the agent will in turn pass this authentication information automatically every time you need to use your passphrase.

Most recent distributions will automatically start ssh-agent when you login to X windows through a session manager like gdm (graphical login).

We can check if it is already running by

$ ps ef | grep ssh-agent

If it is not running, we can start it by

$ eval `ssh-agent -s`

or

$ exec ssh-agent bash

Once it is running, add ssh key to it by running the ssh-add command:

$ ssh-add

this will add default generated private key id_rsa into ssh-agent, to add a different named ssh key, we can do this:

$ ssh-add ~/.ssh/my_pk

To list all ssh-keys that have been added into ssh-agent

$ ssh-add -l

How to start ssh-agent automatically on system start up

Adding the following to ~/.bash_profile will automatically start ssh-agent and load the ssh-key(s) on login:

if [ -z "$SSH_AUTH_SOCK" ] ; then
  eval `ssh-agent -s`
  ssh-add
fi

Why do we need to use eval instead of just ssh-agent?
Because when we execute ssh-agent -s, it will output below infomation. These information simply means that by starting ssh-agent,
it will set some environment variables as shown and exports them to the current shell. Using eval command will simply evaluate the scripts in enbraced by ``, so that its result will take effects on current shell.

SSH_AUTH_SOCK=/tmp/ssh-XH65nCfLn4Hj/agent.8612; export SSH_AUTH_SOCK;
SSH_AGENT_PID=9456; export SSH_AGENT_PID;
echo Agent pid 9456;

check here for more explanations.

A summary note on permission settings in SSH>

There are cases when we ‘correctly’ set up key-pairs following the above procedure, and still encounter error messages “Authentication refused: Bad owner or permissions on” when we login through SSH. This is essentially because of the inappropriate permission mode of the directory ~/.ssh and files in it.

File Permission in local machine and remote machine

Local Machine

• ~/.ssh Write permission should be restricted only to the owner. e.g. 755 drwxr-xr-x
• ~/.ssh/id_rsa Write, Read and Execute permission should be restricted only to the owner. e.g. 600
• ~/.ssh/config Write permission should be restricted only to the owner. e.g. 700 or 600

Remote Machine

• ~/.ssh Write permission should restricted be only to the owner. e.g. 700 drwx—–
• ~/.ssh/authorized_key Write permission should be restricted only to the owner. e.g. 600

In short, if any of the file

Also, if we are not sure what the errors come from, we can always check /var/log/secure for more details.

A sample client side configuration: ~/.ssh/config

Reference
https://support.suso.com/supki/SSH_Tutorial_for_Linux
http://rabexc.org/posts/pitfalls-of-ssh-agents
http://unix.stackexchange.com/questions/90853/how-can-i-run-ssh-add-automatically-without-password-prompt