The easiest way to log into a linux server from a local linux computer is from a local terminal or command prompt. Almost every linux distribution comes packaged with a copy of SSH. If yours does not then it can be simply installed with the package manager by searching for and installing openssh.
In a terminal such as Konsole or Gnome-terminal (they can usually be found under the Utilities menu) issue a command of the following form:
ssh user@server
A working example for user “root” at server server “examplaaa1.miniserver.com” is:
ssh root@examplaaa1.miniserver.com
When this command is run you will be prompted for the password for the user on the remote server. Once the password is entered you will be logged into the command line of the server.
This method of using SSH requires the password to be entered for every connection. This becomes unmanageable when there are multiple users and servers being worked on. The easiest method to make working on multiple servers more secure and more efficient is to use SSH keys.
A secure protocol, in addition to encryption, demands that you prove who you are when you log in. The two principle ways of doing this with SSH are:
Password authentication is the default method for logging in via SSH and will be enabled by default on all Memset servers. Password authentication is secure but there are several advantages to disabling password authentication and instead relying on SSH keys. SSH keys are more secure than passwords as they are all but impossible to brute force attack on the server end. An attacker must have access to the private key to log into the server. They are also more efficient because any server that has the public key can be logged into from any computer that has the private key. This means that a single key (and password) can be used to securely log into any number of servers.
Every SSH key pair is unique. Therefore, in order to start using an SSH key pair, they must first be generated.
SSH keys are generated from the command line in linux. In order to create a key pair first open a terminal. Then issue the following command as your normal user:
ssh-keygen -t rsa -b 4096
The parts of this command are as follows:
Running this command will produce the following output:
Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa):
The default for ssh-keygen is to place the keys into a hidden directory called .ssh under the current users home directory. The default names for RSA keys are:
Private key: id_rsa Public key: id_rsa.pub
These defaults are fine as long as you only have a single key pair but are confusing if you have more than one. For this reason when prompted to enter the file in which to save the key a name with a little more information can be useful e.g.:
Enter file in which to save the key (/home/user/.ssh/id_rsa):/home/John/.ssh/john-smith_work
This will create the following key pair:
/home/John/.ssh/john-smith_work /home/John/.ssh/john-smith_work.pub
SSH keys work when the two machines at either end of the connection have one-half of the key pair. The remote server has the public key and the local machine the private key. Therefore, before a login is possible using keys the public key must be loaded onto the remote server. This is most easily achieved using the ssh-copy-id command.
This command has the following form:
ssh-copy-id -i public_key user@host
Using the keys that were generated in the example above the following is a working example:
ssh-copy-id -i .ssh/john-smith_work.pub root@examplaaa1.miniserver.com
When the command is run you will be prompted for the password for the user at the remote server and the public key will be saved into a file at ~/.ssh/authorized_keys.
The public key can be added manually into the authorized_keys file if you prefer.
The simplest way to use an SSH key is to specify the private key directly in the previous shown SSH login command with the -i (identity) flag:
ssh -i .ssh/john-smith_work root@examplaaa1.miniserver.com
When an SSH key is used like this it must be unlocked with its password for every connection. However, a private key can be unlocked and loaded into memory. When this is done every subsequent connection will use the unlocked key automatically without needing a password entered.
The openssh package supplies a tool to load SSH keys into memory. This tool is called ssh-add. The syntax for the ssh-add is very simple:
ssh-add /path/to/private_key
The default location for SSH keys is in the hidden .ssh directory located under the users home directory. Opening a new terminal from the desktop will start from that user's home directory so loading a private key usually looks like:
ssh-add .ssh/john-smith_work
This command will immediately request the key’s password. Once that is entered the key is loaded into memory and you will be returned back to a prompt. The key is not tied to that terminal so you can log out of that terminal or open as many new terminals as you need. They will all have access to the private key.
The security benefits of using SSH keys can be maximised by disabling password authentication on the server. Almost all of the simple, automated attacks against SSH are people or bots attempting to guess common username and password combinations. When password authentication is disabled this method of attack is rendered useless. It is, therefore, highly recommended to disable password authentication on the server.
Before you follow the steps below, make sure you have a copy of your server's root password as it will be required to regain access to the server if there are any problems with SSH as a result of this work.
The steps to disable password authentication are as follows:
cd /etc/ssh/
nano sshd_config
Before edit: PasswordAuthentication yes After edit: PasswordAuthentication no
sshd -t
systemctl restart sshd.service
If you are not able to log back into the server Memset provides out-of-band access to all their servers via MemShell. Please refer to the MemShell documentation for more information. The root password for your server will be required to access the server via MemShell.
Last updated 22 June 2017, 06:53 GMT