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

I am using the command:

sshfs [email protected]:/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 [email protected] '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 [email protected]
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 [] 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 '' 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_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
[email protected]'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?

  • Do you have access to the ssh logs on, and if so, could you post the relevant parts?
    – Chris Down
    Commented Sep 20, 2011 at 19:42
  • 2
    Why didn't you just use ssh_copy_id? It should take care of all permissions and oddities. Commented Sep 20, 2011 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 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
    Commented Sep 20, 2011 at 20:14
  • I have tried using ssh-copy-id also but to no avail.
    – Pradipto
    Commented Sep 20, 2011 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. Commented Sep 21, 2011 at 0:03

6 Answers 6


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.


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.

  • i executed ssh-keygen -t rsa.
    – Pradipto
    Commented Sep 20, 2011 at 20:54
  • unchecked the line "IdentityFile ~/.ssh/id_rsa" in /etc/ssh/ssh_config. Still no luck
    – Pradipto
    Commented Sep 20, 2011 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
    Commented Sep 20, 2011 at 21:28

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

  • drwx------ 2 mc mc 4096 2011-09-20 15:32 .ssh
    – Pradipto
    Commented Sep 20, 2011 at 20:18
  • -rw------- 1 mc mc 403 2011-09-20 16:14 .ssh/authorized_keys
    – Pradipto
    Commented Sep 20, 2011 at 20:18

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

  • StrictModes is set to no.
    – Pradipto
    Commented Sep 20, 2011 at 20:11
  • Can this be an issue with pam?
    – Pradipto
    Commented Sep 20, 2011 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
    Commented Sep 20, 2011 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
    Commented Sep 21, 2011 at 6:45

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.


Too late to answer but I think these two points are very important Check the permission of your home directory in the server as well. I faced a similar problem and the problem was home directory permission. So two things

  1. Your authorized_keys should be 600
  2. Your home directory should be 755

sshd by default logs some messages into /var/log/secure at least in fedora distro. Check there the reason for why you are refused permission.

Look for this line

sshd[1234]: Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_key

sshd[1234]: Authentication refused: bad ownership or modes for file /home/user

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .