sshd + PAM = fail?

Question

Level 1

8 points

sshd + PAM = fail?

Are there any additional tricks to enabling sshd on Leopard beyond simply checking off "Remote Login" under sharing? I've gotten as far as seeing successful key negotiations and a password prompt, but then immediately get disconnected. I see this PAM error in /var/log/secure:

May 25 15:03:26 imac sshd[4264]: error: PAM: pam opensession(): Cannot make/remove an entry for the specified session

...but nothing of any real interest in the output of a 'ssh -vvv' beyond the closing of the connection. I've configured sshd any number of times in non-PAM environments, but am a little hesitant to start clobbering things in /etc/sshd_config until I'm a little more familiar OS X.

Google searches have turned up things like 'rebuild PAM and/or SSH' which I'm not really inclined to do ATM. Any advice? I tried calling support on this, but was advised to instead search the knowledge base or post to the groups.

Thx,

JQ

Intel iMac, Mac OS X (10.5.2)

Posted on May 25, 2008 1:35 PM

Reply

Answer 1

Clea Rees

Level 4

1,245 points

May 25, 2008 3:24 PM in response to jquinby

I'm sure this is too obvious, but are you sure it isn't and ownership/permissions issue?

- cfr

Reply

Answer 2

BobHarris

Level 9

56,939 points

May 25, 2008 6:00 PM in response to jquinby

Check "man sshd" and look at what the allowable permissions are for various directories and files.

For example if your home directory allows write access to anyone else but yourself, then sshd will fail the login as it can not trust that the .ssh directory was not placed there by someone else.

and a whole bunch of other directories and files you need to check.

Message was edited by: BobHarris

Reply

Answer 3

jquinby Author

Level 1

8 points

May 25, 2008 6:56 PM in response to Clea Rees

Not at all sure, though I'd expect to see "permission denied" or "can't open foo for writing" in that case. Will keep digging.

Reply

Answer 4

jquinby Author

Level 1

8 points

May 25, 2008 6:58 PM in response to BobHarris

I'll take a look at this. Nothing, as far as I know, has been changed with regards to permissions on either my $HOME or anything in it since creation. So many other folks posting questions about sshd here seem to have a (generally) working setup, I was hoping that there was just one single dumb thing I needed to toggle or edit.

Reply

Answer 5

BobHarris

Level 9

56,939 points

May 25, 2008 7:14 PM in response to jquinby

Permissions have been the one obscure thing I've found that frustrate ssh users.

The other thing has been the local system's $HOME/.ssh/known_hosts file having an old entry for that IP address.

But generally the -vvv information has been extremely helpful, but you say yours has not helped.

could you post the output from ssh -vvv (maybe review it to make sure there is nothing personal in the output).

Reply

Answer 6

jquinby Author

Level 1

8 points

May 26, 2008 12:32 PM in response to BobHarris

Sure. Here goes. My comments are inline. Boldface is output usually returned to the user.

*(me)@imac ~$ ssh -vvv (me)@localhost*
OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /Users/(me)/.ssh/identity type -1
debug1: identity file /Users/(me)/.ssh/id_rsa type -1
debug1: identity file /Users/(me)/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7
debug1: match: OpenSSH_4.7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2 MSGKEXINIT sent
debug1: SSH2 MSGKEXINIT received
debug2: kex parsekexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex parsekexinit: ssh-rsa,ssh-dss
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes1 92-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes1 92-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.co m,hmac-sha1-96,hmac-md5-96
debug2: kex parsekexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.co m,hmac-sha1-96,hmac-md5-96
debug2: kex parsekexinit: none,zlib@openssh.com,zlib
debug2: kex parsekexinit: none,zlib@openssh.com,zlib
debug2: kex parsekexinit:
debug2: kex parsekexinit:
debug2: kex parsekexinit: first kexfollows 0
debug2: kex parsekexinit: reserved 0
debug2: kex parsekexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex parsekexinit: ssh-rsa,ssh-dss
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes1 92-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes1 92-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.co m,hmac-sha1-96,hmac-md5-96
debug2: kex parsekexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.co m,hmac-sha1-96,hmac-md5-96
debug2: kex parsekexinit: none,zlib@openssh.com
debug2: kex parsekexinit: none,zlib@openssh.com
debug2: kex parsekexinit:
debug2: kex parsekexinit:
debug2: kex parsekexinit: first kexfollows 0
debug2: kex parsekexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2 MSG_KEX_DH_GEXREQUEST(1024<1024<8192) sent
debug1: expecting SSH2 MSG_KEX_DH_GEXGROUP
debug2: dh genkey: priv key bits set: 129/256
debug2: bits set: 522/1024
debug1: SSH2 MSG_KEX_DH_GEXINIT sent
debug1: expecting SSH2 MSG_KEX_DH_GEXREPLY
debug3: check host_inhostfile: filename /Users/Jay/.ssh/known_hosts
debug3: check host_inhostfile: match line 3
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /Users/(me)/.ssh/known_hosts:3

