Skip to content

SSH Tips

3SSH TIPS Setting up ssh is not difficult, but it can be a disaster recovering if you do not do so.

CLIENT SIDE

REGENERATE HOST KEY PAIR

Regardless of if this is a real install or a VPS (you are a moron if you do not do this on a VPS), you should regenerate your system key. On a VPS this may or not be properly generated, and result in either a predictable key, or quite literally the same key across all VPS nodes on that particular host or even datacenter or company.

To do so, there are several ssh host files in your /etc/ssh folder:

    $ ls /etc/ssh/
    moduli                    ssh_host_ecdsa_key        ssh_host_rsa_key
    ssh_config                ssh_host_ecdsa_key.pub    ssh_host_rsa_key.pub
    ssh_config.d/             ssh_host_ed25519_key      
    sshd_config               ssh_host_ed25519_key.pub

Just issue the following to delete and regenerate new ones :

    sudo rm /etc/ssh/ssh_host*
    sudo systemctl restart sshd

GENERATE USER KEY PAIR

The fundamental to SSL, and thus SSH, is public/private key pairs. Above we regenerated the daemon keys, but that still leaves the client, or in anotherwords the user account keys.

All you must do is the following command: 

    ssh-keygen

PASSWORDLESS LOGINS

This is a common want, as any sane admin will block access to the ssh daemon via username/password. This leaves key based access only. There are several steps to get the key sent over.

ssh-copy-id

If your remote system still allows for password-based logins, you can do the following:

    ssh-copy-id username@host.tld

Upon issuing the command, the program will try to login via your keys to see if you are already setup with all available keys or not. If you are all setup, it will quit out after stating so. If you have one or more keys that need to be copied over you may be prompted for your password, which after providing will allow the program will copy the public key information over to your account.

~/.ssh/authorized_keys

If you cannot login without your key pair, and need to get it over, you will need to have access another way, and copy your public key information into the /home/username/.ssh/authorized_keys file. Every VPS I have used allows for logins via the website in case the SSH daemon is non-functional or the networking is not working correctly. If this is a remote host that you do not control in any meaningful way, contact the administrator. They, like Amazon Lightsail, may provide you with a key to grant you access, which you can then use to add in further keys.

HOST SIDE

Setting up the host is very important, and in most cases VERY simple. With regards to the configuration file, /etc/ssh/sshd_config, there are a few very useful things that can be forced/denied that make a major impact on security.

PERMIT ROOT LOGIN

    PermitRootLogin no

Set this to no. There is no good reason to login as root remotely. On the remote system, login as a standard user, and either use su or sudo to gain superuser priveleges.

PASSWORD AUTHENTICATION

    PasswordAuthentication no

Set this to no. This stops the use of a regular username/password combinatioa. You really should be usinng your key pair to gain access (much more difficult to brute force, and impossible to guess).

CHALLENGE RESPONSE AUTHENTICATION

    ChallengeResponseAuthentication no

Set this to no. On EL7, the default is no. This blocks certain chatter via the client and server that is not necessary, especially using your key pair.

PERMIT EMPTY PASSWORDS

    PermitEmptyPasswords no

Set to no. This should be obvious. Although this should be moot if you are forcing key pair authentication, I set it to enforce it anyway.

PORT

    Port 22

Change the port if desired. I am not a fan of security thru obscurity. But, you may have a corporate guideline or ISP policy that prohibits port 22, the default, and forces you to choose something else.

LISTEN ADDRESSES

    ListenAddress 0.0.0.0

If there are multiple IP addresses on your system, you can force the daemon to ignore certain IPs by just not listing them there. The default is to listen on all interfaces and all IP addresses, both IPv4 and IPv6. For example, if you have a quad port NIC, with the IP addresses of 192.168.1.1-4, and you wish to only have 192.168.1.3 and 192.168.1.4 to listen you can setup this functionality by:

    ListenAddress 192.168.1.3
    ListenAddress 192.168.1.4