Setting up ssh is not difficult, but it can be a disaster recovering if you do not do so.
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:
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.
If your remote system still allows for password-based logins, you can do the following:
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.
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.
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
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.
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
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
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.
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.
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