Cannot su to root from SSH logins

Hi there

I just performed a minimal installation of FreeBSD 8.0R/i386 on a remote server and enabled ssh access with its default configuration (PermitRootLogin no). No updates, no quirky things, just a plain base system install.
Code:
$ uname -a
FreeBSD ceng.ata.xxx.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009     root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386


Some users were created from sysinstall and later invited to join the wheel group, in order to be able to perform some basic administrative tasks.

The issue that is puzzling me is that, when we log in from the local terminal, we can su and become root, but, if we try to su to root from a remote ssh login, we get
Code:
su: sorry
no matter how we try to su: su -, su -l, su, su root.

Users are properly added to wheel:
Code:
$ groups ortiz
ortiz wheel

At first I thought this might be related to a login class (?), or a PAM (?) issue. I did took a look at /etc/pam.d but I think those files are beyond my skills and saw nothing relevant.

Are accounts pending for approval or activation by default? I have used FreeBSD for years and never saw an issue like this, I feel I am back to the 4.4 days when I knew nothing at all!

Thanks in advance
 
Erratus said:
If you use password authentication you should change to public key authentication instead for using su.

Thank you very much for your reply, Erratus.

Following your advice I have uploaded my public key to my new server and edited authorized_keys consequently.

After a public-key login, as in

Code:
ssh -o PreferredAuthentications=publickey server.example.org

to force public key authentication, I still get the same su error.

With my regular user privileges from here, I can just see these messages from /var/log/messages
Code:
Jul 13 07:32:50 ceng login: ROOT LOGIN (root) ON ttyv0
Jul 13 07:35:19 ceng su: BAD SU ortiz to root on /dev/pts/0

that effectively illustrate the problem.

Since when public key auth is being enforced in order to be able to su to root? In which part of the system is this policy applied?

I didnt not even install the documentation sets and manual pages, so I fail to see how to relate su and ssh :(
 
taromaru said:
In which part of the system is this policy applied?
On the remote system the user account you login has to be member of group wheel in order to su on the remote system.
I checked on my system finding that either password and public key authentication both work with su. ;)
I do ssh like this:
Code:
> ssh remoteuser@XXX.XXX.XXX.XXX
with no options. Then you will be asked either for password or for passphrase.
 
Of course, I belong to the wheel group in the remote system :)
I am performing the tests from two independent systems (Windows 7 and Ubuntu 9.10) with no success whatsoever, using both public key and password authentication.

Code:
$ cat /etc/group | grep wheel
wheel:*:0:root,ortiz,xxx

I just inspected /etc/login.conf desperately and I was not able to see nothing that might fix this problem.

Besides, I cannot access physically that remote server and so I cannot root at all, and I am starting to feel handcuffed and useless.

Searching the FreeBSD mailing list archives for different combinations (BAD SU, as inspired by the logs, yields the best results) reports varying nature issues: from newcomers not belonging to wheel (most of them) to users mistyping their passwords when setting passwords while compiling the world to update.

What can I do, am I the only one going through this?

Thank you very much for your help

PS: The installation process was clean and fast, nothing weird happened that might create this
 
Just to summarize:

You can access remote server via ssh
but you cannot su when having succesfully logged in to that server

Did you ever performed a su on that server (physically sitting in front of it)? :)
Your problem might have other reasons than ssh.
 
Putting it simple, yes, we can log in via ssh succesfully. We can use the system at user level as much as we want, but the problem arises when we want to increase the privileges inside the very system we already are logged in.

As the server was installed with the help of a friend in Istabul -Im from Spain-, I also thought it might be related to keyboard mappings and stuff, and so i wrote the password in cleartext and then copy pasted that text buffer from both putty and openssh client.
I got no luck.

My friend can login as root and su to root when he is at that particular room, and using the same password he provided me.
Even more weird is that he is experiencing the same issues in his remote logins from inside Turkey and the very same keyboard map.

Im completely clueless, we might have to eventually have it reinstalled. Its sad if thats the smartest solution I can come up with
 
@taromaru:

