Proxmox Security Series:SSH Through Firewall
In my effort to find fresh ways to improve SSH security beyond the usual tips and tricks, I looked into using the OPNsense firewall—something I already had—as a gateway for my Proxmox server. The idea was to make this firewall the main entry point for server access. This setup simplifies access but also means that if the firewall has issues, everything does. Although it was an interesting idea, I was initially unsure about how much it would really enhance security. Stay tuned as I dive deeper into this later in the article.
SSH Authentication Keys
Prior to implementing the firewall adjustments, I generated two SSH keys: one for the connection to the firewall and another for the Proxmox server.
## Auth Keys for Proxmox Server
ssh-keygen -t ed25519 -f ~/.ssh/pve
## Auth Keys for OPNsense Firewall
ssh-keygen -t ed25519 -f ~/.ssh/firewall
I admit that using two different keys might seem a bit much, and really, one key is usually enough. But I was curious—could using two separate keys actually make things more secure? I saw this as a chance to test out that idea.
Firewall Modifications for SSH
Configuring the firewall for SSH was straightforward and could be managed entirely through the web interface. Keep in mind that different firewalls offer varying features, so the following is a high-level description of the adjustments I made:
- SSH was enabled on the LAN interface exclusively.
- Root user login was disabled to enhance security.
- Password-based login was disabled, requiring more secure authentication methods.
- A new user account was created, which required administrative privileges for SSH access.
- I selected the preferred shell for the user.
- The SSH authentication key was uploaded to ensure secure access.
These changes successfully enabled SSH access to the firewall, setting the stage for more secure operations.
SSH Jump Command
SSH includes a useful -J switch, which allows routing through a jump server.
## SSH Jump Command
ssh -J <firewall_user_id>@<firewall_ip_address> <pve_user_id>@<pve_ip_address>
As you begin to integrate options like authentication keys, the command can become cluttered. This is where the .ssh/config file becomes invaluable. It allows users to assign aliases to SSH servers and specify options for each connection. For environments with multiple servers, the file can become complex. Using include files within the .ssh/config can help manage this complexity, keeping configurations organized and maintainable.
Configuring SSH with .ssh/config
To streamline SSH commands using configuration files, you can create specific config files for each server, like so:
Config File Name: firewall
# Configuration file for firewall
Host firewall
HostName 192.168.166.1
User sebos
IdentityFile ~/.ssh/firewall
Config File Name: pve
# Configuration file for Proxmox VE
Include ~/.ssh/include.d/firewall
Host pve
HostName 192.168.167.127
User richard
ProxyJump firewall
IdentityFile ~/.ssh/pve
Changes to: ~/.ssh/config
Include ~/.ssh/include.d/firewall
Include ~/.ssh/include.d/pve
With these configurations in place, connecting to your Proxmox server via the firewall jump host simplifies to a single command:
ssh pve
Note:
Storing additional configuration files in the
~/.ssh/include.d/directory isn't mandatory but helps maintain organization and clarity in your SSH setup.
Did It Enhance Security?
My assessment is affirmative. The setup resulted in some interesting outcomes:
- The Proxmox server can no longer be directly accessed via SSH without routing through the jump server—a predicted but significant tightening of security.
- Surprisingly, even from the firewall’s shell, I was unable to initiate an SSH connection to the Proxmox server.
To successfully access the Proxmox server through SSH, the following conditions must be met:
- Physical presence within my LAN network.
- Possession of both sets of my SSH keys.
- Knowledge of the user IDs and server IP addresses, though the
.ssh/configfile simplifies this aspect.
Would I extend this setup to my WiFi or WAN network? Potentially, yes—if I stored my configuration files and authentication keys within an encrypted directory secured by a password, I would consider it feasible and safe to do so.
Here’s a simpler version for a general audience:
Would I create two authentication key files again in the future? Yes, but only if I planned to store them in different places, like one on my local machine and the other on a network share within my own network.
Can This Stop All Hackers?
No security system is perfect. Highly skilled hackers can find vulnerabilities, including Zero Day exploits, in any system. The best strategy is to minimize potential entry points and add layers of security to discourage most attackers.
I’d love to hear about your methods. How do you secure SSH in your network?
Top comments (2)
Have a look at wireguard, you can still use your firewall as the jumphost but I would advise you to deploy a VM on your proxmox-node for that instead, or maybe use a raspberry pi or something small like that and let the firewall do the firewalling.
Wireguard would enable you to access proxmox securely from basically anywhere, you can apply specific rules to that network segment if you would like and have more generic rules on your WLAN and Ethernet-bound devices. It just adds another layer of separation that an attacker have to get past.
And as a bonus, if you route all your traffic over wireguard through your home connection... it's more safe when you travel and use open wireless networks for instance.
Thank you for your feedback and the WireGuard suggestion! It’s great to know it’s supported by OPNsense. I’m a big fan of Doug McIlroy’s philosophy of doing one thing well. Since OPNsense already has built-in SSH capabilities, I thought it would be useful to leverage that. Your idea of adding extra layers of separation with WireGuard and have more generic rules on your WLAN and Ethernet-bound definitely adds another level of security, which is always valuable. Appreciate your insight!