shell access for oidc user

L

leon1234

New Member
Sep 24, 2024
5
0
1
Hi,
I logged in via open id connect and want to access the shell of my node. It asks me for the login but it seems that my username and password are wrong. If I log in as root user it does not ask me for login. How can I access the shell as the open id connect user? The user has all permissions for the group and role.

EDIT: also username@realm + password does not work
 
Last edited:
You mean the "Shell" tab for the actual host, instead of the console of the container or VM? If so, that is a "/bin/login" process that asks you for your local password unless you already connected to the UI with the local root credentials. I don't think there is any PAM trickery to use other authentication methods, although that could certainly be added.

I find it annoying, as it regularly logs you out, and doesn't reattach to an existing session. This probably makes a lot of sense, if you deploy in a larger organization, where you can't trust all of the users. But it gets old quickly, if you have a very small group of admins that can access the Proxmox UI.

These days, I just patch PVE to use "/usr/bin/dtach" and to disable the password request. Works well for my use case, but it could be absolutely braindead stupid and insecure for other environments. Review your own threat-profile before applying this change. Please note that you need to reapply it, any time that the PVE manager is updated, and then you also need to run "systemctl restart pvedaemon.service"

Diff: 
--- Nodes.pm.orig    2024-09-14 09:42:29.993099987 -0700
+++ Nodes.pm    2024-09-14 09:44:45.720215992 -0700
@@ -977,7 +977,7 @@
 
 my \$shell_cmd_map = {
     'login' => {
-       cmd => [ '/bin/login', '-f', 'root' ],
+       cmd => [ '/usr/bin/dtach', '-A', '/var/run/dtach/vzctlrootshell', '-r', 'winch', '-E', '-z', '/bin/login', '-f', 'root' ],
     },
     'upgrade' => {
        cmd => [ '/usr/bin/pveupgrade', '--shell' ],
@@ -1000,11 +1000,11 @@
                push @\$cmd, split(\"\\0\", \$args);
            }
        } else {
-           \$cmd = [ '/bin/login', '-f', 'root' ];
+           \$cmd = [ '/usr/bin/dtach', '-A', '/var/run/dtach/vzctlrootshell', '-r', 'winch', '-E', '-z', '/bin/login', '-f', 'root' ];
        }
     } else {
        # non-root must always login for now, we do not have a superuser role!
-       \$cmd = [ '/bin/login' ];
+       \$cmd = [ '/usr/bin/dtach', '-A', '/var/run/dtach/vzctlrootshell', '-r', 'winch', '-E', '-z', '/bin/login', '-f', 'root' ];
     }
     return \$cmd;
 }

For a somewhat less hacky solution, I would use an OIDC-aware reverse proxy to access the PVE user interface. It can do all of the authentication and then provide the results to PVE. You could then patch the PVE manager to trust this information and automatically grant elevated permissions. I don't think it's super difficult to implement, but it certainly requires some amount of testing. And since it's something that needs to integrate with third-party components, I can see why the Proxmox developers are reluctant to spend a lot of time and effort on this feature.
 
Last edited:
zodiac said:
You mean the "Shell" tab for the actual host, instead of the console of the container or VM? If so, that is a "/bin/login" process that asks you for your local password unless you already connected to the UI with the local root credentials. I don't think there is any PAM trickery to use other authentication methods, although that could certainly be added.

I find it annoying, as it regularly logs you out, and doesn't reattach to an existing session. This probably makes a lot of sense, if you deploy in a larger organization, where you can't trust all of the users. But it gets old quickly, if you have a very small group of admins that can access the Proxmox UI.

These days, I just patch PVE to use "/usr/bin/dtach" and to disable the password request. Works well for my use case, but it could be absolutely braindead stupid and insecure for other environments. Review your own threat-profile before applying this change. Please note that you need to reapply it, any time that the PVE manager is updated, and then you also need to run "systemctl restart pvedaemon.service"

Diff: 
--- Nodes.pm.orig    2024-09-14 09:42:29.993099987 -0700
+++ Nodes.pm    2024-09-14 09:44:45.720215992 -0700
@@ -977,7 +977,7 @@
 
 my \$shell_cmd_map = {
     'login' => {
-       cmd => [ '/bin/login', '-f', 'root' ],
+       cmd => [ '/usr/bin/dtach', '-A', '/var/run/dtach/vzctlrootshell', '-r', 'winch', '-E', '-z', '/bin/login', '-f', 'root' ],
     },
     'upgrade' => {
        cmd => [ '/usr/bin/pveupgrade', '--shell' ],
@@ -1000,11 +1000,11 @@
                push @\$cmd, split(\"\\0\", \$args);
            }
        } else {
-           \$cmd = [ '/bin/login', '-f', 'root' ];
+           \$cmd = [ '/usr/bin/dtach', '-A', '/var/run/dtach/vzctlrootshell', '-r', 'winch', '-E', '-z', '/bin/login', '-f', 'root' ];
        }
     } else {
        # non-root must always login for now, we do not have a superuser role!
-       \$cmd = [ '/bin/login' ];
+       \$cmd = [ '/usr/bin/dtach', '-A', '/var/run/dtach/vzctlrootshell', '-r', 'winch', '-E', '-z', '/bin/login', '-f', 'root' ];
     }
     return \$cmd;
 }

