1

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?

Michael Mrozek
  • 93,103
  • 40
  • 240
  • 233
Pradipto
  • 11
  • 1
  • 2
  • 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
  • 2
    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 'SO- stop being evil' Sep 21 '11 at 00:03
  • What distro are you running? – bahamat Sep 22 '11 at 19:03

6 Answers6

3

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.

BillThor
  • 8,965
1

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.

forcefsck
  • 7,964
  • 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
0

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

Community
  • 1
user881300
  • 1,529
  • 2
  • 13
  • 14
0

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.

0

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

migabi
  • 191
  • 3
  • 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 06:45
0

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.

bahamat
  • 39,666
  • 4
  • 75
  • 104