|
|
#1 |
|
Prospect
Join Date: Jan 2004
Location: Los Angeles, CA
Posts: 17
|
For a few of my users, I use rsync to backup their home directories from our file server (OS X Server 10.4.8). I have a script that runs twice a day to do this for a list of users. That part works. I use public key authentication to get this done and I upload the keys to the users .ssh directory (on their computer's local home directory) and verify access from the server end as part of the set-up process.
This is where it gets strange for one user's account, in particular. And as the gods would deem it, it has to be my boss's PowerMac G5 (running 10.4.10), of course :-\. Anyway, I performed the usual to get this going:
I'm mystified that this fails on that one account. Anyone have any suggestions on why this is so? Thanks in advance.
__________________
"Experience is that marvelous thing that enables you to recognize a mistake when you make it again." ~ F. P. Jones |
|
|
|
|
|
#2 |
|
Prospect
Join Date: Aug 2006
Posts: 47
|
Hmm... well nothing comes to my mind, but you might try running "ssh -v" (verbose) with both the account that works and the one that is failing, and then compare the output. It may shed some light on what specifically is different.
|
|
|
|
|
|
#3 |
|
Major Leaguer
Join Date: May 2006
Location: Paris, France
Posts: 311
|
Have you looked at his ~/.ssh/config file?
It's where the options to use with ssh are stored. You can override them by the command line for one shot. Have a look at the man of ssh_config (man ssh_config in the terminal). Look specifically this section: PreferredAuthentications and PubkeyAuthentication. As Bryan stated, the verbose mode can help understanding what's wrong. Multiple -v options increase the verbosity. The maximum is 3. Hope that help. |
|
|
|
|
|
#4 |
|
Prospect
Join Date: Jan 2004
Location: Los Angeles, CA
Posts: 17
|
Thanks bryanc and Lutin for your suggestions. I put the it in max verbose mode to see what's happening between these two accounts. For the one that works, here is what seems the important passage:
Code:
debug1: Trying to start again debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /private/var/root/.ssh/identity debug3: no such identity: /private/var/root/.ssh/identity debug1: Offering public key: /private/var/root/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive debug1: Offering public key: /private/var/root/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-dss blen 818 debug2: input_userauth_pk_ok: fp fe:60:fc:54:2e:aa:de:30:15:1a:82:c4:f1:44:c0:6b debug3: sign_and_send_pubkey debug1: read PEM private key done: type DSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 0 debug3: tty_make_modes: ospeed 9600 debug3: tty_make_modes: ispeed 9600 debug3: tty_make_modes: 1 3 debug3: tty_make_modes: 2 28 debug3: tty_make_modes: 3 127 debug3: tty_make_modes: 4 21 debug3: tty_make_modes: 5 4 debug3: tty_make_modes: 6 255 debug3: tty_make_modes: 7 255 debug3: tty_make_modes: 8 17 debug3: tty_make_modes: 9 19 debug3: tty_make_modes: 10 26 debug3: tty_make_modes: 11 25 debug3: tty_make_modes: 12 18 debug3: tty_make_modes: 13 23 debug3: tty_make_modes: 14 22 debug3: tty_make_modes: 17 20 debug3: tty_make_modes: 18 15 debug3: tty_make_modes: 30 0 debug3: tty_make_modes: 31 0 debug3: tty_make_modes: 32 0 debug3: tty_make_modes: 33 0 debug3: tty_make_modes: 34 0 debug3: tty_make_modes: 35 0 debug3: tty_make_modes: 36 1 debug3: tty_make_modes: 38 1 debug3: tty_make_modes: 39 1 debug3: tty_make_modes: 40 0 debug3: tty_make_modes: 41 1 debug3: tty_make_modes: 50 1 debug3: tty_make_modes: 51 1 debug3: tty_make_modes: 53 1 debug3: tty_make_modes: 54 1 debug3: tty_make_modes: 55 0 debug3: tty_make_modes: 56 0 debug3: tty_make_modes: 57 0 debug3: tty_make_modes: 58 0 debug3: tty_make_modes: 59 1 debug3: tty_make_modes: 60 1 debug3: tty_make_modes: 61 1 debug3: tty_make_modes: 62 1 debug3: tty_make_modes: 70 1 debug3: tty_make_modes: 72 1 debug3: tty_make_modes: 73 0 debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 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 131072 Last login: Thu Sep 20 15:38:24 2007 from cshsmedaff3.csm Welcome to Darwin! [romanoff:~] admin% Code:
debug1: Trying to start again debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /private/var/root/.ssh/identity debug3: no such identity: /private/var/root/.ssh/identity debug1: Offering public key: /private/var/root/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive debug1: Offering public key: /private/var/root/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password:
__________________
"Experience is that marvelous thing that enables you to recognize a mistake when you make it again." ~ F. P. Jones |
|
|
|
|
|
#5 |
|
Prospect
Join Date: Aug 2006
Posts: 47
|
The ~/.ssh/config (and also /etc/ssh_config) are the ssh client configuration files. Unless I misread you, changing them on the target machine (i.e. your bosses), isn't going to change anything, since you are initiating the connection from your server to the ssh daemon on your bosses computer. Your server is the ssh client in this scenario, and the G5 is the ssh server.
The file /etc/sshd_config controls incoming ssh connections. Look specifically for the string "Match User" in that file (I'm pretty sure that's the only way the server can be configured to respond differently based on which user it is dealing with). |
|
|
|
|
|
#6 |
|
Prospect
Join Date: Jan 2004
Location: Los Angeles, CA
Posts: 17
|
Thanks for the clarification. I'm going to try this.
__________________
"Experience is that marvelous thing that enables you to recognize a mistake when you make it again." ~ F. P. Jones |
|
|
|
|
|
#7 |
|
Major Leaguer
Join Date: May 2006
Location: Paris, France
Posts: 311
|
How did it go? Is your problem fixed?
|
|
|
|
|
|
#8 |
|
Prospect
Join Date: Jan 2004
Location: Los Angeles, CA
Posts: 17
|
Got pulled away to server with new hardware that's keeps going deaf to AD. But, I plan on coming back to try the recent suggestion. Thanks.
__________________
"Experience is that marvelous thing that enables you to recognize a mistake when you make it again." ~ F. P. Jones |
|
|
|
|
|
#9 |
|
Triple-A Player
Join Date: Jan 2005
Location: Rochester, NY
Posts: 123
|
I'll continue as I have the same issue .. I've been banging my head against the wall. I have 4 Macs .. ssh public key authentication is working on all except for 1. I added my 'home' public key to my daughters Mac ~/.ssh/authorized_keys2 .. I validated that permissions on .ssh and the files within are valid on her Mac. I always fail public key authentication and fall through to Password authentication. I thought This would have worked once I upgraded my daughters Mac to Leopard .. but still have the same problem. I ran a trace .. Hoping someone can spot the issue .. (I have 2 keys - 'home' and 'work'. These are also listed within the 'IdentityFile' records in my ~/.ssh/config and I should be authenticating on the 'home' key :
[22:13:31][richard@RLRMBP]~/.ssh$ ssh -vvv stephanie@192.168.168.101 OpenSSH_4.5p1, OpenSSL 0.9.7l 28 Sep 2006 debug1: Reading configuration data /Users/richard/.ssh/config debug1: Reading configuration data /etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.168.101 [192.168.168.101] port 22. debug1: Connection established. debug3: Not a RSA1 key file /Users/richard/.ssh/work. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /Users/richard/.ssh/work type 1 debug3: Not a RSA1 key file /Users/richard/.ssh/home. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /Users/richard/.ssh/home type 1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5 debug1: match: OpenSSH_4.5 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.5 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 137/256 debug2: bits set: 494/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /Users/richard/.ssh/known_hosts debug2: key_type_from_name: unknown key type '1024' debug3: key_read: missing keytype debug3: check_host_in_hostfile: match line 58 debug1: Host '192.168.168.101' is known and matches the RSA host key. debug1: Found key in /Users/richard/.ssh/known_hosts:58 debug2: bits set: 502/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /Users/richard/.ssh/work (0x103570) debug2: key: /Users/richard/.ssh/home (0x1081b0) 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_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /Users/richard/.ssh/work debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Offering public key: /Users/richard/.ssh/home debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password: Thanks for any pointers |
|
|
|
|
|
#10 |
|
Prospect
Join Date: Feb 2004
Location: a padded cell with nothing but my laptop and the voices in my head
Posts: 19
|
Solution?
Did anyone have any luck pinpointing the issue of the problems in this thread? I'm having the exact issue.
Thanks for any posting back of the solution. Scott
__________________
.................. ........O........ .....~//~...... .....~\\~...... ......../......... ........\......... .................. |
|
|
|
|
|
#11 |
|
Triple-A Player
Join Date: Jan 2002
Posts: 158
|
One thing that has not been mentioned is whether the logins to these accounts actually works when the correct password is entered. In my work with ssh, I have come across two issues that can cause ssh to fail with what seem to be authentication issues.
1) Expired passwords. Even when using pubkey, if the password is expired, ssh may still fail. This is most common on systems using PAM. 2) Permissions. Some of the posts (inc. the OP) mention checking permissions on .ssh and the contained files. It should be noted that ssh also cares about the permissions on the home directory of the user. If these are too permissive (and/or too restrictive), ssh will fail. If someone in this thread could post the results of Code:
ls -ld ~problemuser |
|
|
|
|
|
#12 | |||||||||||||||||||
|
Prospect
Join Date: Jan 2004
Location: Los Angeles, CA
Posts: 17
|
Finally surfaced again and reviewed all of the replies here. And, it came down to permissions, as expected by others in this thread. After a failed attempt, I tail'd the secure log (/var/log/secure.log). I noted this there:
Code:
Authentication refused: bad ownership or modes for directory ...
Performing these commands on the user's account did the trick. Thank you, heartily, for those who replied and helped me (and hopefully, others), find this solution.
__________________
"Experience is that marvelous thing that enables you to recognize a mistake when you make it again." ~ F. P. Jones |
|||||||||||||||||||
|
|
|
|
|
#13 | |||||||||||||||||||||||
|
Guest
Posts: n/a
|
Thank you!!!!
WOW, I have tried and re-tried so many tutorials on this until I stumbled on this little nugget about even the permissions on the home directory mattering. I ran `chmod g-w .` from my home directory and now everything works!!!! THANKS!!! |
|||||||||||||||||||||||
|
![]() |
|
|