Two things -
  1. Check /var/log/auth.log around the time of the su(1) attempts for clues.
  2. What is in your /etc/login.access file?
 
taromaru said:
... I also thought it might be related to keyboard mappings and stuff, and so i wrote the password in cleartext and then copy pasted that text buffer from both putty and openssh client...
Your friend may try this if a "complex" password is in use:
Change root password temporarily to alphanumeric characters [a-z,A-Z,0-9] only and try ssh/su again.
Punch passwords by keyboard, do not copy and paste while experimenting. This will eliminate at least problems with localized keymapping.
 
taromaru said:
Putting it simple, yes, we can log in via ssh succesfully. We can use the system at user level as much as we want, but the problem arises when we want to increase the privileges inside the very system we already are logged in.

As the server was installed with the help of a friend in Istabul -Im from Spain-, I also thought it might be related to keyboard mappings and stuff, and so i wrote the password in cleartext and then copy pasted that text buffer from both putty and openssh client.
I got no luck.

It may help to see /etc/rc.conf and /etc/ssh/sshd_config. Innocent-looking things like securelevel, maybe.

You said you enabled ssh access, but not exactly how.

we might have to eventually have it reinstalled. Its sad if thats the smartest solution I can come up with

If you do that, make a copy of /etc first. Then you can compare it with the new install to see what to blame. Unless the new install does it too...
 
Check the /var/log/security and /var/log/auth.log. They might have additional information as to why you were denied.

Also, what's the contents of your /etc/pam.d/su, /etc/pam.d/ssh and /etc/pam.d/system?
 
So, in reply to all the help that I am being offered (thank you very much), I will post all the requested files.

Note that I had already taken a look at them, but for the sake of completion here we have the relevant entries:

auth.log
Code:
Jul 13 10:39:50 ceng sshd[3458]: Accepted publickey for ortiz from xxx.xxx.xxx.xxx port 38460 ssh2
Jul 14 10:00:07 ceng sshd[6179]: Accepted keyboard-interactive/pam for ortiz from xxx.xxx.xxx.xxx port 49949 ssh2
Jul 14 10:04:44 ceng su: BAD SU ortiz to root on /dev/pts/0
Jul 14 10:13:39 ceng login: login on ttyv0 as root
Jul 14 10:13:39 ceng login: ROOT LOGIN (root) ON ttyv0

/var/log/security contains no info at all but a single newsyslog related entry

login.access. This is the stock file from the distribution sets, I have performed no change on this neither.

There's, however, that "-:wheel:ALL EXCEPT LOCAL .win.tue.nl" line that makes me wonder if it is just an example, or if it is a policy being enforced as default. If so, it seems to me that thats the show-stopper here, isnt it?

Code:
# $FreeBSD: src/etc/login.access,v 1.4.30.1.2.1 2009/10/25 01:10:29 kensmith Exp $
#
# Login access control table.
#
# When someone logs in, the table is scanned for the first entry that
# matches the (user, host) combination, or, in case of non-networked
# logins, the first entry that matches the (user, tty) combination.  The
# permissions field of that table entry determines whether the login will
# be accepted or refused.
#
# Format of the login access control table is three fields separated by a
# ":" character:
#
# 	permission : users : origins
#
# The first field should be a "+" (access granted) or "-" (access denied)
# character. The second field should be a list of one or more login names,
# group names, or ALL (always matches).  The third field should be a list
# of one or more tty names (for non-networked logins), host names, domain
# names (begin with "."), host addresses, internet network numbers (end
# with "."), ALL (always matches) or LOCAL (matches any string that does
# not contain a "." character). If you run NIS you can use @netgroupname
# in host or user patterns.
#
# The EXCEPT operator makes it possible to write very compact rules.
#
# The group file is searched only when a name does not match that of the
# logged-in user. Only groups are matched in which users are explicitly
# listed: the program does not look at a user's primary group id value.
#
##############################################################################
#
# Disallow console logins to all but a few accounts.
#
#-:ALL EXCEPT wheel shutdown sync:console
#
# Disallow non-local logins to privileged accounts (group wheel).
#
#-:wheel:ALL EXCEPT LOCAL .win.tue.nl
#
# Some accounts are not allowed to login from anywhere:
#
#-:wsbscaro wsbsecr wsbspac wsbsym wscosor wstaiwde:ALL
#
# All other accounts are allowed to login from anywhere.


