So, apparently it's possible to spin up a CT with just SSH public key given, even via GUI, but why does it need a password, i.e. it is not possible to log in via the GUI Console tab to a CT without password, there does not seem to be anywhere to provide the private SSH key (like on a host), but this would mostly make sense for VMs because ... it's not necessary to authenticate to spawn a bash in an LXC, so?
Why does LXC need a password?
- Thread starter esi_y
- Start date
I suppose to have to same level of security as for QEMU VMs, in which you also need to authenticate on the guest OS.
I can't follow this one, just to clarify:
1. If one sets up a CT, it is possible skip password entry completely, which is a secure way of doing things as well. It is possible to set SSH key, in which case the PVE GUI is completely useless to access the CT (unless one suggests to ssh through from the host's shell means via GUI).
2. The only (passwordless) way to enter a VM (without e.g. guest tools of sorts) is SSH, which is secure, but not as secure as no SSH at all. The benefit of a CT is that it is (potentially) MORE secure (no passwords, no SSH). The very fact I can access a VM's or CT's host, therefore also its volume, change
/etc/shadow as I wish ... makes it not ANY MORE secure to ask for password, just inconvenient.3. For a CT, one can spawn a process like a shell from the host, attaching to the CT's namespace without having to add anything into the CT itself. One can do this manually even, so not having it done by PVE instead of the pty approach is just increasing risk unnecessarily (by having to add SSH where it would not have been needed).
I suspect PVE just reused the same from the VM on the CTs, which forces one to have passwords set on container users OR ssh access, which is suboptimal.
Yes.
Yes and no. A default PVE user (PVE authenticated user) can access (with approriate permissions) the terminal of a container and/or the display of a VM and has to authenticate inside of the guest and this is fine. As a PVE user you do not have access to the underlying disks (no SSH and no host terminal) and cannot read e.g. /etc/shadow.
mount -o loop /var/lib/vz/images/$id/vm-$id-disk-0.raw /mnt/here-will-be-my-guest-drive ?
Last edited:
Only root can do that and a PVE authenticated user is unable to login to your machine, therefore that authentication realm exists.
Sorry, had read your previous post too quickly. So you are saying for a regular user, you may grant only the "console" access via GUI, I suppose this would be only for the VM/CTs they are meant to access, you would not be casually letting just anyone, albeit authenticated, list others' VM/CTs, let alone getting them pty access to VM/CTs that are not their own.
In a self-explanatory fashion, as such user is already authenticated (to access those particular pty's), there's no additional benefit to re-auth them again. It would be difficult NOT to have them to do it for a VM, but it lacks any benefit for a CT. I would humbly submit this is an omission that came with LXCs being treated the same as VMs for no good reason with security implications where they would not need to be.
Yes. The authentication-separation also allows users to "see" the content of the display, but not interact and still be able to reboot the box. We have a use case for such a system and are glad it works that way in PVE (or any other virtualization platform I used).
I don't agree. PVE users should be users, so if they want to interact with a CT/VM, they should authenticate themselves. This is normally done by a second set of credentials.
Don't get me wrong here, I am not telling others how to do their setup, but this use case is not really benefiting from the described setup, neither in security nor convenience. For one, the users are inconvenienced by having to hold second set of creds multiple times which cannot e.g. be auto-filled and thus are likely to be repetitive easy-to-crack passwords. This of course is not an issue if the only person that can even access the pty is themselves, but then again, why did they have to remember or copy-paste that second set. If you expand on that, enabling ssh on such CT without prohibiting password auth later on would compromise it in real terms as opposed to system where those users were passwordless to begin with.
If that was my use case, I would actually prefer to have that sshd on such containers and them access it solely as pubkey auth and - if keeping up with the habits comes into play, suggest passphrase on those private keys.
The use case I have in mind is running e.g. services within a CT which needs no SSH access and basically no users other than for the services running, so no "real" users. Should one such a service get compromised, it would be great if there's no way to
su root and start guessing. I understand the CT's root is not host's, but it does not matter if e.g. there's other parts of the CT's fs which should remain inaccessible even should one minor service get compromised.
Last edited: