SSH key problems

@A32:

Hi. I'm hoping someone might be able to shed some light on my situation.

Earlier today I decided it would be a good idea to change the keys I log into SSH with. It turns out it wasn't a great idea after all.

I used ssh-keygen and generated these keys:

sshhostrsa_key

sshhostdsa_key

Well, the second round of Debian ssh updates automatically regenerated the host keys, so you didn't need to delete it at all. The simplest way to get them back, assuming you haven't otherwise altered the sshd configuration, is to 'sudo dpkg –force-depends -P openssh-server ; sudo apt-get install openssh-server' - from lish. Obviously won't be able to login over ssh while doing that, etc, etc.

@A32:

Now, after fiddling around I can now login to my node through LISH but not through my SSH client. When I try, it just disconnects me.

denyhosts doesn't use iptables (by default). If you have a static IP that you want to prevent being blocked by denyhosts, pop it in /var/lib/denyhosts/allowed-hosts. I suspect the above plus this will let you login again.

Your ssh-keygen commands won't have created files of the right names (it would have created idrsa and iddsa) and you haven't created the ssh1 key either.

Try:

ssh-keygen -t rsa1 -f ssh_host_key -C '' -N ''
ssh-keygen -t rsa -f ssh_host_rsa_key -C '' -N ''
ssh-keygen -t dsa -f ssh_host_dsa_key -C '' -N ''
chmod 600 ssh_host*key
chmod 644 ssh_host*key.pub

The -C and -N options ensure no passwords or comments. There should NOT be a password on the host key otherwise sshd can't load them at boot time.

Now restart sshd on the server.

This won't solve the denyhosts option, but should get sshd running properly!

Thanks for all your help. I'm now able to login to my node through my SSH client.

However, I think I'm missing some knowledge at a very basic level.

I use Putty from Windows.

I used puttygen to generate a new public and private key.

I added the public key to the home/.ssh/authorized_keys2 file.

I changed the private key file in Putty to the one I just generated with puttygen.

Now after all your guys' suggestions and changing these things above, everything is back to normal (with a different password).

My (stupid) question is: How do the puttygen generated files and the ssh-keygen files relate to each other?

Is the puttygen key only for authentication and the ssh-keygen key for encrypting data communications between client/server?

Thanks again

ssh-keygen is used to generate public/private key pairs. There's no fundamental difference between a host key and a user key. I use ssh-keygen for all of my keys.

"puttygen" is merely the putty specific version of ssh-keygen.

Now SSH does two things for you; 1) encrypt traffic, 2) provide key based authentication. When you stick a public key into $HOME/.ssh/authorizedkeys (authorizedkeys2 is deprecated; don't use it any more) you are telling ssh that you'll allow key based authentication, rather than password authentication. But whether you use keys or passwords, ssh can still provide "on the wire" encryption.

Okay. I think I get it now.

So I can use ssh-keygen to generate a public and private key, add the public key to authorized_keys, download that private key to my computer, tell putty to use that private key.

-OR-

use puttygen to generate public and private keys, add the public key to authorized_keys, tell putty to use the private key puttygen generated. Right?

–------------

I've done both and I think this was the catalyst to the problems I had. I used ssh-keygen with a password. As you say you can't do that because then the key can't be opened. But generating the key through puttygen doesn't seem to have that "caveat".

Again thanks for all the help!

one question that has been bugging me about this thread: why were you messing with the host keys? in theory, once they're generated on the first startup, they shouldn't be touched. If you were doing this in response to the Debian openssh package maintainer's new found knowledge of cryptography, I was under the impression that the replacement package handled that for you.

What I said was the HOST keys can't have a password. These are the /etc/ssh/ssh_host*key files. You should(!) never need to change these, but because you did I told you how to generate new ones.

User keys can have a password.

HOST keys are public keys.

Things open to the public can't have passwords or that makes them sort of useless.

@jacko:

HOST keys are public keys.

Not quite. Like everything using this technology, there's a private key and a public key and these two are related mathematically. So you'll see /etc/sshhostkey and /etc/sshkeykey.pub. The "pub" version is the public key, the other one is the private key. Unlike normal user private keys, however, this private key should NOT have a password on it, otherwise the ssh daemon process can not load it up at boot time, and ssh will fail to run.