Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
|
06-02-2007, 06:04 PM
|
#1
|
Member
Registered: May 2007
Location: Austin, Texas, USA
Distribution: Debian Etch
Posts: 34
Rep:
|
Privilege separation user sshd does not exist
I'm getting this error when I try to start my cross-compiled OpenSSH sshd daemon for the first time with privilege separation enabled.
I am using OpenSSH_4.6p1.
I believe I have added a 'sshd' user and group correctly. I can login just fine as that user:
# login
(none) login: sshd
$
$ whoami
$ sshd
I'm trying to start the daemon as follows so that I can see the debug:
# /sbin/sshd -D -d
The error I am getting is:
Privilege separation user sshd does not exist
The contents of my /etc/group file are as follows:
root::0:root
sshd:x:33:
The contents of my /etc/passwd file are as follows:
root::0:0:Root User:/root:/bin/ash
sshd::501:33:sshd user:/var/empty:/bin/false
Can anyone please help me out?
Thanks!
|
|
|
06-02-2007, 06:23 PM
|
#2
|
LQ Guru
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733
|
The sshd user is a system user and you shouldn't be able to login as that user.
Edit the /etc/group line to
sshd:!:33:
My sshd entry in /etc/password looks like:
sshd:x:71:65:SSH daemon:/var/lib/sshd:/bin/false
The uid & gid are different on mine of course.
Also check the permissions on any config files that can't be world readable. I wonder if the no sshd user is caused by bad permissions causing a test to fail but the error message is not explicit enough.
|
|
|
06-02-2007, 07:05 PM
|
#3
|
Member
Registered: May 2007
Location: Austin, Texas, USA
Distribution: Debian Etch
Posts: 34
Original Poster
Rep:
|
Still having trouble...
I made the changes you recommended to my 'group' and 'passwd' files. However, it didn't seem to make any difference. Still getting the same error.
I also checked the permissions on all of the config files. They are as follows
-rw-r--r-- 1 root root
The other troubling thing is that I'm not getting any sshd messages in my syslog /var/log/messages file even though I've got the following in my sshd_config file:
SyslogFacility LOCAL7
LogLevel DEBUG
Do you have any other ideas? Thanks for the help.
|
|
|
06-02-2007, 07:37 PM
|
#4
|
LQ Guru
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733
|
Since the ssh daemon didn't start, that explains the lack of messages in /var/log/messages. Unless the attempt to start it should have produced a message. Are you certain there isn't a /var/log/security log used instead?
Also, you could try the -e option to output messages to stdout instead. Maybe using -dd would increase the verbosity of the error you got.
Here is the permissions on your system:
-rw------- 1 root root 132839 2006-11-27 13:02 moduli
-rw-r--r-- 1 root root 2643 2006-11-27 13:02 ssh_config
-rw-r----- 1 root root 3683 2006-11-27 13:02 sshd_config
-rw------- 1 root root 668 2007-05-25 15:23 ssh_host_dsa_key
-rw-r--r-- 1 root root 602 2007-05-25 15:23 ssh_host_dsa_key.pub
-rw------- 1 root root 527 2007-05-25 15:23 ssh_host_key
-rw-r--r-- 1 root root 331 2007-05-25 15:23 ssh_host_key.pub
-rw------- 1 root root 883 2007-05-25 15:23 ssh_host_rsa_key
-rw-r--r-- 1 root root 222 2007-05-25 15:23 ssh_host_rsa_key.pub
I'm curious what the target machine is. Can't you install ssh from a package on the target instead of cross compiling?
|
|
|
06-02-2007, 07:44 PM
|
#5
|
LQ Guru
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733
|
I found this message from this site:
Quote:
mkdir /var/empty
chown root:sys /var/empty
chmod 755 /var/empty
groupadd sshd
useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd
|
How did you create the sshd user?
|
|
|
06-02-2007, 10:59 PM
|
#6
|
Member
Registered: May 2007
Location: Austin, Texas, USA
Distribution: Debian Etch
Posts: 34
Original Poster
Rep:
|
Still not having any luck...
# ls -l /var
drwxr-xr-x 2 root sys 4096 Jun 2 05:00 empty
#cat /etc/group
root::0:root
bin:x:1:root,bin,daemon
daemon:x:2:root,bin,daemon
sys:x:3:root,bin
sshd:x:33:sshd
#cat /etc/passwd
root::0:0:root:/root:/bin/ash
daemon:x:1:1:daemon:/usr/sbin:/bin/ash
bin:x:2:2:/bin:/bin/ash
sys:x:3:3:/dev:/bin/ash
sshd:x:501:33:sshd:/var/empty:/bin/false
#cat /etc/shadow
root::0:0:99999:7:::
daemon:*:13544:0:99999:7:::
bin:*:13544:0:99999:7:::
sys:*:13544:0:99999:7:::
sshd:*:13544:0:99999:7:::
I guess it's probably worth mentioning that this is an embedded system and custom built linux kernel. I may be missing something else that is keeping 'sys' from working properly.
|
|
|
06-03-2007, 09:22 AM
|
#7
|
Member
Registered: May 2007
Location: Austin, Texas, USA
Distribution: Debian Etch
Posts: 34
Original Poster
Rep:
|
In answer to the questions you asked, I created the sshd user with the busybox 'adduser' command.
I haven't tried any pre-compiled x86 binaries on my i686 target either. Having difficulty finding something that can be installed.
Last edited by Mahonri; 06-03-2007 at 09:44 AM.
|
|
|
06-03-2007, 09:46 AM
|
#8
|
LQ Guru
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733
|
Quote:
Originally Posted by Mahonri
In answer to the questions you asked, I created the sshd user with the busybox 'adduser' command.
Also, I haven't tried installing pre-built binaries for openssh. I'll give that a shot.
|
I was just wondering if you simply edited the /etc/passwd file.
Did you try increasing the verbosity of the daemon when you started it with the -e option.
Also, you are running it manually. Does it maybe need to be run in the background as a service. I'm thinking that if the shell process that starts it doesn't have the real UID of the sshd user and the GID value of the user, then the priviledge separation will fail. I don't know but maybe both the real and effective UID values are checked. It might be worthwhile A) trying to start it with sudo. or B) starting in an /etc/init.d/sshd service script.
|
|
|
06-03-2007, 05:10 PM
|
#9
|
Member
Registered: May 2007
Location: Austin, Texas, USA
Distribution: Debian Etch
Posts: 34
Original Poster
Rep:
|
I think you may be on to something. I did try the -e option and it didn't provide any extra info.
I have been trying to start the sshd daemon from the 'init' script executed by the init process at startup.
I'm using the busybox start-stop-daemon command as follows:
/bin/start-stop-daemon -b -S --exec /sbin/sshd -- -d -e
I would imagine that it is the root user that is executing this command at this time. It sounds like I should be starting this daemon as the sshd user -- not as root.
Any advice on how I might do that?
|
|
|
06-03-2007, 09:09 PM
|
#10
|
LQ Guru
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733
|
The -e option was for manually starting the daemon, so that it would log to the console, giving you immediate feedback.
I'm not on my Linux machine right now, so I can't check my startup script.
Here is a readme.privsep file that contains information:
http://sunfreeware.com/README.privsep
Notice this line:
Quote:
Privsep requires operating system support for file descriptor passing.
|
Maybe the kernel of your embedded device won't support it and you need to disable priviledge separation in the sshd_config file. I'm just making a guess here.
If a package is available for your embedded device, you may save yourself a lot of work by installing ssh that way instead of cross compiling. The packages script will probably set up the system correctly or disable privsep if it isn't supported.
|
|
|
06-03-2007, 11:55 PM
|
#11
|
Member
Registered: May 2007
Location: Austin, Texas, USA
Distribution: Debian Etch
Posts: 34
Original Poster
Rep:
|
I noticed this line in the Sun doc you mentioned:
Quote:
Originally Posted by jschiwal
PAM-enabled OpenSSH is known to function with privsep on Linux.
|
My kernel is a standard 2.6.21.1 I downloaded from www.kernel.org
I definitely do not have PAM enabled in my build of OpenSSH. Sounds like it is required for Linux. I'll enable it and see if it works.
|
|
|
06-04-2007, 12:52 AM
|
#12
|
LQ Guru
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733
|
I noticed on SuSE that they use startproc to start the sshd daemon.
Code:
#! /bin/sh
# Copyright (c) 1995-2000 SuSE GmbH Nuernberg, Germany.
#
# Author: Jiri Smid <feedback@suse.de>
#
# /etc/init.d/sshd
#
# and symbolic its link
#
# /usr/sbin/rcsshd
#
### BEGIN INIT INFO
# Provides: sshd
# Required-Start: $network $remote_fs
# Required-Stop: $network $remote_fs
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Description: Start the sshd daemon
### END INIT INFO
SSHD_BIN=/usr/sbin/sshd
test -x $SSHD_BIN || exit 5
SSHD_SYSCONFIG=/etc/sysconfig/ssh
test -r $SSHD_SYSCONFIG || exit 6
. $SSHD_SYSCONFIG
SSHD_PIDFILE=/var/run/sshd.init.pid
. /etc/rc.status
# Shell functions sourced from /etc/rc.status:
# rc_check check and set local and overall rc status
# rc_status check and set local and overall rc status
# rc_status -v ditto but be verbose in local rc status
# rc_status -v -r ditto and clear the local rc status
# rc_failed set local and overall rc status to failed
# rc_reset clear local rc status (overall remains)
# rc_exit exit appropriate to overall rc status
# First reset status of this service
rc_reset
case "$1" in
start)
if ! test -f /etc/ssh/ssh_host_key ; then
echo Generating /etc/ssh/ssh_host_key.
ssh-keygen -t rsa1 -b 1024 -f /etc/ssh/ssh_host_key -N ''
fi
if ! test -f /etc/ssh/ssh_host_dsa_key ; then
echo Generating /etc/ssh/ssh_host_dsa_key.
ssh-keygen -t dsa -b 1024 -f /etc/ssh/ssh_host_dsa_key -N ''
fi
if ! test -f /etc/ssh/ssh_host_rsa_key ; then
echo Generating /etc/ssh/ssh_host_rsa_key.
ssh-keygen -t rsa -b 1024 -f /etc/ssh/ssh_host_rsa_key -N ''
fi
echo -n "Starting SSH daemon"
## Start daemon with startproc(8). If this fails
## the echo return value is set appropriate.
startproc -f -p $SSHD_PIDFILE $SSHD_BIN $SSHD_OPTS -o "PidFile=$SSHD_PIDFILE"
# Remember status and be verbose
rc_status -v
;;
stop)
echo -n "Shutting down SSH daemon"
## Stop daemon with killproc(8) and if this fails
## set echo the echo return value.
killproc -p $SSHD_PIDFILE -TERM $SSHD_BIN
# Remember status and be verbose
rc_status -v
;;
try-restart)
## Stop the service and if this succeeds (i.e. the
## service was running before), start it again.
$0 status >/dev/null && $0 restart
# Remember status and be quiet
rc_status
;;
restart)
## Stop the service and regardless of whether it was
## running or not, start it again.
$0 stop
$0 start
# Remember status and be quiet
rc_status
;;
force-reload|reload)
## Signal the daemon to reload its config. Most daemons
## do this on signal 1 (SIGHUP).
echo -n "Reload service sshd"
killproc -p $SSHD_PIDFILE -HUP $SSHD_BIN
rc_status -v
;;
status)
echo -n "Checking for service sshd "
## Check status with checkproc(8), if process is running
## checkproc will return with exit status 0.
# Status has a slightly different for the status command:
# 0 - service running
# 1 - service dead, but /var/run/ pid file exists
# 2 - service dead, but /var/lock/ lock file exists
# 3 - service not running
checkproc -p $SSHD_PIDFILE $SSHD_BIN
rc_status -v
;;
probe)
## Optional: Probe for the necessity of a reload,
## give out the argument which is required for a reload.
test /etc/ssh/sshd_config -nt $SSHD_PIDFILE && echo reload
;;
*)
echo "Usage: $0 {start|stop|status|try-restart|restart|force-reload|reload|probe}"
exit 1
;;
esac
rc_exit
Installing and configuring PAM will probably be even more complicated than what you are doing now.
If you are the only person accessing this device, locking it down with "Allow Users" may be all you need to do. The privsep feature is to prevent a regular user (with access) from gaining root access. If that only means you, disabling this feature until you can figure out what the problem is might be a plan to getting your device going in the interim.
Last edited by jschiwal; 06-04-2007 at 12:56 AM.
|
|
|
06-04-2007, 02:46 AM
|
#13
|
Member
Registered: May 2007
Location: Austin, Texas, USA
Distribution: Debian Etch
Posts: 34
Original Poster
Rep:
|
I've disabled priv sep for the time being. I went back to manually starting the daemon with /sbin/sshd -D -d -e
It seems to start up just fine. However when I try to ssh in from a remote host I'm getting some mysterious errors.
From remote host
# ssh -l dallas 172.16.1.34
On the target I see these errors:
debug1: userauth-request for user dallas service ssh-connection method none
debug1: attempt 0 failures 0
Invalid user dallas from 172.16.1.33
input_userauth_request: invalid user dallas
Failed none for invalid user dallas from 172.16.1.33 port 58128 ssh2
Can OpenSSH function without PAM if I also disable priv sep?
I know I'm a stubborn old fool for persisting to get this to work. I don't give up easy.
I suspect that I probably need PAM to authenticate the user. You were right -- compiling PAM is not easy. It's complaining as follows:
undefined reference to `yywrap'
I'm currently stuck on this...
Last edited by Mahonri; 06-04-2007 at 01:19 PM.
|
|
|
06-04-2007, 11:50 PM
|
#14
|
Member
Registered: May 2007
Location: Austin, Texas, USA
Distribution: Debian Etch
Posts: 34
Original Poster
Rep:
|
Case closed...
It turns out that I was missing a /etc/nsswitch.conf and associated /lib/libnss_* files. Once I added those, the priv sep user came to life.
I did not need PAM at all. The nsswitch does the password authentication by directly referencing the group and passwd files.
Thanks for all the help.
|
|
|
All times are GMT -5. The time now is 06:52 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|