Trouble keying my OpenSSH connection

I find the easiest method is to generate the key on your server then download it. Keep in mind that PuTTY can't use OpenSSH key files directly, you need to convert them. Use PUTTYgen, found on the main downloads page: http://www.chiark.greenend.org.uk/~sgta … nload.html">http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

With PuTTYgen you want to then go to Conversions | Import Key. Browse for and select your private key that you downloaded (usually named id_rsa). If your key is encrypted (which it should be) enter your password to decrypt it. Now, you can go to File | Save private key, to save the file in PuTTY's format (.ppk).

Once that is done, from PuTTY you go to Connection | SSH | Auth and browse for and select the .ppk file you just saved under "Private key for authentication".

Since you've been trying a bunch of things I'd highly recommend cleaning up any changes you've made so you don't inadvertently keep bad settings.

• Delete the contents of ~/.ssh (if you aren't using your keys for anything else, which I don't think you are)

• Restore sshd_config to whatever configuration you had prior to trying to setup key authentication (set PubkeyAuthentication to yes of course)

• Use a brand new session in PuTTY

Keep in mind that if your key is encrypted and key authentication is working, PuTTY will still prompt you for a password, since it has to be able to decrypt the key. The prompt will be in the session window and will look like:

Using username "yourusename".
Authenticating with public key "keycomment"
Passphrase for key "keycomment":

Good luck.

Probably the most annoying thing about OpenSSH is that it doesn't understand file permissions. Make sure .ssh is 700 and authorized_keys is 644. Most distros default to 664, which is just as secure, but sshd is too stupid to know that.

664 is not secure in the general case. It allows group writeable. It's only because the file is in a 700 directory that you think it is secure.

If you generate keys with ssh-keygen then it will have the right permissions. If you generate keys some other way then you'd better understand what you're doing (file permisions, how umask affects them etc).

ssh isn't being stupid; it's being conservative. This is a good design principle.

I don't like when software enforces "good design" when it has no value.

To paraphrase Practical Cryptography, we already have enough insecure and efficient software. OpenSSH cannot rely on the assumption that a group-writable file is secure from tampering simply because it happens to be that way sometimes, and it will refuse to do so.

We don't mess around with security.

Thanks for the help. My main question is what do I have to do on the server to get it to work after I have generated the keys? I know how to use PuttyGen and all, as I've been making .ppk files that keep getting refused.

