I had to take two extra permission steps on the machine i was sshing into to make it work due to this error: “SSH Error: Permission denied (publickey,gssapi-with-mic)” . Not sure if they’re relevant but here are the steps that did the trick.

The following two lines worked also worked on my Ubuntu 9.10 server also when added to the installed /etc/ssh/sshd_config file:

UsePAM yes
PasswordAuthentication no
ChallengeResponseAuthentication no

Note: The installed default is UsePAM yes and ChallengeResponseAuthentication no. Webmin added UsePAM yes to my file automatically because it was commented out.

Hence, only adding

PasswordAuthentication no

to sshd_config works on my server with RSA public-key authentication.

This is off topic, but since Webmin was mentioned it also added:

IgnoreUserKnownHosts No

to the sshd_config file as the installed default of yes was also commented out and the default for Webmin is no. I changed it back explictly to yes after I realized that this was causing logins to fail. The lesson is to always save a copy of the original config file and be careful when using tools like Webmin, etc. Editing config files directly is probably your best bet as well as uncommenting defaults first. This way you are certain of the config being actually used. Some Webmin modules save backups to config files and some do not. The ssh server module does not.

if you put the key on a USB drive and point to it with the -i modifier like this:

ssh -i /USBDRIVE/id_rsa USERNAME@SERVER

you dont have to rename the file. I have accidentally renamed the key.backup with cp and ended up with 2 copies of the key. or deleted them all with rm!!
The less possible copies of the key the better i feel. You can also take it with you like a real key. Of course just remove the -i pointer to test no-key no-login. or pull the USB…
ssh USERNAME@SERVER

Maybe a late reply, but I have now experienced the same thing. Now on Linux Mint 12. For me it seems that the key is cached automatically by ssh-agent when unlocked by the key ring (at least this is my suspicion). I tried to kill the ssh-agent process, but it had been defuncted on my session. Maybe it is because it is a child process of gnome-session. So I restarted my gnome session (Ctrl+Alt+Backspace) and now I got the expected permission denied error.

Attempting to generate RSA for SCP I had to go through about 3 guides before I finally made it work. Most guides are not clear about what exactly SSH looks for when authenticating.. which is the /.ssh/authorized_keys FILE (not folder). I guess I like it more when tutorials explain how something works, not just show me how to do it. But this tutorial was the most helpful one so far.

What does one have to do to get this to work from another machine where:

a) that machine is running Linux and uses ssh
b) that machine is running Unix and uses ssh
c) that machine is running Windows and uses Putty.exe
d) that machine is running MacOSX and uses
e) that tablet is running Android
d) that tablet is running Apple’s iOS

I have an account that uses sftp to copy files from a Windows server to a Linux server on a daily basis. The client uses RSA keys to authenticate. Then one day, the password for the linux account expired. Suddenly the sftp sessions failed. I could see the keys were accepted and authenticated, but the sftp session refused to start. I was surprised to see that behavior in sshd.

If I set either ChallengeResponseAuthentication and/or PasswordAuthentication to no in the sshd_config file, would that resolve this problem? It’s easy for me to extend the password expire time to something in the future, but at some point that future will become present and I’d be in this same situation again. And who knows if I’d remember the solution.

I have to keep ‘UsePAM yes’ in our sshd_config file, because we use PAM for other stuff in our system. Would just like confirmation that:

UsePAM yes
ChallengeResponseAuthentication no
PasswordAuthentication no

Thank you for your comment. I’m affraid that I do not know the answer to your question. I have however never had this problem, and I have always had password authentication set to no. If you get luck another reader knows the answer.

Nice!
It just works.
I like the
ssh -o PubkeyAuthentication=no user@server
to test restriction, as mentioned above.
Also mentioned above, the chmod on key files/directories is a good idea if not required. I’ve run into ssh not working until I did this (in the past), so I just do it out of habit.
I’m combining this with VNC to remote control Mac -> Mint 13.
Thanks!

BTW, unlike above, if I have to choose, I prefer just “how to” vs. lengthy, intervening explanation of what and why–though what and why at the end is welcome. This article was short, sweet, great!