SSH or Secure Shell is one of the oldest protocols used in networking for secure encrypted communication between two systems and to remotely manage servers and other systems. Ever since its introduction, they have been adopted by IT teams in organizations all over the world to manage their assets. And SSH keys continue to play a significant role in granting secure access to computer systems, and with the cloud computing boom, they’re playing even more important roles.
So what are SSH keys? How does the SSH protocol work? What is the role of SSH keys in asset management? Let’s explore.
History of the SSH protocol
The SSH protocol or Secure Shell protocol was developed by Tatu Ylönen, a researcher at the Helsinki University of Technology. He was motivated by a password sniffing attack on the university which compromised thousands of credentials. He wanted to create more secure networks that guarantee confidentiality and had stronger authentication.
Tatu released the first version free to use in 1995, and by the end of the year, it had 20,000 users.
A revised version of the SSH protocol named SSH-2 was developed by the internet engineering task force and adopted as a standard in 2006.
Meanwhile, developers were working on the last open-source version of the original SSH protocol to create a free version. This eventually led to the creation of OpenSSH, the most popular implementation of the SSH protocol in existence.
How does the SSH protocol work?
The SSH protocol is used to remotely access a system through another. The system the user is trying to access - a server, a workstation, etc. - is called the host; and the system used to access the host - probably your PC or workstation - is called the client.
For a client to remotely access the host, both the systems should be able to send and receive information from each other. The SSH protocol uses cryptographic techniques to encrypt this communication.
The protocol uses both symmetric and asymmetric keys for security.
To give you a refresher on cryptographic techniques, in symmetric key encryption, both the encryption and decryption are done with the same key, or the decryption key can be generated from the encryption key. In the case of asymmetric encryption, the public key can only be used for encrypting the message; you’ll need the private key for decrypting the message.
The server encryption negotiation
Once a server receives a request for an SSH connection, the server encryption negotiation begins. During this process, the protocol uses an asymmetric encryption process with the Diffie-Hellman (DH) key exchange algorithm to form a shared secret key for the SSH connection.
Here the client and the host agree on an encryption protocol as well as two numbers. Using the two numbers, and a number chosen separately by the two entities, two machines apply it to an equation known only between them. And then the final result is exchanged between the two machines. Then using the result received from the other, the machines perform another calculation to form a secret shared key.
This secret shared key is used to establish a secure connection between the host and the client. But this doesn’t mean the user gets access to the server. Before this, the user has to be authenticated.
Authenticating the user
Authenticating a user is pretty straightforward if you’re going through the username/password approach. The user enters the username and the password, which is encrypted and sent from the client to the host, and if accepted, the user gets access to the server.
Since the passwords are encrypted, a third party cannot figure it out even if they gain access to the messages. But the password is only as safe as its strength; if an attacker could guess the password, then it's game over.
The safer approach is to use SSH keys or SSH key pairs.
What are SSH keys?
SSH keys are pairs of asymmetric encryption keys used to authenticate a user before letting them access a remote server.
How is a user authenticated using SSH keys?
Before authenticating a user using SSH keys, you have to set up a pair of public and private keys. Once that is done, and a secure SSH communication is established between the client and the server, the client informs the public and private key combo with which to authenticate the user.
If the server finds this combo in its database, it uses a challenge-response authentication to verify that the user has the private key for the public key.
For this, the server/host encrypts a message using its public key and sends it to the client. The client, in turn, decrypts this message using its private key and combines the underlying message with the session key - the shared key developed both by the client and the host during the server encryption negotiation - to create a hash. This is then sent to the host.
Now hashing, to recall, uses an algorithm to convert a string of any length to a hash value of predefined size. While it is easy to find the hash value of a string, it's computationally difficult to find the original string from the hash value.
Meanwhile, the host server would have created a hash with the underlying message and the secret key. If the hash values match, the user is authenticated.
If the SSH keys are within the client, the user doesn’t have to manually type in the password or the private key for authentication. The whole thing happens behind the scenes; you just have to type the command to open an SSH connection with a server and you’re good to go.
How to use SSH keys
The first step is to generate a pair of SSH keys. These steps assume that you have installed SSH on your client and servers and that you have access to both.
Generating SSH keys on Linux or Mac.
Open the terminal and enter the following command
ssh-keygen -t rsa
The -t rsa refers to the algorithm used. You can use other algorithms like -t ed25519 and if you want you can label the keys using -c For example if you’re using Ed25519 and want to use harry@potter.com as a comment, you can use the command
ssh-keygen -t ed25519 -C "harry@potter.com"
At this point, you’ll be prompted to enter the file location where the key will be saved. You can use the default location, or change the location and hit enter
Next, you’ll be used to enter a passphrase (password). You can leave it empty, or you can use a password for additional protection. If you leave it empty, you’ll be connected directly to the server as long as the keys are stored in the same location. If it is not empty, you’ll be asked to enter the password before you’re granted access to the server.
Generating SSH keys on Windows
There are many different ways to do this on Windows, but let’s go for the Microsoft way. Make sure you have installed OpenSSH on Windows. If not, follow these steps.
In the PowerShell, enter the following command
ssh-keygen -t rsa
As in the case of Linux or Mac, you’ll get a prompt asking where you want to store the file. Specify the location, or hit enter to accept the location.
You’ll be asked to enter a passphrase. You can leave it empty if you want to; if so hit enter.
The keys are now stored in the location. The next step is to share the public key with your remote server.
Once again the steps are different for Mac/Linux and Windows
Sharing the public key on Mac/Linux systems
In the command line, enter
ssh-copy-id username@remoteserverip
- if the username for your server is harrypotter and the IP address of your server is 192.168.1.1 the command will be
ssh-copy-id harrypotter@192.168.1.1
The first time you do this, you’ll be shown a warning message, asking if you want to continue. Type yes and hit enter.
Then you’ll be asked to enter the password for your remote server.
Once you’ve entered your password and hit enter, you’ll get a message saying the keys are added.
Sharing the public key on Windows systems
For Windows systems, this step depends on whether the keys are for a standard user or an administrative user.
For the standard user, the public key is to be placed in a text file called authorized_keys on the server in the location C:\Users\username\.ssh\
For that, use the command
scp :\Users\username\.ssh\id_ed25519.pub user1@domain1@contoso.com:C:\Users\username\.ssh\authorized_keys
For the administrative user, the public key has to be placed in a text file called administrators_authorized_keys in C:\ProgramData\ssh\.
For this, use the command
scp C:\Users\username\.ssh\id_ed25519.pub user1@domain1@contoso.com:C:\ProgramData\ssh\administrators_authorized_keys
Also, the access to the ACL on this file should be limited to administrators only.
For this, use the command
ssh --% user1@domain1@contoso.com icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"
Once the keys are set up, you won’t have to enter the password when you connect to the remote server using SSH(unless you have set up a passphrase before).
How is the SSH protocol used in IT Asset Management?
The SSH protocol is used in IT Asset Management processes in many different ways. They’re used to access systems remotely and securely. It can be used to execute commands remotely or deploy software updates and security patches remotely to devices. They’re also used to securely manage network infrastructure as well as networking devices like routers, firewalls, and more.
And SSH key authentication is used to securely give access to different assets across an organization. Since the entire communication is encrypted, even if someone eavesdrops, they can’t decrypt the data packets and the communication is safe.
This means that managing the SSH keys becomes a necessary part of asset management. The absence of robust key management presents a security risk, as unused keys and keys with unnecessary privileges may find their way to bad actors.
Considering the security risk they present, SSH keys have to be considered just like credentials or passwords.
How to safely manage SSH keys in your organization
The first step is to create an inventory of all the keys used in the organization. Find out who is using them as well as the assets the keys are attached.
The second step is to find out the unused keys and remove them. You should also explore if the keys are granting more privileges than required; if so those keys must be removed and replaced using the principle of least privilege.
Implement key-rotation. Make sure that the keys are changed periodically just like passwords. Another major common issue is that SSH keys are often hardcoded into files or applications. These may simplify processes, but they can present a backdoor into important systems or data. It’s best to treat these keys like the others and rotate them periodically.
Frequently asked questions
What is the SSH or Secure Shell protocol?
SSH or Secure Shell is a protocol used to send and receive encrypted communication between two devices. The protocol uses symmetric and asymmetric encryption and hashing to protect communication packets from packet sniffing attacks.
What is an SSH key?
An SSH key is used to access a remote server through an SSH connection. The keys come in pairs, a public key and a private key. The public key is kept within the server and the private key is with the user or the client. The server authenticates the user by sending a message encrypted using the public key. If the user can decrypt the message, the server accepts that as proof that the user has the private key.
What is the difference between SSH and SSL/TLS?
With SSH, the goal is to communicate securely with a remote server, and the server has to ensure that only authorized users are communicating with it. The client has to prove to the server that they are who they claim they are.
With SSL, the goal is to ensure encrypted communication between a server and a user, but there’s no need to verify or authenticate the user. The goal of an SSL Certificate is to ensure that the server is the one the user is trying to access and that the communication packets are not tampered with.
