Solutions for some SSH problems

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 [email protected]

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 [email protected]

You can also manually copy the key using SSH:

cat ~/.ssh/id_rsa.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Which is basically a shortcut for:

[email protected]> scp ~/.ssh/id_rsa.pub [email protected]:~/[email protected]
[email protected]> ssh [email protected]
Password: windowphonebookchivas
[email protected]> mkdir -p .ssh
[email protected]> cat [email protected] >> ~/.ssh/authorized_keys
[email protected]> rm [email protected]

Now when you SSH to the remote server:

ssh [email protected]

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 [email protected]
ssh -p 2222 [email protected]

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,

ssh [email protected]

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

do_console_menu

4. Wait for the VNC to load and log in using your username and password

do_console

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.

Leave a Reply

Your email address will not be published. Required fields are marked *