Skip to main content

Bastion Host Configuration for Cluster Authorization

This guide describes configuring a bastion host and applying firewall rules to secure SSH access to Forward Cluster version 15 or later.

Prerequisites​

  • A dedicated Linux-based virtual machine to serve as the bastion host (this guide uses Oracle Linux v9).
  • The bastion host should be configured with your organization’s preferred authentication method (e.g., LDAP, TACACS).
  • Ensure the bastion host and all cluster nodes are configured to use the same NTP server for consistent time synchronization.

Step 1: Configure Cluster Nodes with Restricted Firewall Rules​

Each node should use nftables to restrict inbound traffic to only the necessary ports and allow access only from the bastion host and other cluster nodes.

1. Edit /etc/nftables.conf​

To restrict open ports, replace its contents with the following:

include "/etc/nftables/ssh.nft"

table inet filter {
  chain input {
    type filter hook input priority filter; policy accept;
    ct state established,related accept          # Allow outgoing traffic
    icmp type echo-request accept                # Allow ping
    jump allow_ssh
    # Allow HTTP/HTTPS
    tcp dport { 80, 443 } ct state new accept
    # Allow K0S components
    tcp dport { 2380, 4789, 6443, 8132, 9443, 10250 } ct state new accept
    udp dport 4789 accept
    iifname "eth0" drop                          # Drop other inbound traffic on eth0
  }
}

2. Create the SSH Access Rule File​

Create /etc/nftables/ssh.nft with the allowed IPs:

table inet filter {

  set allowed_ips {
    type ipv4_addr
    # flags interval  # Uncomment for CIDR ranges; comment for individual IPs
    elements = { BASTION_IP, CLUSTER_NODE_1, CLUSTER_NODE_2, CLUSTER_NODE_3 }
  }

  chain allow_ssh {
    ip saddr @allowed_ips tcp dport ssh accept
  }
}

Replace placeholders (BASTION_IP, CLUSTER_NODE_1) with actual IPs, including the IP of the node you are configuring, as in the following example.

table inet filter {

  set allowed_ips {
    type ipv4_addr
    # flags interval  # Uncomment for CIDR ranges; comment for individual IPs
    elements = { 192.168.1.3, 192.168.4.7, 192.168.4.8, 192.168.4.9 }
  }

  chain allow_ssh {
    ip saddr @allowed_ips tcp dport ssh accept
  }
}

3. Reload the nftables Ruleset​

warning

Reloading the ruleset will block SSH from any IP not listed in allowed_ips.

Run the following commands to reload the nftables ruleset.

sudo nft flush ruleset
sudo systemctl restart nftables.service

SSH Authentication to Cluster Nodes​

Option 1: Password-Based Authentication​

By default, cluster nodes allow password-based SSH login.

Username: forward
Password: changeme

It is recommended that the forward user change the default password after logging in. Use your actual password when configuring the bastion-host-based management flow. Using this option, a user would have to provide credentials when logging into the nodes of the Forward Cluster from the Bastion host.

Option 2: Key-Based Authentication​

The Forward Cluster supports key-based authentication, allowing users to log in using a secure key pair instead of a password. This guide uses an ED25519 key as an example.

1. Generate an SSH Key on the Bastion Host​

Log in to the bastion host and run the following command to generate a new key pair:

ssh-keygen -t ed25519 -C "user1@team.company.net"

When prompted, specify a custom file name (e.g., user1.key) or press Enter to use the default. This creates a public/private key pair named user1.key and user1.key.pub. For an extra layer of security, you may want to use a passphrase to protect your private keys on the bastion host.

Generating a new key

2. Copy the Key to Each Cluster Node​

Install the public key on each node using:

ssh-copy-id -i user1.key forward@<node-ip>

Repeat this command for each node in the cluster.

3. Connect Using the SSH Key​

With the key installed, use the following command to log in.

ssh forward@<node-ip>

Revoke a Key​

Remove the corresponding entry from the ~/.ssh/authorized_keys to revoke access. Each entry appears as a single line that ends with the comment specified when creating the key (-C flag).

For example:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF2kV... user1@team.company.net
warning

Do not remove the inter-cluster-key, as it is required for internal cluster operations.

Optional: Limit Concurrent SSH Sessions​

For additional security, you can restrict the number of concurrent SSH sessions per user by editing MaxSessions in /etc/ssh/sshd_config.

For example, MaxSessions 1 limits each user to a single active SSH session.