SSH hardening — key-only auth, port, listen-address, mgmt VRF

SSH is the operator’s primary access path to a VyOS router. Every hardening change to SSH reduces the attack surface — but every change also raises the risk of locking the operator out. The discipline: harden SSH only with an out-of-band access path ready, change one setting at a time, and validate after every commit.

This lesson covers the SSH hardening checklist for VyOS 1.5 LTS: disable password authentication, enforce key-only auth, move off port 22, bind to a management VRF, restrict to operator subnets, and the production failure modes where the operator locks themselves out.

The SSH access model

flowchart LR
  OP["Operator workstation<br/>SSH client"] -->|TCP 22| R1["VyOS router<br/>mgmt VRF"]
  OP -.->|TCP 2222| R1
  R1 -.->|reject| R1
  R1 --> AUDIT["Auth log<br/>syslog"]
  R1 -.->|OOB| CON["Console<br/>serial"]

The operator accesses the router via SSH over the management VRF (an isolated L3 path). The SSH daemon listens on a non-default port (typically 2222 or higher) and only accepts public-key authentication. Every login attempt — successful or not — is logged to syslog and exported to the central server.

The hardening checklist

The production hardening checklist:

• Disable password authentication — set service ssh password-authentication disable
• Disable root login — set service ssh root-login disable
• Disable challenge-response — set service ssh disable-challenge-response
• Disable PAM — set service ssh use-pam disable
• Disable X11 forwarding — set service ssh x11-forwarding disable
• Bind to mgmt VRF — set service ssh vrf mgmt
• Restrict port — set service ssh port 2222
• Restrict listen-address — set service ssh listen-address 10.0.0.1
• Configure ciphers and MACs — restrict to modern algorithms

Disabling password authentication

configure
set service ssh password-authentication 'disable'
set service ssh root-login 'disable'
commit
save

After commit, ssh vyos@<host> with a password fails:

$ ssh vyos@203.0.113.1
Permission denied (publickey).

Only public-key authentication succeeds.

Configuring SSH keys

The operator generates a key pair on the workstation:

ssh-keygen -t ed25519 -C "operator@workstation"
# Public key is at ~/.ssh/id_ed25519.pub

The public key is installed on the VyOS router:

configure
set system login user vyos authentication plaintext-password '<set a temp password>'
commit
save

The operator copies the public key to the router and installs it:

cat ~/.ssh/id_ed25519.pub | ssh vyos@203.0.113.1 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Or via the VyOS configuration tree:

configure
set system login user vyos authentication public-keys operator@workstation key '<paste the public key here>'
set system login user vyos authentication public-keys operator@workstation type 'ssh-ed25519'
commit
save

After commit, the operator can SSH with the key without a password.

Binding to a management VRF

configure
set interfaces dummy mgmt address '10.0.0.1/29'
set vrf name mgmt table '1000'
set service ssh vrf mgmt
commit
save

The SSH daemon listens on the mgmt VRF. The mgmt VRF is an isolated L3 path used only for management traffic; it does not carry production traffic. An attacker who compromises the production VRF cannot reach the SSH daemon without crossing the VRF boundary.

Restricting the listen-address

configure
set service ssh listen-address 10.0.0.1
commit
save

The SSH daemon listens only on 10.0.0.1 (the management VRF address). The daemon does not listen on any production interface.

Combined with the VRF binding, this isolates SSH to the management network. An attacker scanning the production interfaces sees no SSH service.

Changing the port

configure
set service ssh port 2222
commit
save

The SSH daemon listens on TCP 2222 instead of the default 22. The operator connects with ssh -p 2222 vyos@<host>.

This is security through obscurity — a determined attacker who knows the port will connect regardless. But moving off port 22 reduces noise from opportunistic scanners; the operator’s auth log is cleaner, and the actual attack surface is smaller.

Restricting allowed ciphers and MACs

configure
set service ssh ciphers ['chacha20-poly1305@openssh.com', 'aes256-gcm@openssh.com', 'aes128-gcm@openssh.com']
set service ssh mac ['hmac-sha2-512-etm@openssh.com', 'hmac-sha2-256-etm@openssh.com']
set service ssh key-exchange ['curve25519-sha256', 'curve25519-sha256@libssh.org', 'diffie-hellman-group18-sha512']
commit
save

This restricts SSH to a tight cipher list. The default list is already strong; tightening further is rarely needed but is sometimes required by compliance (PCI-DSS, NIST).

How the result is validated

show configuration service ssh
show system login user vyos authentication public-keys
ssh -vv -p 2222 vyos@10.0.0.1

The first shows the SSH configuration tree. The second shows the installed public keys. The third shows the SSH handshake — the cipher, the MAC, the key exchange algorithm, and the authentication method.

A working hardened SSH daemon:

• Listens only on the management VRF address (and the configured port)
• Accepts only public-key authentication
• Rejects password authentication
• Logs every authentication attempt to syslog

vyos@R1:~$ show configuration service ssh
vrf mgmt
listen-address 10.0.0.1
port 2222
password-authentication disable
root-login disable
disable-challenge-response

How it fails

The production failure modes a routing engineer must recognise:

• Key not installed before disabling password auth. The operator disables password authentication before installing their key. The operator cannot SSH. The fix: install the key FIRST, then disable password auth.
• Mgmt VRF has no route back to the operator. The operator binds SSH to the mgmt VRF but the operator’s workstation cannot reach the mgmt VRF. The fix: verify reachability before the binding change.
• Wrong listen-address. The operator configures listen-address 10.0.0.2 but the address is on a different interface. The SSH daemon listens on an unreachable address. The fix: verify the listen-address is reachable from the operator’s workstation.
• Port conflict. The operator changes the SSH port to 2222, but another service already binds 2222. The SSH daemon fails to start. The fix: check for port conflicts with netstat -tlnp.
• Single key lost. The operator’s only key is lost. The operator cannot SSH. The fix: always have at least two keys, with revocation capability.
• Cipher mismatch. The operator’s SSH client uses an outdated cipher that the hardened server rejects. The fix: update the SSH client.

Rollback

The recovery from a locked-out SSH configuration:

• Wrong listen-address: connect via OOB and fix the address.
• Wrong port: connect via OOB on the original port (port 22) or fix the port.
• Wrong VRF: connect via OOB and remove the VRF binding.
• Password auth disabled with no key installed: connect via OOB and re-enable password auth or install the key.

The VyOS configuration rollback (rollback N) restores the previous revision if the change locks the operator out.

Production discipline

Cross-course references

• XLVII-VyOS-MgmtPlane (vyos-xlvii-02-api-auth, vyos-xlvii-03-source-restrictions, vyos-xlvii-04-oob-access) cover the rest of the management plane hardening.
• IV-VyOS-Install (vyos-iv-04-console-and-management) covers the initial console setup.
• XV-VyOS-VRFs (vyos-xv-02-vrf-config) covers the VRF configuration this lesson uses.
• XXVI-Linux-SSH (Linux course) covers the underlying SSH server configuration in detail.

Quiz