SSH Jump Server

SSH Jump Server
ssh-jump-server-concept

Introduction     

In recent times, there is an increasing need for organizations to give employees access to their IT facilities due to the ongoing Covid restrictions ( such as work from home )  in place and in other cases grant access to external parties like clients, vendors  who wants to troubleshoot and fix issues with the IT Infrastructure remotely.
 
More so, is the need for multiple manage SSH access to the company’s Linux servers, Routers, Switches, while meeting regulatory and security compliance.
 
This need led to the emergence of the SSH Jump Server concept.
It is a secure intermediary server where all your system administrators would login in first via SSH before getting to access the remote devices such as Linux instance, Routers, Switches etc. The purpose of having the SSH Jump server is to improve security and consolidate SSH user activities to a single point hence better security and accountability. SSH  Jump server is also known by the name SSH Jump Box, SSH Jump Host & SSH Gateway.

What is SSH Jump Server and how does it work?                               

An SSH Jump Server is simply a single, hardened server that you “jump” through in order to access other servers or devices on the inner network.
Sometimes called a SSH Jump host , or SSH Jump server or  ssh bastion host or a relay host, it’s simply a server that all of your users can log into and use as a relay server to connect to other Linux servers, Routers, Switches and more. Therefore, a jump server is a server inside a secure zone, which can be accessed from a less secure zone. It is then possible to jump from this host to greater security zones.
 
In other words, it is an intermediary host or an SSH gateway to a remote network, through which a connection can be made to another host in a dissimilar security zone, for example a demilitarized zone (DMZ2). In short it is intended to breach the gap between two security zones. This is done with the purpose of establishing a gateway to access something inside of the security zone, from the DMZ
 
The SSH Jump Box bridges two dissimilar security zones and offers controlled and monitored access between them.
 
For users accessing your secure network over the internet, the jump host provides a highly secured and monitored environment especially when it spans a private network and a DMZ with servers providing services to users on the internet.
 
Furthermore, a classic scenario is connecting from your desktop or laptop from inside your company’s internal network, which is highly secured with firewalls to a DMZ. In order to easily manage a server in a DMZ, you may access it via a jump host.
 
Therefore, a jump host is a server inside a secure zone, which can be accessed from a less secure zone. It is then possible to jump from this host to greater security zones. An example would be a high security zone inside a corporation. The policy guide states that this zone cannot be accessed directly from a normal user zone. Hence, in a DMZ off the firewall protecting this zone you have a jump host.
 
Connections are permitted to the ssh jump host from the user zone, and access to the secure zone are permitted from the jump host.
 
More often, there is a separate authentication method for the jump host fortified with multi factor authentication, Single Sign On ( SSO ) , Radius  & more. 

How to Configure an SSH Jump Server
  • Using OpenSSH
    A basic ssh jump server with limited features and functionalities  can be configured using OpenSSH packages  that available by default on most Linux distributions. In the example below, we will just use the basic ssh command line to proxy a ssh connection to the remote server via a intermediate jump server.
ssh -J jump_machine remote_machine

If the -J option is not available use the -W option to pivot the connection through an intermediate bastion host.

ssh -o ProxyCommand="ssh -W %h:%p bastion.gateway.org"  remote.server.org

With the OpenSSH 7.3,  the easiest way to pass through hop through intermediate one or more jump hosts is  using the ProxyJump directive ssh_config

Host remote server
HostName 192.168.0.177
ProxyJump [email protected]:22
User devops

Multiple jump hosts can be chained as well

Host remote server
HostName 192.168.0.177
ProxyJump [email protected]:22, [email protected]:22
User devops

 

Do refer the article SSH Proxy and SSH JumpHost  for configuring  a basic jump server that is very limited in feature and functionality when compared to the modern day ssh  jump host solutions.

  • Using Ezeelogin SSH Jump server
     Ezeelogin is a much more powerful and advanced SSH Jump host software solution and  can be deployed quickly.  It has powerful features that  makes managing hundreds of Linux devices and granting ssh access to these device a piece of cake.  Do refer the article to  configure a ssh jump server quickly on your premise or on cloud.                                                    

Why do you need a SSH Jump server solution to manage ssh access? 

