Check /etc/ssh/sshd_config. Do you have the following settings enabled?

Also as someone else recommended you allow root, I do not recommend that. The root user is the most common brute forced account on any system with ssh open to world. Firewalls aside you should not allow the root login access ever. I would recommend this scheme...

Which means users have to be apart of the wheel or users group in order to log in. Normally the wheel group is for ssh users and users allowed sudo access which is why the second group is recommended for normal users.

Also what do the following logs say (depending on your OS):
Authenticate again and see what the log output says on the server.

1 members found this post helpful.

Yes, the home directory of root is /root and I put all the keys in /root/.ssh/authorized_keys

I also had a problem with PAM as it's required on sshd in debian with public keys.

1 members found this post helpful.

Yes, PAM is enabled in my sshd_config. Thanks for the suggestion though.

Did you see my previous comment about the auth logs? What do they say when you attempt to auth?

Oh I fully agree with you here. If I had my way we'd be doing things differently, but this is the third iteration of a machine we're building and it would be non-trivial for me to convince everyone that we need to do this. Everything we need to do on this machine needs root access anyway.

Fortunately, this particular machine does not have a direct connection to the outside world. Its part of a small local network of machines, so I have to first login to one of the two machines that do have an external connect and then from there ssh into this internal system. And we never ssh in as root to those machines with external access (I'm pretty sure root ssh access is disabled).

/var/log/auth.log is an empty file, like /var/log/messages. I think the reason this is done is that this is an embedded system with a very limited amount of diskspace (some internal flash and a SD memory card), so the people who built/configured this machine throw out log messages to keep them from consuming precious disk capacity.

Well I figured out the problem. After searching for information on one of the debug messages I got earlier ("we did not send a packet, disable method"), I came across a forum thread where someone said they fixed their issue by changing the permissions on the home directory, as ssh apparently does not like it to have 777 permissions. I checked, and sure enough root had these permissions:

I'm not sure what the "t" was for, or whether it was relevant to this problem. After changing the permissions on /root to 755 ssh login without requiring a password worked just fine.


Thanks for your help everyone. I wouldn't have found the answer myself if you weren't all helping to guide me to the solution.

It doesn't like the .ssh directory to have permissions other than 700. I haven't heard of it checking on the home directory. I wonder if ssh is barfing because of the .ssh permissions?

No I checked .ssh multiple times and it did indeed have 700 permissions.

Since you have already made some attempt first of all remove all content from /root/.ssh/konown_hosts and /root/.ssh/authorized_keys in both machine, that means your machine and the machine you wish to login.

Follow below steps,

In your machine execute following commands

#ssh-keygen (give passphrase when prompting)

#ssh-copy-id root@<IP of remote machine>

#ssh root@IP

First time it will prompt to enter passphrase, hereafter it will not prompt.

If it is not works, Please mail me #sham_antony@aol.com#

just use "ssh-copy-id" to get your key to the machine where you want to log in.

And allow root login is .... erm... NEVER ALLOW THAT
log in as normal user and issue then a "su" or "sudo"

I had this same problem stump me for over 2 hours. Continually applying the same fixes outlined here. Then I looked at the shadow file and saw that the account was locked. Unlocking the account enabled the ssh key login to work. It would simply fail the login with no error message.