SSH PermitRootLogin

filippoclikkami

New Member
Dec 21, 2023
15
2
3
Hi, i'm thinkeng about to set off ssh root login on my pve for security reasons. I read in other thread on the forum that this can cause some problems?
Is it true? What kind of errors can i encounter?
Thanks
 
Hi,

see these sections of the documentation [0] [1], to check if you want to take this kind of measure. At least if you want to cluster PVE nodes you have to keep the root login (who else would be allowed to live migrate vm disks from root-owned filesystems onto another computer's root-owned filesystem?).

On the other hand -- what kind of security gain would you expect to achieve by disabling ssh root login? You will still be able to log in as root from the webinterface. So a good password rocks anyway :)

This wiki article might be of interest for you though [2] (fail2ban brings ssh blocking for free to my knowledge).

If you run your PVE on a private network that you control, you might just stay with the standard settings for convenience sake. If you run it in a public space, you will have to take more sophisticated measures (VLANs, VPN connections, proper firewall setup, not using a flat network hierarchy, etc) to properly secure your systems anyway.

Best,
Daniel

[0] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_requirements
[1] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_role_of_ssh_in_proxmox_ve_clusters
[2] https://pve.proxmox.com/wiki/Fail2ban
 
Last edited:
Hi,
Pve is a single node and exposed on internet. Webinterface permits root log in but it has also 2FA authentication.
It has a good password and a non standard ssh port, it's just to further reduce the chances.
So in this specific case can it gives errors?

Anyway thank you for the links and the fail2ban advice, i think is the best choice.
 
I would not disable root login via SSH since it can cause issue later when you forgot its because you disabled root login via SSH.
What I do recommend (and do on all my systems and users) is disabling password authentication for SSH.
This way the can only login if they add there public key and have the private key.
This makes guessing impossible.

https://www.cyberciti.biz/faq/how-to-disable-ssh-password-login-on-linux/
 
It has a good password and a non standard ssh port, it's just to further reduce the chances.
So you already changed the SSH port? Then it does not matter if you disable the root login, you already broke the system logic (which does not matter so much in a single node setup).

i think is the best choice.
a VPN may be the best choice of if you're not going with VPN, please take a look at knockd.
 
Another barrier (changing the SSH port is not that useful, as scanning the full port range of a host is not much effort), is to use the firewall to limit the source IP addresses from which SSH access is allowed. This only works if your source IP address is static.
So if your ISP is changing your public IP regularly…. not so useful unfortunately -> VPN?
 
Why the hell would you have PVE management WebUI exposed on internet without any protection?
At least get it behind a VPN or a reverse proxy with proper authentication and malicious IP banning.
 
  • Like
Reactions: Johannes S
Hi and thank you to every one, this is a particular case. Every of our pve obviously has firewall, this is a client's server, unfortunately I can't install a firewall or have a VPN access (at least for now). In this case what is the best option, in addition to those already adopted? Are Fail2ban and disabling password authentication for SSH sufficient in your opinion?
 
If you have the permissions to setup fail2ban and reconfigure ssh you should also be able to setup wireguard, nftables or pves firewall (which is basically a frontend to nftables) in a sufficient way.
 
this is a client's server, unfortunately I can't install a firewall or have a VPN access (at least for now). In this case what is the best option,
It depends on your role. IF you are in a position of responsibility, you explain to your client that their server control interface should not be exposed to the internet. full stop. if you dont know why, you should probably not accept a position of responsibility.

If the client doesn't care- then you can proceed to just do what you were doing. If the client has any sense whatsoever you would place the server behind an actual firewall and use a vpn to gain entry for control purposes, and nat for inbound services.

--edit if it were me, and the client didnt care- I'd run; I wouldnt want any part of that shitshow.
 
Last edited:
  • Like
Reactions: Johannes S