Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

SOLVED. It was the group writable bit on user_B s home directory, that tricked me.

I'm running out of ideas on this one. Every hint would be highly appreciated.

Consider this setup:

  • A server S running Ubuntu, users boldewyn, user_A and user_B
  • Two laptops A and B, each with a local user boldewyn (has an id_rsa key to log in S) and a second key id_rsa_A / id_rsa_B. All keys are stored in /home/boldewyn/.ssh. Both running Ubuntu.
  • user_A and user_B on S have empty passwords, login should be possible only via publickey and SSH.

    +--------+            +-------------------+            +--------+
    | laptop |            |       server      |            | laptop |
    |   A    |            |         S         |            |   B    |
    |        |            |                   |            |        |
    +--------+    SSH     +-------------------+    SSH     +--------+
    |id_rsa_A|------------|< user_A   user_B >|------------|id_rsa_B|
    +--------+            +-------------------+            +--------+
    |id_rsa  |------------|<    boldewyn     >|------------|id_rsa  |
    +--------+            +-------------------+            +--------+

What works:

  • Log in from any laptop as boldewyn (using id_rsa and S:/home/boldewyn/.ssh/authorized_keys

  • Log in from laptop A as user user_A (using id_rsa_A and S:/home/user_A/.ssh/authorized_keys: ssh -i id_rsa_A user_A@S)

My problem: On laptop B the exactly same setup fails for user_B. I can't log in on S, because for any reason the key is not accepted and the password prompt comes (user_B has no password, that's no option).

What I've checked:

  • On laptop B:

    • Checked the rights of ~/.ssh and all its content
    • put public part of id_rsa_B in boldewyns .authorized_keys and ssh -i id_rsa_B boldewyn@S: works (the key is not corrupt or so)
    • ssh -vvv: Well, not really helpful: Just tells me at one point, that it skips publickey method now. No reason given.
  • On server S:

    • Triple-checked user_Bs .authorized_keys file
    • Checked the rights of /home/*/.ssh and all their contents (especially compared user_A and user_B)
    • Checked that $HOME is set (via sudo -u user_B -i)
    • Checked, that all users are in /etc/ssh/sshd_configs AllowUsers (and AllowGroups, by the way)

Other stuff:

The only difference I can come up with between user_A and user_B is, that I created the latter with adduser -M (don't create a home directory; it already existed before). However, I triple-checked, that /home/user_B and all relevant children are owned by user_B and his primary group.

share|improve this question
Run sshd on S in debug mode: sudo sshd -rdp 1234 - often helps. (-p 1234 is the temporary port which you will SSH to.) – grawity Dec 16 '10 at 13:51
Did you triple-check that /home/user_B (as well as /home/user_B/.ssh and /home/user_B/.ssh/authorized_keys) had the proper permissions not writable except to the user, i.e., mode 755 or more restrictive? – Gilles Dec 16 '10 at 23:04
@grawity: Thanks for the hint. I'll try that immediately today in the evening, when I have the setup available. – Boldewyn Dec 17 '10 at 8:43
@Gilles: Yes, I did. In fact, I compared file by file and dir by dir the permissions set in user_A s case (working) with the ones for user_B (not working). They're exactly the same (apart from file ownership, obviously). – Boldewyn Dec 17 '10 at 8:45
up vote 6 down vote accepted

Did you triple-check that /home/user_B (as well as /home/user_B/.ssh and /home/user_B/.ssh/authorized_keys) had the proper permissions: not writable except to the user, i.e., mode 755 or more restrictive?

share|improve this answer
Solved my problem! – Mingjiang Shi Mar 18 '13 at 8:18

I think it might be related to the way you generated those keys. I would try again. Keys are generated with ssh-keygen facility. Perhaps when one set of keys was generated a passphrase was used in the generation process. You might try just hitting the enter key when you are prompted for a passphrase. Copy the the pub portion of that key to ubuntu. Make sure you delete to offending entry in the .ssh/authorized_keys file. A second thought: if cat the pub file make sure you use a >> (append) rather than > (replace_ when you copy the pub file to the authorized_keys file. (cat >> .ssh/authorized_keys).

I am a bit surprised. I have used my methods at work, using Solaris and Cygwin, and at home on my Linux Lan comprised of Centos, Slackware, Debian, and Ubuntu. Is it possible that you private key doesn't match the public one? When you generate your keys you get a pair, the pubic one will get copied traditionally to the .ssh/authorized keys file under the home directory of the target machine. If you re-generate the keys, the new .pub file must be copied. The new private key will not pair with the old public one. I notice that you seem to have a .authorized_keys folder in the home directory. I have never tried that. I think the normal placement is in the /home/user_name/.ssh/authorized_keys folder. I have never had problems using any version of Solaris from about 6 on up, Freebsd, and various iterations and flavors of Linux. Good Luck


share|improve this answer
The keys seems to be okay: put public part of id_rsa_B in boldewyns .authorized_keys and ssh -i id_rsa_B boldewyn@S: works (the key is not corrupt or so) – Arjan Dec 16 '10 at 15:43
Thanks for the try, apolinsky, but, yes, as Arjan says, I've checked the key by using it with boldewyns account. – Boldewyn Dec 17 '10 at 8:42

You must log in to answer this question.

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