Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Resolve a ssh public key connectivity issue Network
Last night, I was setting up password-free SSH connections (using, basically, the information in this ancient hint) between my machines here in the house -- at some point during all the 10.5 upgrading, I'd broken it between a couple of the boxes. Everything worked fine on the mini and the MacBook Pro, and when connecting from the Mac Pro to the other machines. Connecting to the Mac Pro, however, still required entering my password. I double and triple checked everything with the key files, tried RSA and DSA keys, and ran ssh in triple-debug (-vvv) mode. Nothing was any help at all.

Turning to Google, I (ironically) found the solution right here on our own forum site -- in a thread that had been updated with the solution only a couple days ago. In a nutshell, the problem was that the permissions on my user's folder on the Mac Pro were incorrect (and Repair Permissions in Disk Utility didn't fix them). In Terminal, I ran the first of the three commands shown in the thread (as only my top-level user's folder had incorrect permissions)
$ chmod go-w ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys
Once the permissions were fixed, ssh worked as expected. But the real hint in the forum thread wasn't the actual fix; it was a tidbit on how to diagnose the problem in the first place -- one that may be useful for other sorts of ssh connectivity issues as well.

Despite using triple-verbose mode with ssh, it still didn't tell me enough to fix the problem -- the feedback in verbose mode contained no detail that would help identify why I was still being asked for a password. As noted in the forum thread, however, there is a spot where you can find more details: in the secure.log file in /var/log on the machine you're trying to connect to. So on the Mac Pro, I ran sudo tail -f /var/log/secure.log, then tried to connect to the Mac Pro from the mini. On the Mac Pro's screen, the problem then appeared, clear as day:

Apr 23 21:10:55 MacPro sshd[16329]: Authentication refused: bad ownership or modes for directory /Users/robg

It would be really nice if the ssh daemon provided this information as part of the verbose output, but it doesn't (probably because it would give too much info to attackers?). So if you're having ssh connectivity issues and verbose mode isn't helping, try tailing the secure.log file on the machine you're connecting to; it may provide the detail you need to solve the problem.
    •    
  • Currently 2.33 / 5
  You rated: 1 / 5 (9 votes cast)
 
[19,025 views]  

Resolve a ssh public key connectivity issue | 4 comments | Create New Account
Click here to return to the 'Resolve a ssh public key connectivity issue' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Resolve a ssh public key connectivity issue
Authored by: kentmartin on Apr 24, '08 04:44:35PM
It would be really nice if the ssh daemon provided this information as part of the verbose output, but it doesn't (probably because it would give too much info to attackers?).
Technically, the daemon does give you the information you want, it just doesn't tell the client about it, as you mention - for security reasons, and, quite rightly too. In certain circumstances it would allow an attacker to see than an account of a certain name does in fact exist (which could be handy for sending spam), or, it would give valuable clues as to the filesystem layout and permissions. The way I test keyless ssh operations when it is really giving me grief is the following. On the host machine (machine I am trying to ssh to) I run the following as root:
/usr/sbin/sshd -d -p 2222
The -d tells sshd not to detach from the controlling terminal (ie, give you all the yummy debugging stuff to the terminal session you ran it in) and the -p tells it to listen on port 2222 (instead of the normal port 22). You can pick a number other than 2222 if you like, as long as it isn't a port used by something else. You'll then get something on your screen like this (my hostname is saraswathi):
saraswathi:~ root# /usr/sbin/sshd -d -p 2222
debug1: sshd version OpenSSH_4.7p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-p'
debug1: rexec_argv[3]='2222'
debug1: Bind to port 2222 on ::.
Server listening on :: port 2222.
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
Now all I have to do is tell a client to connect to it on port 22. On the machine I am trying to ssh from
ssh -v -p 2222 machine_I_am_trying_to_ssh_to
This basically says do a verbose connection on port 2222 tomachine_I_am_trying_to_ssh_to You'll then see something like this (I am actually using the same machine as both client and server, but that doesn't matter):
kent@saraswathi ~ $ ssh -p 2222 -v saraswathi
OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /Users/kent/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to saraswathi [192.168.1.70] port 2222.
debug1: Connection established.
debug1: identity file /Users/kent/.ssh/identity type -1
debug1: identity file /Users/kent/.ssh/id_rsa type -1
debug1: identity file /Users/kent/.ssh/id_dsa type 2
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
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: checking without port identifier
The authenticity of host '[saraswathi]:2222 ([192.168.1.70]:2222)' can't be established.
RSA key fingerprint is 5a:9d:d1:3b:f0:45:62:dc:9f:af:e1:d5:79:68:46:84.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[saraswathi]:2222,[192.168.1.70]:2222' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/kent/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /Users/kent/.ssh/identity
debug1: Trying private key: /Users/kent/.ssh/id_rsa
debug1: Next authentication method: keyboard-interactive
Which is all very nice, but is only telling you what is happening on the client side, which is only half the story. Flick back over to your server (the to machine side) and you'll see a whole lot more:
debug1: fd 5 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.1.70 port 49747
debug1: Client protocol version 2.0; client 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
debug1: permanently_set_uid: 75/75
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user kent service ssh-connection method none
debug1: attempt 0 failures 0
debug1: Checking with Service ACLs for ssh login restrictions
debug1: call to mbr_user_name_to_uuid with  suceeded to retrieve user_uuid
debug1: Called mbr_check_service_membership with isMember  with status 
debug1: PAM: initializing for "kent"
debug1: PAM: setting PAM_RHOST to "saraswathi.config"
Failed none for kent from 192.168.1.70 port 49747 ssh2
debug1: userauth-request for user kent service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 501/20 (e=0/0)
debug1: trying public key file /Users/kent/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 501/20 (e=0/0)
debug1: trying public key file /Users/kent/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for kent from 192.168.1.70 port 49747 ssh2
debug1: userauth-request for user kent service ssh-connection method keyboard-interactive
debug1: attempt 2 failures 2
debug1: keyboard-interactive devs 
debug1: auth2_challenge: user=kent devs=
debug1: kbdint_alloc: devices 'pam'
debug1: auth2_challenge_start: trying authentication method 'pam'
Postponed keyboard-interactive for kent from 192.168.1.70 port 49747 ssh2
This last set of lines should tell you what you need to know, ie, in the above case, I think the following is what happens. 1) It hands me to PAM and says, will you let this guy on with no password (not the same thing as having the correct key - I mean, can this guy log on with no credentials whatsoever). PAM says no (failure 1).
2) The client has sent a key.
2a) Have a look at /Users/kent/.ssh/authorized_keys and see if the key the client sent is allowed in there.
2b) In the same manner as 2a, check authorized_keys2
3) OK, those last 2 methods have failed - now try an interactive password auth type (ie, get user to punch in their password). Prepare to hand the password to PAM (pluggable authentication module) to see if it is correct.

