Radius Authentication - SSH, SUDO, etc. working / Proxmox not

mharald

New Member
Mar 23, 2020
12
1
3
47
Hello,

Getting started with proxmox. Love it already!

I´d like to see RADIUS Auth working on the Proxmox GUI :)

SSH, SUDO, SU, etc all work with radius password. Any idea why Proxmox GUI is not?

The user xxxxx has a radius password and a local PAM password. The local PAM password is working over proxmox GUI.

root logins work as well over proxmox GUI

Here is a failed login using the radius password (auth.log):

Mar 23 10:41:07 hostname IPCC.xs[901805]: pam_unix(common-auth:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=xxxxx

What is IPCC.xs? Can it be configured to use radius?

Here is a successfull login over SSH (auth.log):

Mar 23 11:12:05 hostname sshd[954667]: Accepted password for xxxxx from xxx.xxx.xxx.xxx port 51243 ssh2
Mar 23 11:12:05 hostname sshd[954667]: pam_unix(sshd:session): session opened for user xxxxx by (uid=0)
Mar 23 11:12:05 hostname systemd-logind[716]: New session 123 of user xxxxx.


Any help is greatly appreciated.

Regards,

Harald
 
The user xxxxx has a radius password and a local PAM password. The local PAM password is working over proxmox GUI.

Not every PAM user is automatically added and enabled in the PVE user config. You need to add those users, either in the webinterface, or with pveum user add '<user>@pam', which could be scripted if you need to batch add a few users.
 
What is IPCC.xs? Can it be configured to use radius?

This is a red-herring, IPCC is just the interprocess communication stack we use to talk from Perl API code to pmxcfs (clustered configuration filesystem) faster and without going over the FUSE path (reduced overhead).
 
Not every PAM user is automatically added and enabled in the PVE user config. You need to add those users, either in the webinterface, or with pveum user add '<user>@pam', which could be scripted if you need to batch add a few users.
Hello! Thx for the reply. I believe the user has already been added:

root@hostname:/home/xxxxx# pveum user add xxxxx@pam
create user failed: error with cfs lock 'file-user_cfg': user 'xxxxx@pam' already exists


Is there any other common issue why this wouldn´t work?

Thank you and regards,

Harald
 
This is a red-herring, IPCC is just the interprocess communication stack we use to talk from Perl API code to pmxcfs (clustered configuration filesystem) faster and without going over the FUSE path (reduced overhead).
Hello! Thank you, I didn´t know that.

Can it be tought Radius? Something like:

auth sufficient pam_radius_auth.so

Regards,

Harald
 
root@hostname:/home/xxxxx# pveum user add xxxxx@pam
create user failed: error with cfs lock 'file-user_cfg': user 'xxxxx@pam' already exists


Is there any other common issue why this wouldn´t work?

not really, if it is added AND enabled in PVE user.cfg it should work - as long as that user can login on the system already successfully. What's the output from pveum user list
 
not really, if it is added AND enabled in PVE user.cfg it should work - as long as that user can login on the system already successfully. What's the output from pveum user list
Code:
root@hostname:/home/xxxxx# pveum user list
┌────────────┬─────────┬──────────────────────┬────────┬────────┬───────────┬────────┬──────┬──────────┬────────┐
│ userid     │ comment │ email                │ enable │ expire │ firstname │ groups │ keys │ lastname │ tokens │
╞════════════╪═════════╪══════════════════════╪════════╪════════╪═══════════╪════════╪══════╪══════════╪════════╡
│ xxxxxx@pam │         │ mymail@myprovide.com │ 1      │      0 │           │        │      │          │        │
├────────────┼─────────┼──────────────────────┼────────┼────────┼───────────┼────────┼──────┼──────────┼────────┤
│ root@pam   │         │ mymail@myprovide.com │ 1      │      0 │           │        │      │          │        │
└────────────┴─────────┴──────────────────────┴────────┴────────┴───────────┴────────┴──────┴──────────┴────────┘
xxxxxx = the radius user I am trying to log in to from proxmox UI.
 
I will restart the Server in the next days. I hope this helps.

Until then, is there a way to restart the Authentication-Module from Proxmox, should such a thing exist? :)

Regards,

Harald
 
if you know your way around perl, you could add some debugging output in https://git.proxmox.com/?p=pve-acce...cae9092b81ca79a2b35c69675164f2257;hb=HEAD#l24 (/usr/share/perl5/PVE/Auth/PAM.pm on your system). did you add radius to common-auth?
Hello,

Perl is not really my thing :(

in common-auth I only added the "try_first_pass".

This is working just fine for SSH&Co. Am I missing something?

Here´s the output from /etc/pam.d/common-auth

Bash:
root@hostname:/home/xxxxx# cat /etc/pam.d/common-auth
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
auth    [success=1 default=ignore]      pam_unix.so nullok_secure try_first_pass
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config
 
if you know your way around perl, you could add some debugging output in https://git.proxmox.com/?p=pve-acce...cae9092b81ca79a2b35c69675164f2257;hb=HEAD#l24 (/usr/share/perl5/PVE/Auth/PAM.pm on your system). did you add radius to common-auth?
Hi Fabian,

If I look at the Perl script, it looks as if it will only work with local passwords.

libpam-radius-auth doesn´t authenticate against local passwords but tries to authenticate the user against the radius server.

The "try_first_pass" means it will try _once_ to authenticate the user against radius. Should this fail, it will try to authenticate against local passwords.

Does this help in any way?

Regards,

Harald
 
you must have added pam_radius somewhere in PAM's config - PVE uses common-auth, if pam_radius is not configured there it will not work ;) the try_first_pass means it will try once to authenticate against pam_unix , not against pam_radius. please check your other PAM config files, and copy an appropriate line into common-auth as well. note that, as the comment indicates, common-auth is the common baseline for all authentication (but it does sound like that is what you want anyway ;)). so far no-one requested it, but we could of course also check using some PVE specific PAM config file (first? only?) instead of / in addition to common-auth..
 
you must have added pam_radius somewhere in PAM's config - PVE uses common-auth, if pam_radius is not configured there it will not work ;) the try_first_pass means it will try once to authenticate against pam_unix , not against pam_radius. please check your other PAM config files, and copy an appropriate line into common-auth as well. note that, as the comment indicates, common-auth is the common baseline for all authentication (but it does sound like that is what you want anyway ;)). so far no-one requested it, but we could of course also check using some PVE specific PAM config file (first? only?) instead of / in addition to common-auth..
Got it. Thank you for that. I'll dig around, see how I can get it to work. Shouldn't be too hard :)

Regards,

Harald
 
Hi,

Just wanted to followup on this one, so it rounds up.

If you add:

auth sufficient pam_radius_auth.so

to /etc/pam.d/common-auth

then Radius authentication is working fine on the Web Frontend.

Downside: _ALL_ PAM Authentication now goes over Radius. I cannot choose if, for example, /etc/pam.d/sshd should only use common-auth and /etc/pam.d/sudo should try radius and then common-auth as they all have common-auth as a backend.

@proxmox: You should consider developing your own PAM Module in /etc/pam.d which then uses common-auth as a backend. This would enable us admins to choose wether to use common-auth (linux auth) or some other PAM Module instead (or both!).

Thank you for your guidance for finding a -workaround-

Stay healthy ;)

Regards,

Harald
 
  • Like
Reactions: fabian
Yes, like I said earlier that should be pretty straight-forward to implement without changing how the default common-auth case works - it's just that no-one has requested it yet as far as I know ;)
 

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!

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!