+Key exchange looks OK. So far, so good.+

debug2: bits set: 521/1024
debug1: ssh rsaverify: signature correct
debug2: kex derivekeys
debug2: set_newkeys: mode 1
debug1: SSH2 MSGNEWKEYS sent
debug1: expecting SSH2 MSGNEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2 MSGNEWKEYS received
debug1: SSH2 MSG_SERVICEREQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2 MSG_SERVICEACCEPT received
debug2: key: /Users/(me)/.ssh/identity (0x0)
debug2: key: /Users/(me)/.ssh/id_rsa (0x0)
debug2: key: /Users/(me)/.ssh/id_dsa (0x0)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod isenabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/(me)/.ssh/identity
debug3: no such identity: /Users/(me)/.ssh/identity
debug1: Trying private key: /Users/(me)/.ssh/id_rsa
debug3: no such identity: /Users/(me)/.ssh/id_rsa
debug1: Trying private key: /Users/(me)/.ssh/id_dsa
debug3: no such identity: /Users/(me)/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod isenabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input userauth_inforeq
debug2: input userauth_inforeq: num_prompts 1
Password:

+Password sent.+

debug3: packet_send2: adding 32 (len 21 padlen 11 extra_pad 64)
debug2: input userauth_inforeq
debug2: input userauth_inforeq: num_prompts 0
debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64)
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug3: ssh session2open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client session2setup: id 0
debug2: channel 0: request pty-req confirm 0
debug3: tty makemodes: ospeed 38400
debug3: tty makemodes: ispeed 38400
debug3: tty makemodes: 1 3
debug3: tty makemodes: 2 28
debug3: tty makemodes: 3 127
debug3: tty makemodes: 4 21
debug3: tty makemodes: 5 4
debug3: tty makemodes: 6 255
debug3: tty makemodes: 7 255
debug3: tty makemodes: 8 17
debug3: tty makemodes: 9 19
debug3: tty makemodes: 10 26
debug3: tty makemodes: 11 25
debug3: tty makemodes: 12 18
debug3: tty makemodes: 13 23
debug3: tty makemodes: 14 255
debug3: tty makemodes: 17 255
debug3: tty makemodes: 18 255
debug3: tty makemodes: 30 0
debug3: tty makemodes: 31 0
debug3: tty makemodes: 32 0
debug3: tty makemodes: 33 0
debug3: tty makemodes: 34 0
debug3: tty makemodes: 35 0
debug3: tty makemodes: 36 1
debug3: tty makemodes: 38 1
debug3: tty makemodes: 39 1
debug3: tty makemodes: 40 0
debug3: tty makemodes: 41 1
debug3: tty makemodes: 50 1
debug3: tty makemodes: 51 1
debug3: tty makemodes: 53 1
debug3: tty makemodes: 54 1
debug3: tty makemodes: 55 1
debug3: tty makemodes: 56 0
debug3: tty makemodes: 57 0
debug3: tty makemodes: 58 0
debug3: tty makemodes: 59 1
debug3: tty makemodes: 60 1
debug3: tty makemodes: 61 1
debug3: tty makemodes: 62 1
debug3: tty makemodes: 70 1
debug3: tty makemodes: 72 1
debug3: tty makemodes: 73 0
debug3: tty makemodes: 74 0
debug3: tty makemodes: 75 0
debug3: tty makemodes: 90 1
debug3: tty makemodes: 91 1
debug3: tty makemodes: 92 0
debug3: tty makemodes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
*Last login: Mon May 26 14:21:20 2008*