The OpenSSH based jump server is clearly not enough to meet the modern day requirements  of an IT enterprise. The challenges for  the enterprise are constantly changing and dynamic . On day , it could be from maintaining security, granting ssh access to the users to designated server and that too for particular time and on another day it could be the security compliances that needs to be met at the time of a Linux servers infrastructure audit.
The modern day  SSH Jump host solutions are designed to address the challenges faced by an IT enterprise when it comes to  security and to meet various security compliances like PCI DSS, NIST, ISO 27001 and more.
 
The modern day ssh jump server  software has the  following features  and more.
  • Identity and Access management (IAM)
  • Privileged Access management (PAM),
  • Role Based Access Control to delegate access to Linux servers and Network devices.
  • Two factor authentication methods  like Google Authenticator, DUO Security 2FA, & Yubikey in SSH.
  • Integrates with Windows Active Directory, OpenLDAP, Redhat IDM.
  • Supports SAML for  Single Sign On.
  • Support RADIUS Authentication to access network devices such as Routers and Switches
  • Password Manager
  • SSH key rotation, 
  • Automated root password management

CONCLUSION

IT Enterprises that use a SSH Jump Server solution in improving security of their critical IT asset and in meeting various mandatory security compliances  (which would otherwise prove very costly in case of a breach),  are more likely to succeed due to the improved operational efficiency, digital security, hence more successful business for the company’s end customers.

References

SSH Proxy and SSH JumpHost

SSH Keybased Authentication on Linux Servers

Secure SHell or SSH is a network protocol that helps the users, mainly system administrators to securely access the remote computer over an unsecured network. SSH is the current de-facto method of remote server administration. Before SSH, telnet and rlogin were the primary tools for remote administration. SSH was a game-changer in the computing industry. It offered almost impenetrable security through efficient encryption and enabled server administrators to manage their servers remotely with absolute confidence.

An user can SSH to the remote machine using either password authentication or Key based authentication. Let’s see how the SSH authentication works.

SSH Authentication

The SSH suite consists of two parts SSH server and SSH client.

>> The SSH server runs SSHD daemon and listens on port 22 by default. The server accepts connection requests from machines that have an ssh client installed.

>> SSH clients are part of all Unix or Linux distributions. But if you are a windows user, you may need to use ssh clients such as PuTTY for making ssh connections.

The primary condition for anyone to access a remote server through ssh is a user account with shell access on the server.

Password Authentication in SSH

The command to access your ssh account is

ssh [email protected]

Now, the system will ask you to enter the password of the ssh user. If the password matches, it permits the login. Password authentication is simple and popular. But it creates some administrative headaches for the server administrators. An ideal password should be a long string of letters, numbers, and special characters. To ensure its security, one should change the passwords at regular intervals. Remembering such a cryptic password is practically impossible for our human brain. So the majority use easy-to-remember passwords or keep them in shareable documents. This lackadaisical attitude encourages attackers to access your login information and perform malicious activities on the server. Besides, the requirement to enter the password manually makes task automation quite challenging.

SSH derives its security from three factors, Asymmetric encryption during authentication, session establishing using symmetric encryption, and hashing to ensure data security during transmission. As the name implies, Symmetric encryption uses the same method for encryption and decryption. So if someone gets access to the key, they can decrypt the messages.

SSH KEYs and Asymmetric encryption

What is SSH Keys?

  • SSH Keys (Secure Shell Keys) are used as an authentication credential to securely access the remote servers using the SSH protocol
  • SSH key authentication works on the principle of asymmetric encryption.
  • SSH Keys always comes in pairs (public-key and private key)
  • SSH Keys comprise Public and Private keys which can be generated using the ssh-keygen command
  • System uses different keys for encryption and decryption. So even if one gets access to the encryption key, they can not decrypt it.

How does SSH Key based authentication work?

