What is SSH?
SSH, or Secure Shell, is a network protocol that allows users to remotely manage their servers or computers over the Internet, in which the communication between the two machines are strongly encrypted and protected from being eavesdropped. The user runs a client on his or her machine and the network connection carries the user’s keystrokes and commands from the user’s local machine to the remote server. The network connection then carries back the server’s responses to the user.
Compared to the older method of remotely managing the computers using a non-protected network protocol like telnet and rlogin, SSH presents a secure alternative over an unsecured network connection (like Internet). Nowadays SSH comes shipped in mostly (if not all) servers.
A user can connect to the remote server by keying in the username and password through SSH by running the puTTY client, Terminal, Bash or any other clients. However, there is another option that is safer and less cumbersome then keying in your password every time you want to connect to your remote server, which is to authenticate using SSH public key on the said SSH server.
What is SSH public key authentication and how do they work?
An SSH server can authenticate a user in several ways, where the most commonly used method would be through passwords and public key authentication.
Normally, how a user would securely connect to their server would be to open up puTTY/Terminal/Bash and initiate an SSH connection either by logging in using a GUI or typing in a terminal ssh username@IPAddress and then proceed to key in the password when prompted.
But instead of keying in your password in the puTTY/Terminal client when you want to login to your remote server, another way to safely authenticate would be to authenticate using an SSH public key, which is authenticating without keying in the password.
SSH key authentication works in pairs: private key and public key. Unlike symmetric encryption (which uses the same key to encrypt and decrypt), SSH key authentication employs asymmetric encryption algorithm, where the encryption and decryption use different keys.
A user (or an authorised person) needs to generate both private key and a public key. The private key must be kept safely and confidential, to the extent of not sharing it with anybody else. If the private key is compromised, it is almost as good as gone, as the malicious user may gain access to the remote server using the private key, moreover if the private key is unprotected by any passphrase.
The public key which was generated together with the private key can be shared with any server. The public key is then uploaded to the remote server that the user wants to log in using the SSH protocol. Hence, a relation may also be such that; one private key to one public key placed in many servers.
Another person having access to a public key does not mean that he/she can decrypt the messages. Only a user with the private key can decrypt the messages. The public key is only there as a means to encrypt the messages where the messages can only be decrypted by the person with the private key. It is safe to say that private key cannot be derived from the public key. Hence, the public key does not have the ability to decrypt the messages that it sends out, or even decrypt the messages that the private key has encrypted.
SSH Public Key Authentication simplified
So in the case where a user is authenticating using the SSH keys (instead of manually keying in the password), the server will then send an encrypted challenge statement back to the user and the user will then decrypt the message with the private key and then send it back to the remote server to be checked. The server will then verify that that the message is correctly decrypted and if it matches the challenge statement earlier, then the client is authenticated.
Basically, the remote SSH server is testing the client whether the client has the right private key that is associated with the public key on that remote server. If the client can prove that it has the right private key, then the client is authenticated.
Why authenticate using SSH key instead of password?
Undeniably, the main advantage of authentication using SSH public key over authentication using password would be security. No matter how long or complex a password is, it can never equate with the cryptographic strength that SSH public key offers.
A password is susceptible to brute-force attack by a malicious user or worse, a password can even be guessed by someone who knows about the user’s personal information that can be used to retrieve the password.
Additionally, using SSH public key also would eliminate the need for users having to remember complicated passwords or writing them down.
Public key authentication also allows for a non-interactive login should a user need to access a remote server multiple times without needing to key in the password multiple times every time he or she logs in (or when session is disconnected due to idle time) as well as to automate processes that need to be authenticated which come from a remote machine.
However, all the above advantages are meaningless if the private key is not kept in a safe place. To increase the security, instead of storing the private key on a hard drive, it is recommended that that it is stored on a cryptographic device like a smart card or a usb token, so that it is not accessible by malicious users should an unauthorized user gains access to the computer. Additionally, the private key can be encrypted with a passphrase. But this is only applicable for interactive logins (for non-automated tasks) as it may require a person to key in the passphrase in order to use the private key.
Since creating a pair of SSH keys requires minimal effort, often times, keys are generated or re-generated (and in many cases, self-provisioned) unnecessarily just to solve minor issues. If left unchecked, this can lead to unmanaged chaos where there are many public keys without knowing who they are attached to, or whether the person is still authorized to access the servers. As such, policies and rules must to be implemented to regulate the usage of private and public keys in any organisation, like keeping an inventory,
RunCloud servers support the use of SSH public key authentication and it can be done easily and quickly. Please visit the link here on how to generate the key pairs as well as uploading the public key to the Runcloud server. And don’t forget keep an inventory of who the public keys belong to!