+Almost in!+

debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client input_channelreq: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead

+Or not.+

debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)

debug3: channel 0: close_fds r -1 w -1 e 6 c -1
*Connection to localhost closed.*
debug1: Transferred: stdin 0, stdout 0, stderr 33 bytes in 0.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 610.0
debug1: Exit status 254

Booted. In /var/log/secure, everything looks pretty good until the PAM error:

May 26 14:22:21 imac com.apple.SecurityServer[20]: checkpw() succeeded, creating credential for user (me)
May 26 14:22:21 imac com.apple.SecurityServer[20]: checkpw() succeeded, creating shared credential for user (me)
May 26 14:22:21imac com.apple.SecurityServer[20]: Succeeded authorizing right system.login.tty by client /usr/sbin/sshd for authorization created by /usr/sbin/sshd.
May 26 14:22:21 imac sshd[5166]: Accepted keyboard-interactive/pam for (me) from ::1 port 55949 ssh2
May 26 14:22:21 imac sshd[5172]: error: PAM: pam opensession(): Cannot make/remove an entry for the specified session

Reply

Answer 7

BobHarris

Level 9

56,939 points

May 26, 2008 3:23 PM in response to jquinby

I created my own ssh -vvv and then did a side-by-side difference between the 2.

Essentially you logged in.

At this point it is your shell that is in control.

So I would be asking if there is anything in your shell initialization file that is kicking you out.

Try putting some 'echo' statements in your initialization file(s).

If you use the default 'bash' then
$HOME/.profile
$HOME/.bashrc
$HOME/.bash_profile

csh/tcsh
$HOME/.login
$HOME/.cshrc
$HOME/.tcshrc

ksh
$HOME/.profile
$HOME/.kshrc

etc...

The man page for the shell should tell you the names of all the possible initialize files.

If you suspect something higher in the food chain, there are global initialization files in /etc/. Use the man page for your shell to tell you the names of those files.

Also make sure /etc/shells lists your shell. By default it contains
/bin/bash
/bin/csh
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh
but if you are using a shell with a different path, or have edited /etc/shells, this could affect your login. Then again, I would have expected the terminal to choke if your shell was not in /etc/shells.

You might also check the protections on your shell initialization files. It is always possible that the login is failing because protections on the home directory or one of the shell initialization files is too permissive. And then again, if that were a problem, why would Terminal allow you to succeed. I don't know, but when you are desperate, you look at crazy things 🙂

Reply

Answer 8

Jul 4, 2008 10:22 PM in response to jquinby

I was having a similar problem, except I was trying to start sshd manually. I was getting the exact error messages in both /var/log/secure.log and in the output from ssh -vvv.

host1:~ root# ps -ef|grep ssh
501 5119 182 0 0:00.01 ?? 0:00.03 /usr/bin/ssh-agent -l
0 5124 1 0 0:00.00 ?? 0:00.00 /usr/sbin/sshd

Then after reading in the thread that you can enable sshd (Remote Login) from System Preferences, I finally got things working. It did take a few times of enabling and disabling before it worked. Each time I would do ps, and I would never see sshd listed. Finally I could see the process had started, and sure enough I could then ssh in.

host1:~ root# ps -ef|grep ssh
501 5119 182 0 0:00.01 ?? 0:00.03 /usr/bin/ssh-agent -l
0 5446 1 0 0:00.00 ?? 0:00.00 /usr/libexec/launchproxy /usr/sbin/sshd -i

Hopefully this will help you or others.

Message was edited by: K2theCat

Reply

Answer 9

Jul 5, 2008 12:53 AM in response to jquinby

Just my 2 cents. but I would be looking at the file /etc/pam.d/sshd (I'm assuming that you're not running the server version of OS X). And in particular the following line:

session required pam_launchd.so

pam is complaining about the portion if the initialization. Try changing it from "required" to "optional" and see if the message changes or if you make it any further. Also you're running 10.5.2 check to see if any of the updates make changes to pam.

May 26 14:22:21 imac sshd5172: error: PAM: pam opensession(): Cannot make/remove an entry for the specified session

Reply