Secure Shell (SSH) is a cryptographic network protocol that provides a way to securely communicate over unsecured networks. It uses encryption to safeguard data from unauthorized access or tampering, which is why it’s the standard for secure remote access, file transfer, tunneling and port forwarding.
SSH can be made vulnerable by weak passwords, poor key management, incorrect or insecure configurations, forwarding risks and Man-in-the-Middle attacks. To mitigate these risks, anyone using SSH should adhere to the following best practices.
Use SSH keys instead of passwords
SSH passwords should never be used to grant access to targets because they’re easy to compromise via brute force attacks, phishing and human error. Instead, users should leverage SSH keys — a pair of cryptographic keys that secure the communication between the client and server.
An SSH key pair consists of a private key, which is confidential and stored on the client machine, and a public key, which is shared freely and stored on the server where the client wants to connect. The public key is used to encrypt messages that can only be decrypted by the corresponding private key. When a client attempts to connect to an SSH server, there is a handshake protocol that allows the server to validate that the client possesses the private key associated with the stored public key. If the handshake completes, then access is granted.
SSH keys are considered more secure for accessing SSH targets than passwords due to their use of asymmetric cryptography, which creates a robust authentication system. Unlike passwords, SSH keys are long random strings,, making it harder for hackers to crack them with brute force or password-dictionary attacks. And when private keys are properly stored locally on the client machine, it reduces the risk of interception during transmission.
While SSH keys are better than passwords, they have their own set of risks, especially if there isn’t a good system in place to properly manage them. Administrators must grant, rotate and revoke keys as organizations grow, reorganize and deal with employee turnover. For optimal security, administrators should grant just-in-time access to SSH keys and monitor user activity and commands executed on SSH targets.
What about SSH certificates?
A better solution is certificate-based authentication, which uses a public key alongside a certificate instead of a private key. A certificate authority (CA) is a trusted entity that issues certificates to establish a cryptographic link between an identity and a public key. This reduces the risk of private key theft or loss and eliminates the hassle of key management for administrators.
When using a CA solution, all servers trust the CA. The CA then issues certificates for users, eliminating the need to specify which server trusts which key. Instead, servers trust the CA, and the CA determines user access to specific servers. If the CA doesn't trust a user for a particular server, it won't issue a certificate. Additionally, CAs can issue short-lived certificates, restricting access to a defined time period and preventing reuse beyond that timeframe.
Don’t rely on a single root of trust
The problem with a CA is that it’s a single root of trust. If this CA is compromised, and the key it uses to sign certificates is stolen, then all of the servers that trust the CA can be compromised.
Adding a second root of trust, like BastionZero, requires that both roots authenticate the user before they can gain access to the desired SSH target. When multiple roots of trust are required, the target will remain locked down even if one root of trust is compromised, significantly improving the security of targets.
Customize the default SSH settings
Changing default SSH settings can enhance security by making it more challenging for attackers to exploit known configurations and vulnerabilities. Each company should tailor these to their unique needs, but here are some customizations to consider.
- Change the default port: Many automated attacks focus on default settings, so if SSH servers must be on public IPs, using a non-standard port can reduce the visibility of the SSH service. However, this is not a panacea — it just stops widespread port scans from easily locating servers. It’s far better to not have SSH ports open on public IPs.
- Put SSH servers on private IPs: There are many examples of SSH ports on public IPs being scanned and SSH being breached to install Bitcoin miners. Putting SSH servers on private IPs and securing them with SSH keys instead of passwords can help prevent this.
- Disable root login: Users should log in with a regular account and then switch to the root user using sudo or a similar mechanism. This forces attackers to guess both a valid username and password (at minimum), making it more difficult for them to launch successful brute force attacks.
- Disable password-based authorization: As discussed, key or certificate-based authentication is much more secure than using a password, which can be vulnerable to various attacks.
- Restrict SSH access: Not everyone in a company needs access to SSH targets. Grant just-in-time access to approved users to reduce potential entry points for attack.
Implement SSH best practices
There are two ways to implement the SSH best practices outlined above: with open source software or with a managed service.
Secure SSH with open source
OpenPubkey is open source software created by BastionZero in partnership with Docker and the Linux Foundation. It lets IdPs act as CAs to cryptographically bind public keys to identities in OpenID Connect (OIDC) SSO interactions. This completely eliminates the need for passwords or private SSH keys and establishes multiple roots of trust to greatly enhance the security of SSH targets.
To protect your SSH targets with OpenPubkey, check out the repository on GitHub.
Secure SSH with BastionZero’s managed service
BastionZero is the most advanced access tool for organizations that use SSH. It eliminates SSH key management, supports least privilege access and enables companies to meet SOC 2 and ISO 27001 requirements. It uses the existing SSH config file to identify and secure hosts in a matter of minutes. Users simply log into BastionZero, select the hosts they want to secure and install and register the BastionZero agent on the chosen SSH target(s).
Learn more about securing SSH targets and implementing best practices with BastionZero here.
See BastionZero in Action
BastionZero connects teams to resources and requires no additional infrastructure to deploy or manage. It is the first—and only—cloud-native solution for trustless access providing multi-root authentication while maintaining zero entitlements to your systems.
With BastionZero, you can reclaim your architecture from over-privileged third parties and ensure that the right people have access to the right resources at just the right time—every time.
Schedule a demo now to see how you can trust less and access more with BastionZero.