For a somewhat less hacky solution, I would use an OIDC-aware reverse proxy to access the PVE user interface. It can do all of the authentication and then provide the results to PVE. You could then patch the PVE manager to trust this information and automatically grant elevated permissions. I don't think it's super difficult to implement, but it certainly requires some amount of testing. And since it's something that needs to integrate with third-party components, I can see why the Proxmox developers are reluctant to spend a lot of time and effort on this feature.
Click to expand...
Yes I mean the shell of the host and not the shell of the container/vm. Thanks for the suggestion. I have the same scenario that you described.
What is an OIDC-aware reverse proxy? I use nginx proxy manager.
I added the account created via oidc to the administrator role but I guess Ill go with your solution then! Thanks for the code
 
An OIDC-aware reverse proxy would require users to authenticate before they can use the reverse proxy. This gives you an extra level of access control. In the easiest scenario, you could use Cloudflare to do this. But most reverse proxies should have support for this type of operation. I believe, nginx can do so, if you configure it accordingly.
 
zodiac said:
You mean the "Shell" tab for the actual host, instead of the console of the container or VM? If so, that is a "/bin/login" process that asks you for your local password unless you already connected to the UI with the local root credentials. I don't think there is any PAM trickery to use other authentication methods, although that could certainly be added.

I find it annoying, as it regularly logs you out, and doesn't reattach to an existing session. This probably makes a lot of sense, if you deploy in a larger organization, where you can't trust all of the users. But it gets old quickly, if you have a very small group of admins that can access the Proxmox UI.

These days, I just patch PVE to use "/usr/bin/dtach" and to disable the password request. Works well for my use case, but it could be absolutely braindead stupid and insecure for other environments. Review your own threat-profile before applying this change. Please note that you need to reapply it, any time that the PVE manager is updated, and then you also need to run "systemctl restart pvedaemon.service"

Diff: 
--- Nodes.pm.orig    2024-09-14 09:42:29.993099987 -0700
+++ Nodes.pm    2024-09-14 09:44:45.720215992 -0700
@@ -977,7 +977,7 @@
 
 my \$shell_cmd_map = {
     'login' => {
-       cmd => [ '/bin/login', '-f', 'root' ],
+       cmd => [ '/usr/bin/dtach', '-A', '/var/run/dtach/vzctlrootshell', '-r', 'winch', '-E', '-z', '/bin/login', '-f', 'root' ],
     },
     'upgrade' => {
        cmd => [ '/usr/bin/pveupgrade', '--shell' ],
@@ -1000,11 +1000,11 @@
                push @\$cmd, split(\"\\0\", \$args);
            }
        } else {
-           \$cmd = [ '/bin/login', '-f', 'root' ];
+           \$cmd = [ '/usr/bin/dtach', '-A', '/var/run/dtach/vzctlrootshell', '-r', 'winch', '-E', '-z', '/bin/login', '-f', 'root' ];
        }
     } else {
        # non-root must always login for now, we do not have a superuser role!
-       \$cmd = [ '/bin/login' ];
+       \$cmd = [ '/usr/bin/dtach', '-A', '/var/run/dtach/vzctlrootshell', '-r', 'winch', '-E', '-z', '/bin/login', '-f', 'root' ];
     }
     return \$cmd;
 }

For a somewhat less hacky solution, I would use an OIDC-aware reverse proxy to access the PVE user interface. It can do all of the authentication and then provide the results to PVE. You could then patch the PVE manager to trust this information and automatically grant elevated permissions. I don't think it's super difficult to implement, but it certainly requires some amount of testing. And since it's something that needs to integrate with third-party components, I can see why the Proxmox developers are reluctant to spend a lot of time and effort on this feature.
Click to expand...
which file are you editing?
 
is there a way to just patch the login but not detaching to the shell? I just tried it and when 2 users are logged in they see what the other one is typing which is kinda spooky :D
 
This is similar to what is currently happening when you open the console for any of the containers. But if it bothers you, you can probably just remove everything before the /bin/login (in other words, remove the /usr/bin/dtach and its command line arguments). I haven't tested whether it gives you a separate PTY, if you do that, but I suspect it should work.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom