Building a Jump Host

A jump host (or bastion host) is a secure intermediary server used to access machines on a private network that are otherwise inaccessible from the outside. This guide focuses on configuring a jump host for secure SSH access and outlines best practices to ensure a secure environment.

Network Overview

The network typically looks like this:

[ Client ] -----> [ Jump Host ] -----> [ Internal Network ]

The client accesses the jump host, which is exposed to the external network. The internal network remains secure and isolated, with the jump host serving as a controlled gateway.

Configuring the Jump Host

SSH Configuration: Secure Access

The security of the jump host is critical since it acts as the gateway to internal resources. Key SSH configurations include:

Disable Password Authentication: Enforce key-based login to enhance security.

In /etc/ssh/sshd_config, ensure:
```
PasswordAuthentication no
```
Limit User Access: Restrict access to specific users to minimize the attack surface.
```
AllowUsers admin user1 user2
```
Restrict Access by IP: Optionally, allow SSH access only from specific trusted networks.
```
Match Address 203.0.113.0/24
    AllowUsers admin
```
Logging and Monitoring: Ensure SSH logging is enabled for auditing access attempts. OpenBSD, for instance, logs SSH activity by default in /var/log/authlog.

Example from OpenBSD's /etc/syslog.conf:
```
auth.info       /var/log/authlog
```
Adjust as needed to capture detailed authentication logs.

Example Network Layout

Here’s an ASCII representation of a typical setup:

    +---------------------+
    | Client (Public IP)  |
    +---------------------+
              |
       SSH to Jump Host
              |
    +---------------------+
    | Jump Host (Firewall)|
    |     Public IP       |
    +---------------------+
              |
    SSH to Internal Network
              |
+----------------------------+
| Internal Server (Private IP)|
+----------------------------+

The client initiates a connection to the jump host, which forwards the connection to the internal server within the private network.

Setting Up Key-Based Authentication

Key-based authentication should be enforced by copying the public key to the jump host:

ssh-copy-id user@jumphost

Ensure the correct permissions are set on the .ssh directory and authorized_keys file:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Configuring ProxyJump for SSH Clients

The ProxyJump option (-J) simplifies routing through the jump host to internal machines.

Example Command:

ssh -J user@jumphost user@internal-server

This command initiates a connection to jumphost and forwards the SSH connection to the internal server.

To simplify usage, this can be configured in the ~/.ssh/config file:

Host internal-server
    ProxyJump user@jumphost
    User user

This allows connections to the internal server to be made with the simple command:

ssh internal-server

Testing the Setup

After configuring the jump host and client, test the connection from the client:

ssh -J user@jumphost user@internal-server

This command should correctly route through the jump host to the internal server.

Security Best Practices for Jump Hosts

Firewall Configuration: Ensure the jump host’s firewall is configured to only allow necessary services, such as SSH (port 22). For OpenBSD, use pf to restrict traffic:

Example pf.conf rule:
```
block in all
pass in proto tcp from any to (self) port ssh
```
Two-Factor Authentication (2FA): Consider enabling two-factor authentication on the jump host to enhance security.
Monitoring and Alerts: Set up monitoring tools to track SSH login attempts and generate alerts for suspicious activity. OpenBSD’s smtpd can be configured to send alert emails for failed SSH login attempts.
Regular Key Rotation: Periodically update and rotate SSH keys to mitigate the risk of compromised credentials.