Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I know that you can use ssh-keygen to generate a public/private key pair. Then you can install the public key on a remote server. You can then login without supplying a password. I haven't been successful in setting up key-based authentication. SSH always prompts for a password.

Can someone help me understand the debug information?


Sever information

Server A

-bash-3.00$ uname -a
SunOS cusd2 5.10 Generic_118833-33 sun4u sparc SUNW,UltraAX-i2

Server B

bash-2.05$ uname -a
SunOS apc_dev1db1 5.9 Generic_118558-27 sun4u sparc SUNW,Sun-Fire-V240

plant key

I've generated the key pair on Server A and then copied the public key to Server B. I then renamed it to authorized_keys.

login with debug info

-bash-3.00$ ssh sybase@apc_dev1db1 -v  
Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f   
debug1: Reading configuration data /etc/ssh/ssh_config   
debug1: Rhosts Authentication disabled, originating port will not be trusted.  
debug1: ssh_connect: needpriv 0  
debug1: Connecting to apc_dev1db1 [192.168.1.44] port 22.   
debug1: Connection established.    
debug1: identity file /export/home/attlmw1/.ssh/identity type -1  
debug1: identity file /export/home/attlmw1/.ssh/id_rsa type 1  
debug1: identity file /export/home/attlmw1/.ssh/id_dsa type -1   
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1  
debug1: no match: Sun_SSH_1.1  
debug1: Enabling compatibility mode for protocol 2.0  
debug1: Local version string SSH-2.0-Sun_SSH_1.1  
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible  
Unknown code 0  
)  
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: Peer sent proposed langtags, ctos: en-US,es,fr,hi-IN,ja-JP,ko,ko-KR,zh,zh-CN,zh-HK,zh-TW,en-CA,es-MX,fr-CA,ja,th,th-TH,i-default  
debug1: Peer sent proposed langtags, stoc: en-US,es,fr,hi-IN,ja-JP,ko,ko-KR,zh,zh-CN,zh-HK,zh-TW,en-CA,es-MX,fr-CA,ja,th,th-TH,i-default  
debug1: We proposed langtags, ctos: i-default  
debug1: We proposed langtags, stoc: i-default  
debug1: Negotiated lang: i-default  
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent  
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP  
debug1: Remote: Negotiated main locale: C  
debug1: Remote: Negotiated messages locale: C  
debug1: dh_gen_key: priv key bits set: 139/256  
debug1: bits set: 1592/3191  
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent  
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY  
debug1: Host 'apc_dev1db1' is known and matches the RSA host key.  
debug1: Found key in /export/home/attlmw1/.ssh/known_hosts:1  
debug1: bits set: 1595/3191  
debug1: ssh_rsa_verify: signature correct  
debug1: newkeys: mode 1  
debug1: SSH2_MSG_NEWKEYS sent  
debug1: expecting SSH2_MSG_NEWKEYS  
debug1: newkeys: mode 0  
debug1: SSH2_MSG_NEWKEYS received  
debug1: done: ssh_kex2.  
debug1: send SSH2_MSG_SERVICE_REQUEST  
debug1: got SSH2_MSG_SERVICE_ACCEPT  
debug1: Authentications that can continue: publickey,password,keyboard-interactive  
debug1: Next authentication method: publickey  
debug1: Trying private key: /export/home/attlmw1/.ssh/identity  
debug1: Trying public key: /export/home/attlmw1/.ssh/id_rsa  
debug1: Authentications that can continue: publickey,password,keyboard-interactive  
debug1: Trying private key: /export/home/attlmw1/.ssh/id_dsa  
debug1: Next authentication method: keyboard-interactive  
Password:  

The permission of related files

bash-2.05$ uname -a  
SunOS apc_dev1db1 5.9 Generic_118558-27 sun4u sparc SUNW,Sun-Fire-V240  
bash-2.05$ ls -ld .ssh/  
drwx------   2 sybase   sybase       512 Sep  6 13:16 .ssh/  
bash-2.05$  
bash-2.05$ ls -l .ssh/authorized_keys  
-rw-------   1 sybase   sybase       224 Sep  6 08:31 .ssh/authorized_keys  


-bash-3.00$ uname -a  
SunOS cusd2 5.10 Generic_118833-33 sun4u sparc SUNW,UltraAX-i2  
-bash-3.00$  
-bash-3.00$ ls -ld .ssh/  
drwx------   2 attlmw1  other        512 Sep  6 08:08 .ssh/  
-bash-3.00$ ls -l .ssh/  
total 6  
-rw-------   1 attlmw1  other        887 Sep  5 18:10 id_rsa  
-rw-r--r--   1 attlmw1  other        223 Sep  5 18:10 id_rsa.pub  
-rw-r--r--   1 attlmw1  other        234 Sep  6 08:08 known_hosts  
share|improve this question
3  
what are the directory permissions on ~/.ssh and authorized_keys? Solaris boxes are stricter about this than Linux. chmod 700 ~./ssh and chmod 600 ~/.ssh/authorized_keys should work on a Solaris server. –  Chad Feller Sep 6 '11 at 4:03
    
Thank you Quanta. I found out where is the issue. When I plant the publick key on remote server. I didn`t use scp or ftp. I copy the content and paste it on target server. Here is the strange thing. The orignal publick key content is one line. But when I copy and paste it to remote server, it becomes two line. I use scp instead copy&&paste to try. It works . –  Mingwei Li Sep 6 '11 at 5:36
1  
@MingweiLi: Please create an answer with this solution and accept it when you are able to. –  Iain Sep 6 '11 at 6:17
    
@lain thank you. I`m a fresher here. System told me can not answer my own question in 8 hours –  Mingwei Li Sep 6 '11 at 6:54
add comment

4 Answers

Make sure that:

  • the authorized_keys has permission 600.
  • the sybase's $HOME folder and $HOME/.ssh has permission 700 and owned by sybase.

Also take a look at sshd logs on server B, it will tell you more details.

share|improve this answer
    
The perms on $HOME directories can be much more open than 700 on Solaris. My Solaris boxes all use 755 by default without any ssh problems. –  Iain Sep 6 '11 at 6:29
add comment
up vote 2 down vote accepted

The problem is on the authorized_keys file.
While planting the publick, the correct action is scp the publick key to remote server and add it to the authorized_keys file.
But what i do is copy the content and paste it to authorized_keys file. On putty this will make the orignal content changed. The orignal line is only one line. But after i copy and paste it turn out to be two lines.

share|improve this answer
add comment

On solaris, you should set the user's home directory to 755, .ssh directory to 755, and .ssh/authorized_keys to 600.

share|improve this answer
add comment

In the future, rather than copying and pasting the key, you may want to use this command instead:

ssh-copy-id

This will allow you to not only copy your public key directory to your authorized_key and set the correct permissions.

share|improve this answer
1  
Solaris ships with its own version of SSH (Sun_SSH), which doesn't include ssh-copy-id. –  Chad Feller Sep 7 '11 at 4:25
    
Oh, nice. One more reason to move to Open Source software. :) –  Rilindo Sep 7 '11 at 13:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.