What do I have to edit in my sshdconfig file to make the key get recognized by openssh? Do I have to put the public key in authorizedkeys? (which I have to make first in /home/userwhoiskeying/.ssh/ or do I have to just let ssh-keygen run and then it will work?

ssh-keygen generates the files to root/.ssh/ and I've tried making an authorizedkeys in there and putting the public key in that authorizedkeys and then pointing the configuration to that. I've also tried editing the line that says "host keys" in my sshdconfig to /root/.ssh/idrsa.pub. when I restart ssh, it says cannot load key. I've tried everything that I can think of.

If you're trying to login as root (bad idea! Login as a normal user then use sudo or su) then ensure you have PermitRootLogin set, otherwise sshd will deny direct root logins.

Also, are ppk files openssh compatible? I'm not sure they're in the right format… Look at http://unixwiz.net/techtips/putty-openssh.html#keypair for info on how to use puttygen to create an openssh compatible public key

@sweh:

If you're trying to login as root (bad idea! Login as a normal user then use sudo or su) then ensure you have PermitRootLogin set, otherwise sshd will deny direct root logins.

Also, are ppk files openssh compatible? I'm not sure they're in the right format… Look at http://unixwiz.net/techtips/putty-openssh.html#keypair for info on how to use puttygen to create an openssh compatible public key

I've tried that three times now, before I even posted here, and once again it says "Server refused our key."

I even completely removed SSH and reinstalled it so that I could start over.

What do I have to change in the sshd_config file to get this to work properly?

I'm extremely uncomfortable leaving my server open to password authentication.

@Captain Briney:

@sweh:

If you're trying to login as root (bad idea! Login as a normal user then use sudo or su) then ensure you have PermitRootLogin set, otherwise sshd will deny direct root logins.

Also, are ppk files openssh compatible? I'm not sure they're in the right format… Look at http://unixwiz.net/techtips/putty-openssh.html#keypair for info on how to use puttygen to create an openssh compatible public key

I've tried that three times now, before I even posted here, and once again it says "Server refused our key."

I even completely removed SSH and reinstalled it so that I could start over.

What do I have to change in the sshd_config file to get this to work properly?

I'm extremely uncomfortable leaving my server open to password authentication.

You need this line to enable public key authentication.

PubkeyAuthentication yes

This goes in sshdconfig not the similarly named sshconfig. The sshd daemon has to be restarted for the changes to take effect of course. Existing sessions are not closed if the daemon is restarted.

You have to create the authorizedkeys file under ~/.ssh/authorizedkeys. The file is simply the concatentation of all the public keys you wish to use to authenticate as that user. Therefore, if you're only going to authenticate with one key, idrsa.pub (your public key) and authorizedkeys should be identical.

To check this run

diff ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys

If there is no output then they're identical, which is what you want. If you get output then something's wrong.

EDIT:

By the way, a good way to test if just your server side stuff is setup properly is to simply do:

ssh localhost

This will attempt to establish an SSH session with the local machine as the current user, using the key in ~/.ssh/idrsa. If that works fine (you should get a new "Last login" message and the issue/motd banner should be printed again), then your problem is on the client end. If it's unable to connect, or instead prompts you for a password (not your key password which will trigger a prompt of "Enter passphrase for key '/home/currentuser/.ssh/idrsa':") then something is wrong with the server setup.

@zengei:

@Captain Briney:

@sweh:

If you're trying to login as root (bad idea! Login as a normal user then use sudo or su) then ensure you have PermitRootLogin set, otherwise sshd will deny direct root logins.

Also, are ppk files openssh compatible? I'm not sure they're in the right format… Look at http://unixwiz.net/techtips/putty-openssh.html#keypair for info on how to use puttygen to create an openssh compatible public key

I've tried that three times now, before I even posted here, and once again it says "Server refused our key."

I even completely removed SSH and reinstalled it so that I could start over.

What do I have to change in the sshd_config file to get this to work properly?

I'm extremely uncomfortable leaving my server open to password authentication.

You need this line to enable public key authentication.

PubkeyAuthentication yes

This goes in sshdconfig not the similarly named sshconfig. The sshd daemon has to be restarted for the changes to take effect of course. Existing sessions are not closed if the daemon is restarted.

You have to create the authorizedkeys file under ~/.ssh/authorizedkeys. The file is simply the concatentation of all the public keys you wish to use to authenticate as that user. Therefore, if you're only going to authenticate with one key, idrsa.pub (your public key) and authorizedkeys should be identical.

To check this run

diff ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys

If there is no output then they're identical, which is what you want. If you get output then something's wrong.

EDIT:

By the way, a good way to test if just your server side stuff is setup properly is to simply do:

ssh localhost

This will attempt to establish an SSH session with the local machine as the current user, using the key in ~/.ssh/idrsa. If that works fine (you should get a new "Last login" message and the issue/motd banner should be printed again), then your problem is on the client end. If it's unable to connect, or instead prompts you for a password (not your key password which will trigger a prompt of "Enter passphrase for key '/home/currentuser/.ssh/idrsa':") then something is wrong with the server setup.

Thanks for all the great help.

None of this works, and I have already tried all of this before. I think I will be fine without key authentication for the time being. I've given up at this point, heh. Thanks again.

Don't forget, details about login failures are logged to /var/log/secure

@Captain Briney:

I've tried that three times now, before I even posted here, and once again it says "Server refused our key."

I even completely removed SSH and reinstalled it so that I could start over.

What do I have to change in the sshd_config file to get this to work properly?

I'm extremely uncomfortable leaving my server open to password authentication.
You're not making it easy for us, by not providing any details other than "it doesn't work".

First thing to do is get this running as a non-root user. So, for example, I'd like to see the output of

grep -v '^#' /etc/ssh/sshd_config | grep -v '^/r>

ls -ld / /home /home/user /home/user/.ssh /home/user/.ssh/authorized_keys

(where "user" is your username; assuming the home directory is /home/user)

cat ~/.ssh/authorized_keys

On the server, as root, "/usr/sbin/sshd -p 2222 -d"

On the client, "ssh -v -p 2222 -i /path/to/private/key user@server"

(and show the output of both).

Every time I've had to fix peoples ssh issues it's either been permission problems or corrupted public key file, or the user wasn't actually presenting the correct private key.