rc.conf, the remaining entries belong to the networking setup (hostname, default gateway and addressing). Everything looks harmless

Code:
keymap="us.iso"
sshd_enable="YES"

pam.d directory was also untouched.
su
Code:
# $FreeBSD: src/etc/pam.d/su,v 1.16.32.1.2.1 2009/10/25 01:10:29 kensmith Exp $
#
# PAM configuration for the "su" service
#

# auth
auth		sufficient	pam_rootok.so		no_warn
auth		sufficient	pam_self.so		no_warn
auth		requisite	pam_group.so		no_warn group=wheel root_only fail_safe
auth		include		system

# account
account		include		system

# session
session		required	pam_permit.so
sshd service
Code:
# $FreeBSD: src/etc/pam.d/sshd,v 1.16.10.1.2.1 2009/10/25 01:10:29 kensmith Exp $
#
# PAM configuration for the "sshd" service
#

# auth
auth		sufficient	pam_opie.so		no_warn no_fake_prompts
auth		requisite	pam_opieaccess.so	no_warn allow_local
#auth		sufficient	pam_krb5.so		no_warn try_first_pass
#auth		sufficient	pam_ssh.so		no_warn try_first_pass
auth		required	pam_unix.so		no_warn try_first_pass

# account
account		required	pam_nologin.so
#account 	required	pam_krb5.so
account		required	pam_login_access.so
account		required	pam_unix.so

# session
#session 	optional	pam_ssh.so
session		required	pam_permit.so

# password
#password	sufficient	pam_krb5.so		no_warn try_first_pass
password	required	pam_unix.so		no_warn try_first_pass


system
Code:
# $FreeBSD: src/etc/pam.d/system,v 1.1.32.1.2.1 2009/10/25 01:10:29 kensmith Exp $
#
# System-wide defaults
#

# auth
auth		sufficient	pam_opie.so		no_warn no_fake_prompts
auth		requisite	pam_opieaccess.so	no_warn allow_local
#auth		sufficient	pam_krb5.so		no_warn try_first_pass
#auth		sufficient	pam_ssh.so		no_warn try_first_pass
auth		required	pam_unix.so		no_warn try_first_pass nullok

# account
#account 	required	pam_krb5.so
account		required	pam_login_access.so
account		required	pam_unix.so

# session
#session 	optional	pam_ssh.so
session		required	pam_lastlog.so		no_fail

# password
#password	sufficient	pam_krb5.so		no_warn try_first_pass
password	required	pam_unix.so		no_warn try_first_pass

I will try to make a change under login.access and report back if there's any update.

Thank you very much for you kind help, really

EDIT: We just appended "+:wheel:ALL" to login.access and changed the password to an only-numeric password and now I can su from ssh networked logins.

Right now we dont know what fixed this issue (password change or login.access entry) and have no time for it so, we will try it later today or tomorrow morning. Any input or comment is welcome!
 
taromaru said:
We just appended "+:wheel:ALL" to login.access and changed the password to an only-numeric password and now I can su from ssh networked logins.

Right now we dont know what fixed this issue (password change or login.access entry) and have no time for it so, we will try it later today or tomorrow morning. Any input or comment is welcome!

Simple: remove the entry from /etc/login.access, and see if you can still su(1). If so, the password change fixed it. If not, pam_login_access(8) is denying access for some reason (which would be rather odd, considering the default configuration does not include any rules).
 
This morning again I had some time to spend on that system, so I made some tests.

I commented out the login.access(5) entry and could succesfully su again. This behaviour survived a reboot so we can state it was a keyboard encoding issue, probably with the turkish vowels.

Thank you very much for all your help and comments on this matter
 
Back
Top