Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have two systems named Interface(10.1.1.87) and Client-Interface(10.1.1.91). I want to automatically mount an sshfs share from Client-Interface on Interface on boot.

I am using the command:

sshfs mc@10.1.1.91:/opt/lampp/ /media/CIDrive/ -o allow_other

But it asks for my password. I tried the following to make it password-less:

  1. As root on Interface:

    # ssh-keygen -t rsa
    # chmod 700 ~/.ssh
    # cat ~/.ssh/id_rsa.pub | ssh mc@10.1.1.91 'cat > .ssh/authorized_keys'
    
  2. On Client-Interface I added to the sshd_config file:

    RSAAuthentication yes
    PubkeyAuthentication yes
    StrictModes no
    

and restarted the SSH daemon. Nonetheless, it is still asking for the password:

root@JMGDDS-Interface:~# ssh -v mc@10.1.1.91
OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.1.1.91 [10.1.1.91] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-3ubuntu1
debug1: match: OpenSSH_5.1p1 Debian-3ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1
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<1024<8192) 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: Host '10.1.1.91' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
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
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
mc@10.1.1.91's password:

The permission for the .ssh folder is 700; .pub and authorized_keys are 600. What could be the possible cause? How can I fix it?

share|improve this question
    
Do you have access to the ssh logs on 10.1.1.91, and if so, could you post the relevant parts? –  Chris Down Sep 20 '11 at 19:42
1  
Why didn't you just use ssh_copy_id? It should take care of all permissions and oddities. –  Marco Ceppi Sep 20 '11 at 20:06
    
Sep 20 16:18:47 JMGDDS-ClientInterface sshd[25319]: pam_unix(sshd:session): session closed for user mc Sep 20 16:19:05 JMGDDS-ClientInterface sshd[25461]: Accepted password for mc from 10.1.1.87 port 37662 ssh2 Sep 20 16:19:05 JMGDDS-ClientInterface sshd[25461]: pam_unix(sshd:session): session opened for user mc by (uid=0) –  Pradipto Sep 20 '11 at 20:14
    
I have tried using ssh-copy-id also but to no avail. –  Pradipto Sep 20 '11 at 20:15
    
If all else fails, run the ssh daemon with ssh -d or ssh -dd. You'll see a lot of logs. If you decide to post them, be careful, there'll be a little private information here and there. –  Gilles Sep 21 '11 at 0:03
show 1 more comment

5 Answers

I haven't checked recently but if any directory in the path to .ssh is world writable SSH would refuse to use authorized keys from it. These permissions could allow other users to fake you .ssh directory.

If the home directory is writable by anyone else it will not be used unless StrictModes is turned off.

share|improve this answer
add comment

Check that in your local machine you have a file ~/.ssh/id_dsa with mode 600 and that the contents of the local~/.ssh/id_dsa.pub are also in the remote ~/.ssh/authorized_keys file.

I'm saying id_dsa because it's one of your private keys according to your logs (you also have an identity private key). Maybe you can specify which PrivateKey you want to use in your ~/.ssh/config under Host your.server.here. Alternatively, you may check the same for ~/.ssh/id_rsa and ~/.ssh/id_rsa if you have an rsa key pair.

Using ssh_copy_id -i ~/.ssh/id_dsa.pub user@host (if available) is another way to setup key pairs, that also takes care of permissions etc.

share|improve this answer
    
i executed ssh-keygen -t rsa. –  Pradipto Sep 20 '11 at 20:54
    
unchecked the line "IdentityFile ~/.ssh/id_rsa" in /etc/ssh/ssh_config. Still no luck –  Pradipto Sep 20 '11 at 21:05
    
@Pradipto: you don't need to change /etc/ssh/ssh_config, return it to it's original state. Remove the local side files ~/.ssh/id_dsa* and ~/.ssh/identity if you do not use them for some other server. Leave only ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub and try again. If it doesn't work, use the ssh_copy_id as described and try again. –  forcefsck Sep 20 '11 at 21:28
add comment

Check the permissions on host 10.1.1.91 of directory .ssh/, and file .ssh/authorized_keys Perhaps the sshd on that host doesn't like the permissions on that end.

share|improve this answer
    
drwx------ 2 mc mc 4096 2011-09-20 15:32 .ssh –  Pradipto Sep 20 '11 at 20:18
    
-rw------- 1 mc mc 403 2011-09-20 16:14 .ssh/authorized_keys –  Pradipto Sep 20 '11 at 20:18
add comment

How did your sshd_conf looks like? Are you sure that "StrictModes no" is not commented?

share|improve this answer
    
StrictModes is set to no. –  Pradipto Sep 20 '11 at 20:11
    
Can this be an issue with pam? –  Pradipto Sep 20 '11 at 20:23
    
Because there is no error in log after line "Next authentication method: publickey" makes me think that it is a server problem (no response was returned); use LogLevel DEBUG3 on server and watch the /var/log/secure. –  migabi Sep 20 '11 at 21:04
    
I have replicate your config on a fresh Centos and it is working. This is the config: Protocol 2 SyslogFacility AUTHPRIV StrictModes no RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication yes ChallengeResponseAuthentication no GSSAPIAuthentication yes GSSAPICleanupCredentials yes UsePAM yes AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS X11Forwarding yes Subsystem sftp /usr/libexec/openssh/sftp-server –  migabi Sep 21 '11 at 6:45
add comment

Run the server in debug mode.

On the server, as root:

# /etc/init.d/ssh stop
# /usr/sbin/sshd -ddd

Now connect with the client, and read the server's debug output. This should give you an indication as to why you can't get in. Correct whatever that is.

If you happen to be running RedHat (or possibly Fedora) I ran into a problem with pam_fprintd not being installed.

share|improve this answer
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.