The primary requirement for password-less ssh access is a valid private key in the client machine and the public key in the authorized_keys file. All SSH servers have a file named “authorized_keys.” It contains the public key of all ssh clients with whom it had a previous ssh session. If it is your first ssh connection attempt with the server, it will ask for your confirmation for including your public_key in this file.

  1. The client machine shares its public key with the server during the initial handshake.
  2. The server checks whether the key is present in its authorized_keys file.
  3. Then the server generates a random number and encrypts it using the client’s public key and challenges the client to decrypt the number.
  4. The challenge string contains the mutually agreed session-id as well.
  5. The client decrypts the number using its private key.
  6. It then generates an MD5 hash using the number and session id.
  7. When the reply reaches the server, it computes the checksum using the number and session id.
  8. If the hash values match, a connection is established.

How to configure SSH Key based authentication on Servers?

  1. Generate SSH key pair using the command ssh-keygen
~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):

At the following prompt, accept the default or enter the passphrase and press Enter.

Enter the passphrase (empty for no passphrase): passphrase
Enter the same passphrase again: passphrase
Your identification was saved in /home/user/.ssh/id_rsa.
Your public key was saved in /home/user/.ssh/id_rsa.pub. 
The key fingerprint is this value:

2. Ensure that the SSH Keys were generated.

:~$ ls -l .ssh/
total 21
-rw------- 1 user user 2655 Mar 30 14:42 id_rsa
-rw-r--r-- 1 user user 578 Mar 30 14:42 id_rsa.pub

3. Enable Key based authentication on the ssh configuration file by changing “PubkeyAuthentication yes”

vi /etc/ssh/sshd_config
  1. Restart the SSH service
  2. Add the public key (id_rsa.pub) to remote server’s authorized_keys file /.ssh/authorized_keys. Using the ssh-copy-id command, we can easily add the public key to the remote server.
ssh-copy-id -i id_rsa.pub [email protected]_server
  1. Disable PasswordAuthentication on the ssh configuration file.
  2. Now you should be able to access the remote server by executing the command from your machine.
ssh [email protected]

Apart from ssh user access, Cert-based authentication is the default option for VM management in all major cloud platforms such as AWS, Google Cloud, and Azure.

Comparing SSH Keys ( RSA, DSA, ECDSA, and EdDSA )

The encryption algorithm defines the security of each encryption. The most widely adopted encryption algorithms for SSH key generation are RSA, DSA, ECDSA, and EdDSA.

1. RSA (Rivest-Shamir-Adleman)

RSA is the default key type when generated using the ssh-keygen command. It is one of the oldest cryptographic algorithms and is considered the gold standard of asymmetric encryption algorithms. It uses the prime factorization method for encryption. RSA is capable of data encryption, digital signature generation, and verification. RSA is known for its compatibility with all versions of SSH and the robust security it offers. Even though digital signature verification is much faster, RSA is slower for signature generation. The longer keys offer good security, but it significantly reduces the performance.

2. DSA (Digital Signal Algorithm)

Digital Signature Algorithm (DSA) ensures each message’s genuineness through a complex hash value. The algorithm requires random, secret, unpredictable, and non-reusable numbers for the signature generation. Even a tiny compromise in these parameters can weaken the security significantly. Hence the quality of the Random Number Generator, RNG, is a defining element for DSA. In DSA, signature generation is faster, but verification is slow. It doesn’t offer any data encryption either. For an equal-sized key, both RSA and DSA offer similar security. But the vulnerability incidents are higher for DSA and are not recommended in their original form. OpenSSH 7.0 and higher versions do not support DSA, and it may create compatibility issues.

ssh-keygen -t dsa

3. ECDSA

ECDSA (Elliptical curve Digital Signature Algorithm) is an elliptical curve implementation of DSA. The advantage of ECDSA is that it offers similar security as RSA, with almost half of its key size. The small key size significantly improves performance. Since its modified version of DSA, the vulnerability associated with RNG is also present in ECDSA.
All the current SSH clients support ECDSA.

ssh-keygen -t ecdsa

4. EdDSA (Elliptic Curve Digital Signature Algorithm)

EdDSA (Edwards-curve Digital Signature Algorithm) offers exceptionally high levels of data security by generating different signatures for each data. It offers faster signature generation, verification, and batch verification with minimal usage of computational resources. The keys and signatures generated by EdDSA are small and offer security on par with RSA and EcDSA. EdDSA is relatively new and has not yet proven its mettle through vigorous scrutiny like RSA. Similarly, compatibility issues are much higher.

ssh-keygen -t ed25519