Understanding SSH bastion: use cases and tips

Hi! I am Canözüm and I’ve been working as a Solutions Architect at Scaleway for a year. I provide our clients with technical guidance during their migration to Scaleway, and I’ve noticed that one of my clients’ main concerns is server access security. To improve this, a good solution is to implement SSH bastion into your infrastructure.

To launch an application in the cloud you need to be able to access the servers on which it is hosted. There are several ways you can do that: via RDP for a Windows server, VNC for a server with a graphical interface, and SSH to access the terminal. An SSH (Secure Shell) access is sufficient for launching an application—all you need is an SSH key. Find out how to generate SSH keys here.

To monitor and control access to servers within your infrastructure, and keep servers from being exposed on the internet, you need to centralize them. Which leads us to the topic of this article: implementing SSH bastion.

Definition and uses

SSH bastion is a jump server (or gateway server) that gives access to Instances within a private network using the SSH protocol. You can log into the Instances of your private network via a single, centralized, entry point. You can also monitor user access to the infrastructure.

Once this virtual machine is in place, you will need an SSH configuration for each server within the private network. If you’d like to know more about ssh_config, check out this article.

Best practices on security

Even if SSH bastion centralizes infrastructure access, you still need to take certain measures to better secure the servers. If you skip the SSH configuration step, you risk giving unrestricted access to all servers. According to the principle of least privilege (PoLP)—giving minimum levels of access to a user or resource—each machine within the private network should have an SSH configuration.

Using SSH bastion also means having a strict IT security policy. Everyone within the organization must follow the best practices established by the IT teams. As SSH keys do not have an expiration feature, you need to frequently monitor the keys that give access to the bastion. The best practice is to also add an extra level of security to enable user identification.

It is also tempting to use wildcards on the SSH configuration, such as Host * ForwardAgent: yes in order to authorize access to all servers. However, granting the key holder unrestricted access to all the machines would cause a security breach.

How to use SSH bastion on two-tier architectures

Open-source tools for SSH bastion

When you use two-tier architectures—an application hosted by a series of Instances and a database—it is good practice to keep the different tiers from being exposed on the internet. If those tiers are hosted within a private network, you’ll need access to manage the applications. The best course of action is to centralize SSH accesses, via SSH bastion, for example.

To do this, you can rely upon open-source SSH jump tools such as Teleport, Boundary by Hashicorp, or simply OpenSSH.

Here is an example of a two-tier architecture:

Scaleway’s SSH bastion

By using the Scaleway console, you can implement SSH bastion in a single click. When you use the SSH bastion feature of the Public Gateway, all the keys that are linked to your project are automatically loaded onto the bastion.

Conclusion

When combined with good security practices, SSH bastion is a powerful tool that allows you to create a single entry point to your infrastructure. You can choose between several open-source tools or managed solutions offered by cloud providers so you don’t have to worry about hosting and maintenance.

For more information on Scaleway’s VPC and SSH bastion, you can read our Quickstart on VPC or our tutorial on how to use SSH Bastion.