HOWTO: Changing SSH Port with Proxmox Cluster

[churnd]

This has been a common question, which I know because I myself have searched for a solution without much luck. It's known that Proxmox Cluster requires SSH to be on port 22 to work & it doesn't support changing it as far as I'm aware. Certain circumstances dictate this might be an issue for a variety of reasons.

I think I've found a workaround: Don't change it, just restrict it with iptables, & add another port. OpenSSH can listen on however many ports you want, so you can leave the default 22 enabled, but also add another non-standard port to the config file & it will listen on both:

This assumes you're starting with an empty ruleset

Read & understand the entire thing before changing anything!

Edit /etc/ssh/sshd_config & add the additional Port line under Port 22. Save & close the file (Note: this is just a snippet of the top of the file, not the entire file):

 # Package generated configuration file # See the sshd_config(5) manpage for details
 
 # What ports, IPs and protocols we listen for
 Port 22
 Port 2222
 # Use these options to restrict which interfaces/protocols sshd will bind to
 #ListenAddress ::
 #ListenAddress 0.0.0.0

From there, restart ssh & verify you can get in over port 2222 before continuing:

service ssh restart

For administrative use, you could use the non-standard port 2222, which could stay open to the world. For Proxmox's cluster purposes, we can restrict port 22 with iptables.

When creating firewall rules, I always use these as a standard baseline (allow all to/from loopback & allow all established connections):

iptables -I INPUT 1 -i lo -j ACCEPT
iptables -I INPUT 2 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Assume 10.0.1.10 is the other Proxmox cluster node. If you have multiple nodes, add one rule per node:

iptables -I INPUT 3 -m conntrack --ctstate NEW -m tcp -p tcp --source 10.0.1.10 --dport 22 -j ACCEPT

Then drop the rest of the connections to port 22:

iptables -I INPUT 4 -m tcp -p tcp --dport 22 -j DROP

Note that I'm using "iptables -I INPUT 2". I'm specifying the rule number so it will go where I want in the INPUT chain, in that case 2. iptables processes rules from top down. If your chain is empty, you can copy & paste. If not, you'll need to adjust accordingly.

These are meant to be done on a running system, hence the use of the -I flag with the rule number after INPUT. If the system is rebooted, the rules will be lost. It is up to you to determine how to make them permanent. I haven't gotten that far myself, but there's plenty of howto's out there for doing that on debian. If you're using a script to load the rules, you'll want to change the -I flag to -A.

It's also possible you could use the new PVE Firewall in 3.3 for this, but I haven't given it a look yet.

If anyone can see a reason why this is a bad idea, please let me know. Thanks!

 

[TCB13]

Thanks for the info, there is also another solution involving changing the default ssh client port. http://jaroker.com/technotes/operat...-port-is-non-standard-root-login-is-disabled/

 

[guletz]

Hi @churnd

The ideea is good, but is not so wise from security perspective. A better ideea is to use your iptables, so you can redirect any new connection on port 2222(from WAN) to port 22(localhost).

 

[bofh]

im curious to know why port 22 should be a problem
changing the port wont do any good security wise

only real good way is using vpns, even if i sound like an old broken record.
all other methoods letting important daemons in the open, no matter if you use fail to ban or similar, are insufficent.

do not forget there always zero day exploits, we dont know if it aint hit ssh daemon one day, or similar.
so let only non priviliged daemons in the open, that way, even if theres an exploit an attacker still have to get root rights from the inside out
before you find out something is off.

also vpn makes your setup more structured and makes more complex even distributed setups a piece of cake.
liek having several far away servers running in one vpn net work, with split dns and an internal dns structure for all your vms and hosts.
with nothing exposed to the internet but needed services

you can even access from a tablet or mobile phone since everyone has now fully vpn support for all kinds of vpns.

and i cant think of any reason why you would need to change ssh ports

 

[guletz]

From security point of view is not a good ideea to use for any daemon a port > 1024 if this daemon is starting under root account. Only root can start a service who can listen on a port < 1024. But a normal user can run a service who will use a port > 1024.

Please do not think at various tools, like split dns/vpn - the security is a PROCESS and not a tool. If you think at various tools you are wrong.

 

[bofh]

umpf, it doesnt matter which port you can start, all ports have to closed except vpn is open.
and openvpn runs chroot without root, it wont matter casue its just routing, doesnt need any system rights, only access to some libs depending on the plugins you use.

no security is a tool ofc. or ebtter a set of tools. from DPI on your real firewall to IDS and honeypots. but in this forum basic closing ports and securing incomming connections seems already a big leap forward.

besides, openvpn is not visible form the outside and wont even answer to anything without the right TA key and hmac auth. so buffer overflows and similar are not easy possible if even possible at all. reason is that the deamon wont even look at anything you send him that doesnt match

and splitdns isnt a security feature but adds to securty too. since you do not have to expose your internal vms and ips to an external dns table plus it enables for some flexible configurations

 

[guletz]

Hi,

My response was for this:

If anyone can see a reason why this is a bad idea, please let me know

Then you add others ideas with ovpn. By the way, if security is a lots of tools, what is happening if you do not have a process that tell/force you to change your ovpn certificate before expiration time?