2

I am looking for tips on how to troubleshoot a problem with connecting to a new server via SSH. I am trying to connect using private-key authentication, where SSH uses my local private key to authenticate, without prompting for a password, but running into problems with that.

When I run ssh root@newserver, the connection succeeds immediately, without prompting me for a password. In contrast, when I run ssh user@newserver, the private-key authentication attempt fails and it prompts me for a password. I'm stumped about why the latter fails. What should I try, to debug this?

Things I've already tried:

  • I've carefully checked /root/.ssh/authorized_keys and /home/user/.ssh/authorized_keys. Both are identical, and both contain my public key.

  • I've carefully checked the permissions on /root/.ssh and /home/user/.ssh directories on newserver. Everything seems fine, and in any case, the permissions are the same for both.

  • I've tried logging in from two different clients, and see the same behavior on both, so I don't think it is client-specific. I can log into other servers successfully from both of those clients.

  • I tried running /usr/sbin/sshd -d -p 2323 on the new server and then connecting using ssh -p 2323 root@newserver and ssh -p 2323 user@newserver. Here's the brain-twisting part: when I launch sshd by hand from the command line, I'm able to log in (both to root and user) via private-key authentication, but when I try to use the system-standard sshd, I can only log in to root but not to user via private-key authentication.

  • I've run ssh -v. I don't see any enlightening messages: with ssh -v root@newserver, I get

    debug1: Offering DSA public key: /home/user/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433

    With ssh -v user@newserver, I get

    debug1: Offering DSA public key: /home/daw/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

    Adding more -v's doesn't lend any insight; with ssh -vvvvv bingen.cs.berkeley.edu, I get

    debug1: Offering DSA public key: /home/daw/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

    so no indication of why the attempt to log in via private-key authentication failed.

This is Fedora 21, openssh-6.6.1p1-11.1.fc21.x86_64.

Improve this question
3
  • This sounds like a permission issue on the server. The files in ~/.ssh as well as that folder itself have to follow certain rules (ownership/permissions), if StrictModes yes is set in sshd_config. To diagnose issues in general follow my guide here.
    – 0xC0000022L
    Commented Jan 24, 2015 at 20:51
  • Also, could you show us the output of grep -v '^[[:space:]]*$' /etc/ssh/sshd_config |grep -v '^#' in an edit, so we can see what may be missing/wrong in the sshd_config file?
    – 0xC0000022L
    Commented Jan 24, 2015 at 20:55
  • 1
    What about the server logs? Is SELinux enforcing?
    – Gilles 'SO- stop being evil'
    Commented Jan 24, 2015 at 23:54

3 Answers 3

Reset to default
3

I think nlu has pointed into the right direction.

The generally better way to trace down ssh problems is by stopping the sshd on the server side and then start it with $(which sshd) -d.

That will give you more meaningful error messages in almost all cases.

Update: Sorry - you already did this.

There seems to be one difference between sshd on the cli and the service: SELINUX.

On the CLI it is not as restrictive. Do you have selinux enabled? If so - check the se-logs/settings!

Improve this answer
4
  • S/he's doing that (3rd point) although I guess s/he meant to type sshd there. Also, stopping the main SSH server is a bad idea on a headless server. Just because some user has connection issues, shouldn't prevent you as the admin to access the machine. I.e. use an alternative port. Check out this guide. Also IIRC, output goes to the log for your command. With -D it goes to the terminal.
    – 0xC0000022L
    Commented Jan 24, 2015 at 21:14
  • @0xC0000022L I did not read that third point. Right. But I remember having a similar issue with selinux enabled. I updated my answer accordingly.
    – Nils
    Commented Jan 24, 2015 at 22:17
  • nice catch. That could be a reason. Since I don't use Fedora most of the time, I would not have thought of that.
    – 0xC0000022L
    Commented Jan 24, 2015 at 22:33
  • Nice catch, Nils! You got it exactly -- it was SELinux.
    – D.W.
    Commented Jan 25, 2015 at 1:38
2

You should check the ownership and permissions of /home/user/.ssh/authorized_keys too.

Improve this answer
1

Turns out it was a SELinux permissions problem with files in ~/.ssh/. I copied the files from a backup stored on an external drive, where I guess they had received different labels, and they kept their incorrect labels.

I should have known. When experiencing puzzling failures that could be permission issues, always check SELinux.

The fix: restorecon -r /home/user/.ssh.

Improve this answer

You must log in to answer this question.

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