[SOLVED] root or not root?

[PmGs]

New on Proxmox, but not on Debian, I'm surprised (that in base) it's proposed to use root as user.
I did find this link https://forum.proxmox.com/threads/disable-root-account.83967/ which seems to conclude that you should keep root, which is confirmed by my first attempts, I haven't managed to create backup storage under a non-root admin.
I'm concerned about opening remote root access, what do you think? What solution can/should I use to secure my server?

Translated with DeepL.com (free version)

 

[Dunuin]

New on Proxmox, but not on Debian, I'm surprised (that in base) it's proposed to use root as user.
I did find this link https://forum.proxmox.com/threads/disable-root-account.83967/ which seems to conclude that you should keep root, which is confirmed by my first attempts, I haven't managed to create backup storage under a non-root admin.

Some stuff is hardcoded to root, so you might need it sooner or later.

I'm concerned about opening remote root access, what do you think? What solution can/should I use to secure my server?

You shouldn't make your management (SSH/webUI/API/BMC) public. This is still the best way to secure your server. If you need some remote management whitelist a static public IP and block everything else and/or make it only accessible via VPN.

 

[LnxBil]

I'm surprised (that in base) it's proposed to use root as user.

Everything runs as root, so why the hell would you want to add another pam user that does the administration and needs to prefix everything with sudo to get anything done and have e.g. no automation or even working autocompletion? This has just only downsides to me.

There are still things that cannot be done in the GUI (at least to my knowledge) like accessing the nodes terminal/shell as root which needs PAM authentication. Most daily things can be done by any user (in any realm) on the GUI, so there is no need for a pam user after all.

You can however disable the root password login (prohibit-password in sshd, which is default on Debian and Ubuntu for years) or even disable the root password completely if you want to disable GUI access, but disabling root by setting its shell to nologin is the crazyiest thing I've ever seen.

 

[PmGs]

Some stuff is hardcoded to root, so you might need it sooner or later.

Thanks, it was what I understood.

 

[PmGs]

You shouldn't

... Of course

 

[PmGs]

so why the hell would you want to add another pam user

To reduce the surface attack ... root is a well known user!

 

[Dunuin]

There are other ways that are way more effective to protect your logins:
- set up fail2ban to temporarily block IPs of attackers so you can't bruteforce an SSH login...even if you know the user name
- for SSH, forbid passwords at all and only allow public private key authentification
- for webUI use 2FA
- for API use tokens
- restrict access via firewall whitelisting instead blacklisting
- don't make your management public so it can't be attacked in the first place, so it doesn't matter if the username is known or not...and with an attacker having access to your management LAN you got way bigger problems...

 

[alexskysilk]

To reduce the surface attack ... root is a well known user!

Proxmox is designed for root user use, for better or for worse. To limit the attack surface, limit your source networks and IPs allowed for ssh use.

 

[PmGs]

Thanks @alexskysilk I understood that "Proxmox is designed for root user use," and thanks @Dunuin to have well resume how to protect a server.

That said, I've been misled by this text from the proxmox doc

https://pve.proxmox.com/pve-docs/chapter-pveum.html#_administrator_group
It is possible that an administrator would want to create a group of users with full administrator rights (without using the root account).

 

[LnxBil]

That said, I've been misled by this text from the proxmox doc

https://pve.proxmox.com/pve-docs/chapter-pveum.html#_administrator_group
It is possible that an administrator would want to create a group of users with full administrator rights (without using the root account).

Yes, this only applies to the GUI, not the underlying Linux.

 

[HyperTrout]

Hello everyone,

Sorry for reviving this old thread, but it's still not quite clear to me whether or not it's possible to make do with a non-root user.

To be more specific - will this limitation also apply to sudoers users used to interact via Proxomv VE API, or that limitation (root hardcoded for certain features) is for UI only?

I.e. I want to use a sudoer user instead of root for API calls, and not worry about some features being not available to me.

Thanks!

 

[gorand]

There are other ways that are way more effective to protect your logins:
- set up fail2ban to temporarily block IPs of attackers so you can't bruteforce an SSH login...even if you know the user name
- for SSH, forbid passwords at all and only allow public private key authentification
- for webUI use 2FA
- for API use tokens
- restrict access via firewall whitelisting instead blacklisting
- don't make your management public so it can't be attacked in the first place, so it doesn't matter if the username is known or not...and with an attacker having access to your management LAN you got way bigger problems...

I think it is sensible to try and find an alternative to root access. It's not only about protecting logins and shielding from (external) breakins. It is also good practice to not use the root account for _everything_. You can nuke your machine in a flash, with just the one little mistake. But I understand some pve/qemu stuff might need root for what it does. Also, at least, it is always good to know who became root and did what they did, so only sudo access (no direct root logins) is useful too.

 

[LnxBil]

Also, at least, it is always good to know who became root and did what they did, so only sudo access (no direct root logins) is useful too.

I always hear this argument ... how can you be sure that EVERYTHING you do is logged if you just start a new shell and disable history, or attach to a running tmux/screen sessiong? I really, really don't get the security benefits of sudo in such a setup ... and don't get me started on cat ... | sudo tee constructs ... Better use a more mature security framework that'll restrict root from the really, really bad stuff.

 

[gorand]

I always hear this argument ... how can you be sure that EVERYTHING you do is logged if you just start a new shell and disable history, or attach to a running tmux/screen sessiong? I really, really don't get the security benefits of sudo in such a setup ... and don't get me started on cat ... | sudo tee constructs ... Better use a more mature security framework that'll restrict root from the really, really bad stuff.

well that was my original point. better restrict exactly what you want to do to some kind of non-universal-root user. otherwise you'll have to do with what you can log/trace back. but apparently this is difficult in the pve context/process/os integrations. but it's still better not to use root for everything (logged or not). this is not only a pve problem, to be sure.

 

[LnxBil]

Fortunately, you don't need to log in as root in your day-to-day work.

Has anyone experience in 4-eyes-login systems for Linux? Like two people need to log in in order to get a shell and work together?