Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm able to SSH to my server (CentOS 5.9) using an admin account with sudo privileges:

$ ssh admin@myserver
Last login: Wed Feb 27 19:23:11 2013 from [IP ADDRESS]
[admin@myserver ~]$

Then I can su to root:

[admin@myserver ~]$ sudo su root
[sudo] password for admin: 
[root@myserver admin]# 

But I can't su to another user, and the su command is not telling me why:

[admin@myserver ~]$ sudo su anotheruser
[admin@myserver ~]$ whoami
admin

Any idea why I can su to root, but not to other users?

How can I get su to tell me why it is not doing what I want it to do?

share|improve this question
    
Don't use sudo, just su. Try su root, then su user as root. Then for more details, try su user as admin. –  Chloe Feb 28 '13 at 1:01
    
@Chloe sudo su anotheruser most certainly can work. It just needs to be granted in /etc/sudoers. –  Aaron Copley Feb 28 '13 at 1:04
1  
(Reason being is that it may not be desirable to know the target user's password. Sudo allows you to authenticate as yourself.) –  Aaron Copley Feb 28 '13 at 1:10
    
Why don't you just give those users permission to run commands as the other users in /etc/sudoers and forget this unnecessary indirection? –  Michael Hampton Feb 28 '13 at 1:51

3 Answers 3

up vote 0 down vote accepted

What permissions are granted in /etc/sudoers to admin?

Also, as root, you could always su - anotheruser. An extra step perhaps, but without knowing anything about your sudoers file this will work.

share|improve this answer
    
My permissions in /etc/sudoers look like this: root ALL=(ALL) ALL %admins ALL=(ALL) ALL The admin user is in the admins group. –  ChiCgi Feb 28 '13 at 1:10
2  
You're going to need to look in /var/log/secure, then. Sudo / su log to the authpriv facility which generally goes to /var/log/secure. –  Aaron Copley Feb 28 '13 at 1:16
    
I would double (triple) check the group membership of admin user. Is it a local group or domain? Try adding the user by name to /etc/sudoers to test and eliminate a point of failure. –  Aaron Copley Feb 28 '13 at 1:17
    
That's great feedback. I can see the su command working from admin to root in the /var/log/secure, but I find this for the admin user trying to su to anotheruser: Feb 28 10:03:38 myserver su: pam_unix(su-l:session): session opened for user anotheruser by admin(uid=0) Feb 28 10:03:38 myserver su: pam_unix(su-l:session): session closed for user anotheruser I'm still not exactly sure what's going on except that it's opening a session and then immediately closing the session. –  ChiCgi Feb 28 '13 at 15:12
    
I've also added the admin user to the sudoers file just below root like this: admin ALL=(ALL) ALL. Still no luck. The root user is also not able to su to another user account--not just the admin. I can, however, su from root to admin and vice-versa. –  ChiCgi Feb 28 '13 at 15:22

Check /var/log/security and /var/log/auth.log.

Why are you using sudo to use su? You don't need to do that unless you change your standard ACLs.

If you use sudo, then the issue might be related to you sudoer file. Verify you have it configured properly.

share|improve this answer
    
Reason to use sudo su over su is to use his own password instead of the target user. –  Aaron Copley Feb 28 '13 at 0:58
    
Also, these logs don't exist in a default CentOS 5.9 installation. –  Aaron Copley Feb 28 '13 at 1:01
    
On my other server (similar setup) by using sudo, I'm able to su using my own password. When I su by itself with no sudo, it says "incorrect password". –  ChiCgi Feb 28 '13 at 1:07
1  
su by itself requires you to use the target username's password, not your own. –  Aaron Copley Feb 28 '13 at 1:19
    
Is it a specific user you're having issues with or all users other than root? Also, can you show your sudoer's file? –  CIA Mar 1 '13 at 3:25

In case it's useful to someone else: I just ran into the same symptoms but the answer had nothing to do with sudo configuration.

Instead, it mattered which user I was trying to su to. The target user was a service pseudo-user (jenkins) which had /bin/false as its shell. The fix was to change the shell to a valid one (using chsh).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.