Open SSH is the most widely used SSH server on Linux. UsingSSH, one can connect to a remote host and gain a shell access on it in a secure manner as all traffic is encrypted.
A neat feature of open SSH is to authenticate a user using a public/private key pair to log into the remote host. By doing so, you won't be prompted for the remote user's password.
This tutorial will describe how to create a SSH public/private key pair, how to enable key based authentication and finally how to disable password authentication.
Even though SSH is secured, there is tons of brute force attacks against SSH server which will attempt to gain access to your machine.
By using key based authentication and by disabling the standard user/password authentication, you will reduce the risk of having someone gaining access to your machine.
This tutorial suppose that you already have your remote machine running a SSH server. If not, make sure your remote host has openssh server.
On Debian Stable, you need to install:
#apt-get install ssh
which will result in having both SSH server and SSH client installed.
On Ubuntu and Debian Unstable the client and server packages are separate. Therefore, you will at least need:
$sudo apt-get install openssh-server
On the server and:
$sudo apt-get install openssh-client
On the machines connecting to the server (i.e the clients)
Now let's generate the key pairs.
1. Generating A SSH Key Public/Private Key Pair
Before we can even authenticate to the remote machine using key based authentication, we need to create a public/private key pair. To do so, simply trigger:
user@host$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX user@host
Mind that if you leave the passphrase empty, anybody getting you private key (/home/user/.ssh/id_rsa) will be able to connect to your remote host.
I would recommend that you enter a passphrase, this passphrase will be use to "unlock" the key, mind that this passphrase is not related to the remote user password.
You can define another filename to save your keys to. This become handy when you have a different set of key pairs to different hosts
By now, you should have id_rsa and id_rsa.pub in ~/.ssh directory.
id_rsa is the so called private key. id_rsa.pub is the public key, the one you are going to upload on your server in order to be able to gain access to the remote machine using key authetication.
Do not share your private key, this key has to be your own, nobody but you will need to use it.
The need of a passphrase will save you a lot of trouble in case you lost it.
Now that we have our public/private key pair ready, we need to upload it to the remote machine and enable access with it.
2. Adding The Public Key To The Authorized Key
In the first place, we need to upload the key to the remote machine:
user@host:~$ scp ~/.ssh/id_rsa.pub remoteuser@remotehost:~/
Now, the public key is uploaded, let's add it to the authorized keys. To do so, we are going to connect to remotehost as remoteuser and add the key at the end of file ~/.ssh/authorized_keysand delete it once added:
$ ssh remoteuser@remotehost
remoteuser@remotehost's password:
remoteuser@remotehost:~$ cat id_rsa.pub >> ~/.ssh/authorized_keys
remoteuser@remotehost:~$ rm id_rsa.pub
remoteuser@remotehost:~$ exit
Now, we need to configure the remote SSH server to accept authentication by key pair. This is usually enabled by default. If not, the next section will cover how to activate key based authentication.
3. Activating Key Based Authentication On The Server
To do so, we need to connect as root on the remote machine. This can be achieved either by connecting to root directly:
$ ssh root@remotehost
or by connecting to the remote machine with a normal user:
$ ssh remoteuser@remotehost
and the either (usually for Ubuntu boxes):
remoteuser@remotehost:~$ sudo su -
or (Debian boxes)
remoteuser@remotehost:~$ su -
depending on your default settings.
Now open and edit /etc/ssh/sshd_config and make sure you have the following line:
RSAAuthentication yes
PubkeyAuthentication yes
Then reload your configuration:
# /etc/init.d/ssh reload
Okay, now you should be able to connect to remoteuser@remotehost without supplying a password (but the passphrase of you private key if you supplied any) by simply typing the following:
user@host:~$ ssh remoteuser@remotehost
remoteuser@remotehost:~$
Or, if your private key file is not the standard ~/.ssh/id_rsa, you can inform ssh by using the -iswitch as follow:
user@host:~$ ssh -i /path/to/private/key remoteuser@remotehost
Once you are sure that you can log into the remote host using your private key, we can safely disable the username/password authentication.
4. Disabling Authentication By Password
In order to disable authentication by password, we need to connect as root on the remote machine. On connected, go and edit/etc/ssh/sshd_config and make sure you have the following setting:
....
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no
...
and reload SSH configuration file:
# /etc/init.d/ssh reload
Now, open a new shell and connect the remote host using your private key:
user@host:~$ ssh remoteuser@remotehost
remoteuser@remotehost:~$
and check that you can't connect without a key anymore:
$ cd ~/.ssh
$ mv id_rsa id_rsa.bck
$ ssh remoteuser@remotehost
Permission denied (publickey).
$ mv id_rsa.bck id_rsa
If you get rejected with Permission denied (publickey). it means it is all good and your ssh server is protected against brute-force attacks.
5. Conclusion
By authenticating yourself using a public/private key pair and by disabling authentication by password you will considerably reduce the chance an attacker gain access to your remote machine.
It is wise to provide a passphrase when creating your key pair, this way, even if somebody get a copy of your private key, you will reduce the risk of having him gaining access to your remote machine.
No comments:
Post a Comment