PAM denying sudo to root
PAM denying sudo to root
Hi all,
I have a problem with PAM here which seems to be a little bit weird. We're running several CentOS systems (CentOS 6 and 7) on virtual machines, and use Veeam for backup. Now, I'd like to give Veeam the ability to index the files on the VMs, and for this, the Veeam server needs root access to the VM.
Since we don't want to store all our root-passwords in the Veeam server configuration, I've setup a special user for this which can login using a (password-protected) ssh key, and then elevate to root using sudo.
This works on almost all VMs except of a few ones where the sudo fails, although all machines are AFAIK identical configured.
I've examined /var/log/secure, here's what I' ve found on a machine where sudo failed:
Feb 9 13:57:25 <server> sshd[12965]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<veeam-server> user=root
Feb 9 13:57:25 <server> sshd[12965]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Feb 10 09:07:38 <server> sshd[16683]: Failed password for root from <IP> port 61753 ssh2
And here's the message on a server where it works:
Feb 8 22:41:31 <server> sshd[23642]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<veeam-server> user=root
Feb 8 22:41:31 <server> sshd[23642]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Feb 8 22:41:32 <server> sshd[23642]: Failed password for root from <IP> port 61912 ssh2
So, password failed on both servers, /var/log/secure is identical. But audit.log on the server which allows the login states
type=USER_AUTH msg=audit(1423555092.353:48470): pid=5604 uid=0 auid=4294967295 ses=4294967295 msg='op=success acct="root" exe="/usr/sbin/sshd" hostname=? addr=<IP> terminal=ssh res=success'
whereas the other one says
type=USER_AUTH msg=audit(1423555658.968:96902): pid=16683 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="root" exe="/usr/sbin/sshd" hostname=<veeam-server> addr=<IP> terminal=ssh res=failed'
The only difference I can see is that server one (which worked) does not show the hostname (hostname=?) while server 2 does.
I've checked sudoers, several pam.d config files, sysctl.conf and also the output of authconfig, everything's identical.
So, the question is, why can Veeam sudo on server 1 but not on server 2?
Thanks and best regards form Germany,
Harald
I have a problem with PAM here which seems to be a little bit weird. We're running several CentOS systems (CentOS 6 and 7) on virtual machines, and use Veeam for backup. Now, I'd like to give Veeam the ability to index the files on the VMs, and for this, the Veeam server needs root access to the VM.
Since we don't want to store all our root-passwords in the Veeam server configuration, I've setup a special user for this which can login using a (password-protected) ssh key, and then elevate to root using sudo.
This works on almost all VMs except of a few ones where the sudo fails, although all machines are AFAIK identical configured.
I've examined /var/log/secure, here's what I' ve found on a machine where sudo failed:
Feb 9 13:57:25 <server> sshd[12965]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<veeam-server> user=root
Feb 9 13:57:25 <server> sshd[12965]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Feb 10 09:07:38 <server> sshd[16683]: Failed password for root from <IP> port 61753 ssh2
And here's the message on a server where it works:
Feb 8 22:41:31 <server> sshd[23642]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<veeam-server> user=root
Feb 8 22:41:31 <server> sshd[23642]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Feb 8 22:41:32 <server> sshd[23642]: Failed password for root from <IP> port 61912 ssh2
So, password failed on both servers, /var/log/secure is identical. But audit.log on the server which allows the login states
type=USER_AUTH msg=audit(1423555092.353:48470): pid=5604 uid=0 auid=4294967295 ses=4294967295 msg='op=success acct="root" exe="/usr/sbin/sshd" hostname=? addr=<IP> terminal=ssh res=success'
whereas the other one says
type=USER_AUTH msg=audit(1423555658.968:96902): pid=16683 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="root" exe="/usr/sbin/sshd" hostname=<veeam-server> addr=<IP> terminal=ssh res=failed'
The only difference I can see is that server one (which worked) does not show the hostname (hostname=?) while server 2 does.
I've checked sudoers, several pam.d config files, sysctl.conf and also the output of authconfig, everything's identical.
So, the question is, why can Veeam sudo on server 1 but not on server 2?
Thanks and best regards form Germany,
Harald
-
- Posts: 1522
- Joined: 2014/05/21 20:16:00
- Location: Central New York, USA
Re: PAM denying sudo to root
I don't know, but suspect that UID 'check' was added to CentOS 7 hence the reject notice.
CentOS 6 account numbers start at 500; CentOS 7 at 1000 (just FYI)
I'm having a brain scratch trying to figure out why root would ever sudo or want to - he's already root !! All sudo does is "elevate" a user to a sort of root status. I must be confused.
CentOS 6 account numbers start at 500; CentOS 7 at 1000 (just FYI)
I'm having a brain scratch trying to figure out why root would ever sudo or want to - he's already root !! All sudo does is "elevate" a user to a sort of root status. I must be confused.
Re: PAM denying sudo to root
Hello lightman47,
thanks for your reply! Hm, the problem occurs on CentOS 6 and 7, so, it seems to be version-independent. Concerning the sudo itself, that was maybe a bit confusing in my initial post: Of course the initial login is not made as root, but as a normal user (veeam) using an authorized key.
Then, sudo is executed to get root rights on the VM for indexing etc.
So, there are two steps, and the first one is okay while the second one fails:
First of all, the Veeam server logs in as user veeam with its private key, which works on all VMs. Then, it issues a "sudo su -" to elevate to root, and that fails on some (not all) VMs. To make things even more confusing, when I do a "manual" login from the Veeam server with putty, I can use a "sudo su -" to become root on all systems.
I hope this helps to make things a bit clearer.
Harald
thanks for your reply! Hm, the problem occurs on CentOS 6 and 7, so, it seems to be version-independent. Concerning the sudo itself, that was maybe a bit confusing in my initial post: Of course the initial login is not made as root, but as a normal user (veeam) using an authorized key.
Then, sudo is executed to get root rights on the VM for indexing etc.
So, there are two steps, and the first one is okay while the second one fails:
First of all, the Veeam server logs in as user veeam with its private key, which works on all VMs. Then, it issues a "sudo su -" to elevate to root, and that fails on some (not all) VMs. To make things even more confusing, when I do a "manual" login from the Veeam server with putty, I can use a "sudo su -" to become root on all systems.
I hope this helps to make things a bit clearer.
Harald
-
- Posts: 1522
- Joined: 2014/05/21 20:16:00
- Location: Central New York, USA
Re: PAM denying sudo to root
You're doing TWO "sudo's", so to speak - do EITHER "sudo" or "su -". SUDO is a 'temporary su" to perform a single task, where su will make you root until you exit that instance.
Re: PAM denying sudo to root
Is the special account that you're talking about root? It's not a good idea to allow SSH access to the root account. You should be using your "special user" to perform whatever action you're trying to take. The snippet above says that you're trying to SSH from the veeam server as the root user, and not as the veeam account that you mention below.HaraldH wrote: I've setup a special user for this which can login using a (password-protected) ssh key, and then elevate to root using sudo.
Feb 9 13:57:25 <server> sshd[12965]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<veeam-server> user=root
Feb 9 13:57:25 <server> sshd[12965]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Feb 10 09:07:38 <server> sshd[16683]: Failed password for root from <IP> port 61753 ssh2
Can you share the following, obfuscating any sensitive information?
--
-- /etc/ssh/sshd_config
-- /etc/pam.d/sshd
-- /etc/pam.d/password-auth
-- Jeremy --
Re: PAM denying sudo to root
Hello jyoung,
thanks for your reply. The special account is called "veeam", Veeam uses this account for login and after successful login it tries to get superuser rights with sudo, which fails on some (not all) servers. Veeam needs superuser rights for several tasks, for example for indexing.
The snippet is from the secure.log, and it looks the same on all servers, no matter if sudo was successful or not.
Here's the config information you've requested, everything should be standard:
/etc/ssh/sshd_config
/etc/pam.d/sshd
/etc/pam.d/password-auth
Many thanks for your help and kind regards,
Harald
thanks for your reply. The special account is called "veeam", Veeam uses this account for login and after successful login it tries to get superuser rights with sudo, which fails on some (not all) servers. Veeam needs superuser rights for several tasks, for example for indexing.
The snippet is from the secure.log, and it looks the same on all servers, no matter if sudo was successful or not.
Here's the config information you've requested, everything should be standard:
/etc/ssh/sshd_config
Code: Select all
# $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
#AuthorizedKeysCommand none
#AuthorizedKeysCommandRunAs nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes
# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no
UsePAM yes
# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
# no default banner path
#Banner none
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server
Code: Select all
#%PAM-1.0
auth required pam_sepermit.so
auth include password-auth
account required pam_nologin.so
account include password-auth
password include password-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open env_params
session optional pam_keyinit.so force revoke
session include password-auth
Code: Select all
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
Harald
Re: PAM denying sudo to root
Thank you for sharing the configs. The special account that you've created is not the one that you're trying to use with SSH. Whatever you're doing, you're trying to SSH as root and failing password authentication.HaraldH wrote:Hello jyoung,
thanks for your reply. The special account is called "veeam", Veeam uses this account for login and after successful login it tries to get superuser rights with sudo, which fails on some (not all) servers. Veeam needs superuser rights for several tasks, for example for indexing.
The snippet is from the secure.log, and it looks the same on all servers, no matter if sudo was successful or not.
-- Jeremy --
Re: PAM denying sudo to root
Hello HaraldH.
Were you able to solve this?
I'm having the same issue, and by increasing the user id I could do the sudo. Anyway it does not make sense that the user id prevents the sudo.
Thanks.
Kind regards,
Vilhena
Were you able to solve this?
I'm having the same issue, and by increasing the user id I could do the sudo. Anyway it does not make sense that the user id prevents the sudo.
Thanks.
Kind regards,
Vilhena