|
|
Resolve a ssh public key connectivity issue
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 2222The -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_toThis 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-interactiveWhich 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 ssh2This 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.
Resolve a ssh public key connectivity issue
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 |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.07 seconds |
|