Hope this helps someone. The same method will work on any system which runs sshd. You will need root access to the to system.

[ Reply to This | # ]
Resolve a ssh public key connectivity issue
Authored by: kentmartin on Apr 24, '08 04:48:02PM
There are a few typos in the comment above, but one that is particularly confusing is:

Now all I have to do is tell a client to connect to it on port 22. On the machine I am trying to ssh from

It should read

Now all I have to do is tell a client to connect to it on port 2222. On the machine I am trying to ssh from

[ Reply to This | # ]
Resolve a ssh public key connectivity issue
Authored by: musenut on Jan 10, '10 08:11:11AM

I am having an ssh connectivity issue with a iMac running 10.5.8. We had a G5 in the office that we were able to set up to remotely access from behind the firewall by opening port 22 and setting up remote login. The iMac however refuses to let us connect. We enabled remote login on the iMac, gave it the G5's old IP address that worked over port 22, and set it's firewall open to all incoming connections. I repaired permissions but connection is still refused. Can I use this method of "tailing the secure.log file on the machine you're connecting to" for troubleshooting this problem? And if so - can someone walk me thru it step by step because I know very little about unix commands and using terminal.

Any help much appreciated!

-kristy

Edited on Jan 10, '10 08:16:50AM by musenut



[ Reply to This | # ]
Resolve a ssh public key connectivity issue
Authored by: AlwaysLearning on Aug 06, '14 05:13:45AM

There's no /var/log/secure.log on OS X 10.9.4 (at least on the standard desktop install). You can see some useful output from sshd on the HOST machine, though, by running:

tail -n 200 -f /var/log/system.log | grep sshd



[ Reply to This | # ]