SSH keys don't do anything

Pass the -v option to your ssh command line and examine the debug output. Is ssh picking up on your key? If it is, is it then accepting the key?

Also make sure your .ssh/authorized_keys file is correct: keytype followed by key, no stray newlines in the key, …

Permissions should be 600 not 644. Also, I suppose you did check sshd_config to see if PubkeyAuthentication is set to yes?

Using a passphrase for the key is highly recommended, so you might wish to add the key to ssh-agent on your local computer.

Things to man and google for more info:

sshd_config

ssh_config

ssh-agent

I don't know if this will work for you, but the file name for the authorized keys on my servers is ~/.ssh/authorized_keys2 (where "~" is the user's home directory). Note the number 2 at the end of the file name.

I'm also using OpenSSH.

Note that authorizedkeys2 (and knownhosts2) were deprecated with the release of OpenSSH 3.0 (back in late 2001).

Originally they were introduced to differentiate keys for SSHv2 versus v1.x, but I'd be pretty surprised if any distribution currently in use at Linode needs them. (Actually I'm even mildly surprised OpenSSH is still reading them at this point)

– David

Thanks for all the advice!

I just had to reboot my local FreeBSD box.

All is well…

An added note:

I tried to setup my local box to use rsync via CRON with my private key that has a pass phrase. It's not worth the hassle unless you think someone may steal your computer. You have to use a script to get SSH to use the SSH agent every time you boot up your local box, and you have to supply the pass phrase at boot up as well.

See this method: http://meinit.nl/using-rsync-from-cron- … passphrase">http://meinit.nl/using-rsync-from-cron-with-ssh-keys-that-have-a-passphrase

I punted and regenerated a private key without a pass phrase - actually you can keep the current key and remove the pass phrase with: 'ssh-keygen -p', enter the old passphrase, and then hit CR each time for the new one.

Also Filezilla (I'm using version 3.5.2) isn't yet able to work with private keys that have a pass phrase.

The benefit of using keys for SSH is that you can then disable access to the server using a password and not have to worry anymore about brute force attacks. Just edit /etc/ssh/sshd_config and add "PasswordAuthentication no".

Another note:

I use PCBSD and Ubuntu with KDE on different machines and setup the key files on both. I use KDE's file manager, Dolphin, which supports SFTP.

Now I don't need Filezilla anymore. I can use my file manager transparently and even launch a text editor or other program by double clicking any file, do my editing, and save it as usual.

Hmm, it's really odd that you had to reboot your LOCAL box. By the way, if anyone else is wondering…

@Torva:

putting the key into the file /root/.ssh/authorizedkeys as well as the ordinary user /jeff/.ssh/authorizedkeys. I have the same key file on my local machine.
The file on the server should be named authorizedkeys, and it should contain your public key (one line). The file on your local machine should be named idrsa, and it should contain your private key (many lines). Having the same key in both places doesn't do anything, because public key cryptography requires a pair of keys. Public on the server, private on your local machine.

@Azathoth:

Permissions should be 600 not 644.
The authorizedkeys file can be either 644 or 600. After all, it only contains your public key, and public keys are safe to disclose to others. The idrsa file on your local machine should be 600, because it contains your private key. SSH will refuse to use a private key with any other permission.

I also wouldn't have thought rebooting my local machine would be required, and in fact it may have been coincidence. I actually have no idea why the next day it just started working.

Correct me if I'm wrong but don't you also need the public key to be in /authorized_keys on your local machine as well as the server?

@Torva:

Correct me if I'm wrong but don't you also need the public key to be in /authorized_keys on your local machine as well as the server?

Only if you want to be able to use that public key when connecting to your local machine.