I used puttygen to generate both my public and private key files (ssh2, 2048 bit). I have set up the settings in putty correctly and it is using the correct private key file. As for the public key, (I am using these keys for root) it is in /root/.ssh/authorized_keys

I have tried using chmod on .ssh to 700 and on authorized_keys to 400. That did not do anything.

I have googled everywhere as well and it seems I cannot find a solution to this, as I've tried most things. I figured asking here might assist me.

Does anyone have any recommendations? Thanks in advance.

edit: here's an ls -ldZ of my .ssh folder and authorized_keys file

drwx------ root root ?                                /root/.ssh
-rw------- root root ?                                /root/.ssh/authorized_keys
  • give more information. what is remote server distro, version. is there any security layer between your client and server? (SELinux, iptables,...). Capture the audit log on your remote server when trying to connect to see any hint. Enable putty debug would be helpful. – cuongnv23 May 13 '16 at 3:42
  • It's running CentOS 6.7, and as far as I'm aware there is no security layer blocking anything. Where would I look for the audit log? I tried checking the auth log but it seems to not exist. As far as putty debugging goes, do you want the event log? I checked it and it contained quite a bit of information, but leading up to checking the key not much was helpful. – Joel May 13 '16 at 4:11
  • Trying to ssh from Linux box with ssh -vvv could be helpful, although it can contain some private information to be filtered. – user140866 May 13 '16 at 7:22
  • ls -ldZ ~ ~/.ssh ~/.ssh/authorized_keys on server. – Jakuje May 13 '16 at 8:29
  • @Joel you should take a look at file /var/log/audit/audit.log. Also, update your answer with output of command from @Jakuje – cuongnv23 May 13 '16 at 9:49

Set LogLevel to DEBUG in sshd_config, and I think you'll find (in auth.log of course) a reason why you publick key is refused.

  • You don't even need to change the log level. A denied login is always logged with a reason, and usually that reason is enough to figure it out. – Gilles May 13 '16 at 21:38
up vote 0 down vote accepted

Looking at the log /var/log/secure showed that it was just downright refused. I'm somewhat new to centos since I'm mainly a debian kind of guy, so I was unaware of /var/log/secure

After checking this and doing a bit of searching, it turns out PermitRootLogin no needs to be PermitRootLogin without-password if you want to specifically use just keys for root login. That did the trick. Thanks everyone for contributing.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.