When thinking about best practices for SSH monitoring security, we must also think generally about SSH security. We want to ensure people do not have access to our secrets such as password logins or private keys. However for monitoring, if your goal is to verify successful logins via password or key-based authentication, you need to expose that secret to the service you are delegating SSH monitoring to. It is your responsibilty to ensure the security of your systems. These four principles will help:
By providing a password/key to someone that is not you, you are creating a new risk. This decision should be weighed very carefully. Please keep our Terms of Service in mind when you are configuring your SSH checks. It is also crucial to know that when you are creating a user for SSH sign-in monitoring, you should have a separate restricted user ONLY for monitoring. You should treat this login like an untrusted user on your system, and therefore you should give it the least access required and terminate its session as quickly as possible.
When you are setting up SSH monitoring, consider:
IP whitelisting can be accomplished one of 2 ways
In your firewall, only allow SSH from the list of IPs you trust. This is useful if you know that you will only be signing in from the IPs you provide. However, if you sign in from unknown locations it could be hard to apply a whitelist this way. If it isn't practical to allow SSH via whitelist, you could secure your SSH server with something like SSHGuard to prevent brute force attempts.
If you are using OpenSSH, you can use its built-in whitelisting. You can use the AllowUsers option to specify the usernames that can sign into that server. What is handy is you can specify only the username or user@example.com and it will either allow that username, or with the second example, restrict the username to sign in from the machine 'example.com'.
If you implement whitelisting of IPs via the SSH server, your AllowUsers line could get long, but it could look something like this:
Documentation
Development
Premiere
Check Types
AllowUsers nodepingtest@2607:3f00:11:21::10 nodepingtest@104.247.192.170 nodepingtest@136.175.8.15
If you whitelist IPs, you would also need whitelist NodePing's probes to ensure they can test your SSH services.
There are many resources available to verify how hardened your SSH server is. For a start, check out the ssh-audit tool. You could also run Lynis on your system to see what else could be modified.
It's considered best practice to use SSH keys vs. passwords for authentication. One benefit to key-based authentication is not exposing your user's password when you sign in. Do not reuse passwords. Using a host-specific key prevents you from possibly sharing a commonly used password.
It is also important to think about key and password security. If you are doing password-based logins, a weak or reused password will put your server at risk. Likewise for SSH keys, you want to make sure you are using RSA 3072-bit at a minimum, 4096-bit is the recommended. Or even better, generate your keys using the newer ed25519 algorithm like so:
ssh-keygen -t ed25519
If you are setting up a user to perform an SSH check, you will want to ensure the user is restricted in what it can do on the system. If you only want to ensure a successful SSH sign in, you only want the user to successfully sign in and then immediately exit. Or, since you can check the contents of an SSH session using NodePing's SSH content matching, you can also have the session run a command that outputs something meaningful to the console and then automatically exits. There are a couple ways of doing this:
Although the shell-based method is functional if you change the user's shell, you will have to add the same configuration to the new shell's rc file. An example of this would be if you changed your user's shell from bash to zsh.
For the second option, command directly from SSH, you can either make an adjustment to the user's authorized_keys file, or modify the sshd_config file and add a 'ForceCommand' for the user, which will force that behavior for all that username's logins over SSH.
Both methods work well to limit the user's session to the functionality required for SSH monitoring and nothing more, which is the goal.
If you desire to use the command from shell route, I will assume you are using either bash or zsh. You need to edit the user's $HOME/.bashrc file or $HOME/.zshrc file. At the bottom of the file add your command and 'exit':
do_something
exit
do_something can be anything you prefer to run on login. It can echo some unique string or run a script or executable. The important thing is that you add the 'exit' on the next line, which will make the session disconnect. This method can be used for either password logins OR key-based logins.
For SSH-based restrictions, the first method requires that you modify the SSH key. It cannot be done with a password login because it relies on setting up the authorized_keys file. Run ssh-keygen. Take the private key and upload it to NodePing in the 'Account Settings' - 'Certs and Keys' section following our instructions for our SSH Checks. Then, add your public key to the authorized_keys file in $HOME/.ssh directory on the host you want to have the SSH check sign into. The trick now is to add a 'command=' argument for that key. So, it would look something like this:
command="echo 'hello world'" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIw/2Iw7iJGqqKEJfyPZPN394dd0aWUxvqEVorD7yjQ1
Every time you sign into that host using that specific username and SSH private key, the command to echo "hello world" will be ran, and the session closed.
The alternative method using OpenSSH's built-in functionality is to modify the /etc/ssh/sshd_config file and have a section at the end that looks something like this:
Match User nodepingtest
ForceCommand echo "hello world"
This will do the same as the authorized_keys method, except, every login to the nodepingtest user will result in that command being run.
It's important to restrict the user that is used for SSH monitoring. SSH monitoring is a great tool, but like many powerful tools has some serious security implications that need to be considered carefully. These best-practices should help towards your security goals.