SSH (Secure Shell) is one of the most useful tools in the Unix arsenal. It provides a secure way of logging in and connecting to a remote server, allowing users to access and control the remote system through the network.
This article will enumerate some of the common SSH use cases and potential problems as well as solutions for each.
Passwordless SSH
Normally, when you SSH to a remote server, you will be required to enter your password to that server:
~$ ssh [email protected] Password:
If you are running automated scripts like Capistrano that needs SSH access to a remote system, this can pose a problem as it pauses the execution of your script. To solve this or if you just get tired of providing your password every time you SSH, then its time to utilize SSH public keys.
Public keys are used to identify your system with the remote system you are logging into. First you need to generate your public key using this command:
ssh-keygen -t rsa
~$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/marvs/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/marvs/.ssh/id_rsa. Your public key has been saved in /home/marvs/.ssh/id_rsa.pub. The key fingerprint is: 5b:ee:0a:c6:46:4e:3f:ed:27:38:8c:74:55:4d:93:78 marvs@local
You can press Enter for every prompt in the process and it should be ok. This will generate the public key in:
/home/USERNAME/.ssh/id_rsa.pub
Then copy the generated key into the remote server’s authorized_keys file. SSH provides a convenience method for this (assuming you are connecting to the “REMOTE” server with username “marvs”:
ssh-copy-id -i marvs@REMOTE
You can also manually copy the key using SSH:
cat ~/.ssh/id_rsa.pub | ssh marvs@REMOTE "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
Which is basically a shortcut for:
marvs@local> scp ~/.ssh/id_rsa.pub marvs@REMOTE:~/[email protected] marvs@local> ssh marvs@REMOTE Password: windowphonebookchivas marvs@REMOTE> mkdir -p .ssh marvs@REMOTE> cat [email protected] >> ~/.ssh/authorized_keys marvs@REMOTE> rm [email protected]
Now when you SSH to the remote server:
ssh marvs@REMOTE
It should no longer prompt you for a password given that you are using the local machine with the correct public key. If you re-generated your public keys, or if you want to use another machine, you will need to add the ~/.ssh/id_rsa.pub file again into the remote machine’s ~/.ssh/authorized_keys file.
Unable to SSH again
Let’s say you tried to SSH into a remote machine that you had access before, and then you are greeted by this message:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed.
This means that the SSH keys of the remote server has changed for some reason, and your local machine can no longer recognize it. While the message looks scary, most of the time this is not as horrible as it looks.
To solve this, you just need to re-establish trust between your local machine and the remote machine. You will need to remove the key corresponding to the remote machine in your ~/.ssh/known_hosts file.
It is possible to update the file manually and remove the offending line. However there is an easier way using another SSH convenience method:
~$ ssh-keygen -R HOST
This will remove the key information of HOST in your known_hosts file. Some example uses are:
~$ ssh-keygen -R 123.456.7.8
~$ ssh-keygen -R mambin.com
~$ ssh-keygen -R ec2-123-456-7-8.compute-1.amazonaws.com
You can then use the SSH command again to log in to the remote server, which updates your known_hosts file with the new key.
Non-default SSH port
The default SSH port is port 22. To improve the security of a server from malicious attackers that scan that particular port for vulnerabilities, one may choose to set the SSH port to another value.
This can pose a problem to programs that use SSH to connect to the remote server, since by default it will use port 22. To use a different port when using SSH, just use the -p flag:
ssh -p PORT user@host
ssh -p 2222 marvs@REMOTE
If you do not want to use the -p flag everytime you use SSH, then you can also set your local SSH configuration to use another port. To do this, edit (or create) your .ssh/config file:
nano ~/.ssh/config
Host mambin.com
Port 4567
Host *
Port 2222
You can specify host-specific configuration for more granular control. In the example above, when you SSH to mambin.com, you are specifying that you are connecting to port 4567. Therefore,
is the same as
ssh -p 4567 [email protected]
For all other remote hosts, the SSH command will use port 2222 as specified in the Host * configuration.
Locked out of system and cant SSH
If you installed Fail2Ban to secure your system, you may sometimes find yourself banned from your own server. This happens when you are sharing an IP Pool with other people using your ISP. If your server is on the cloud and not available for access physically, this is very troubling indeed.
When this happens, what you can do is to find out if your cloud hosting provider has a VNC feature that you can use. Virtual Network Computing (VNC) applications allows you to control a remote system by transmitting keyboard and mouse commands. If you are using DigitalOcean, then you can follow these steps:
1. Get your IP address
On a new tab, get your current IP address by visiting https://toolsphere.com/whatsmyip and taking note of your IP address.
2. Log in to your hosting account
3. Go to the VNC Console menu
4. Wait for the VNC to load and log in using your username and password
5. Once logged in, perform the following commands:
Open the hosts.allow file and include your IP address:
sudo nano /etc/hosts.allow
# Allow all SSH connections from 192.168.0.10 sshd: 192.168.0.10 # Allow all SSH connections from 192.169.0.0 - 192.169.0.999 sshd: 192.169.0.
As you can see, you can set whether to allow only specific IP addresses or allow a range of IP addresses to allow SSH access to. Remember that when allowing multiple addresses, you must end the configuration line with a dot. For example:
sshd: 123.122.
sshd: 123.122.0.
Note that by allowing a broader range of IPs the less the security of your system is. If you set it very specifically though, you may run into a scenario where you need to update the hosts.allow file everyday as a different IP address is assigned to you from the IP pool. It is up to you to determine the balance between convenience and security.
After saving the file, restart the SSH service:
sudo service ssh restart
Exit the VNC console and you should now be able to connect via SSH to your remote server again.