What does this ssh error mean?

Question

This is my last resort. I've been trying to figure out the problem here for hours.

Here's the deal: I have copied my private key from machine #1 onto machine #2. Machine #1 is able to connect via ssh to a server with my public key just fine, but machine #2 gives the following output, when trying to connect to the server:

$ ssh -vvv -i /home/kevin/.ssh/kev_rsa [email protected] -p 22312
OpenSSH_5.3p1 Debian-3ubuntu6, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.244 [192.168.1.244] port 22312.
debug1: Connection established.
debug3: Not a RSA1 key file /home/kevin/.ssh/kev_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace

...


Permission denied (publickey).

There is obviously more debug output that I have omitted, and I can provide upon request. I am convinced however that it doesn't like my private key file.

I also had a suspicion that it has to do with how I copied it from machine #1 to machine #2. I copy/pasted the text from the private key onto a flash drive. This might be the problem, however, when I duplicated this method on another working private key file, and did a diff on the original, to the copy/pasted one, they are identical.

I've been struggling with this. If I could just get a little more information on why it doesn't like my key, I could fix it I'm sure. Anyone have any ideas on this? Is there some meta-data somewhere that tells ssh that a file is in fact an RSA key?

Solution

In my experience the two most common key based auth errors are

1. Inappropriately broad permissions on the $HOME/.ssh directory
2. An error in copying the public key to the remote system

File Permissions

OpenSSH does a lot in an attempt to protect you from yourself. The most user impacting way this happens is by enforcing hard restrictions on who has access to your local ssh folder. You really only want you, and only you, to access the directory. Well, and anyone with uid=0, but there's no good way around that. So what you need to do is simply change your permissions: chmod -R go-rwx ~/.ssh This will remove read, write, and execute rights to any files underneath the .ssh directory from all users except the owner, i.e. you.

Authorized Keys Issues

The file containing your public key, typically $HOME/.ssh/authorized_keys has to fit a very specific form for SSH to understand how to accept the private key. Each key must consist of, at least, 2 fields

1. Type of key used (RSA, DSA, RSA1, etc)
2. Key

Each key, along with all of its options and component parts, must be listed one per line in this file. Since the keys tend to be very long they will often wrap and appear as two lines on your terminal. This will sometimes cause havoc when attempting to copy/paste, since sometimes one or more newlines will get inserted wherever the key wraps on your screen. Fixing this problem can be a bit trickier for a shell beginner.

Try running
wc -l ~/.ssh/authorized_keys
This will print out the number of lines in the file. Compare that number against the number of keys you expect to be in the file. If you will only be accepting this one key, you can also just make a copy of the public key file, since it is the same format as your authorized keys file. Something like
scp -p ~/.ssh/kev_rsa.pub remotehost:~/.ssh/authorized_keys
or, if you have your public key on the same system you can do
cat ~/.ssh/kev_rsa.pub >> ~/.ssh/authorized_keys

Additionally, look in the log file on the remote host and see if any errors are being reported there. The files will most likely be either /var/log/secure.log or /var/log/auth.

Comments

[womble]

And what does /var/log/auth.log on the server say?

[Dru]

For clarification, the public key from machine 1 connects to the server. The private key from machine 1, running on machine 2 will not connect to the server?

[kevin]

I have the same key pair on both machines, and the public key is on the server. I copy pasted the keys from client machine 1, which has no problems connecting to the server, here to my home computer (machine 2) which is having this authentication problem.

[kevin]

@womble, Unfortunately, I can't access the server, if I can get this figured out I will be able to ssh right in.. Ahh, irony... ;)

[kevin]

Hi @Stobor, I considered that too actually, and checked the private key file in vi using the :set invlist command, and there are no additional or superfluous $ or other invisible characters.

[Stobor]

@womble: Dru and Kevin explained the situation in the comments above. I'm assuming client machine 1 is at work, and is not accessible from home where client machine 2 is.

[kevin]

It's a server that has privileged access. I gave my public key to this person. Like I said, it works on machine 1. I'm convinced there is something wrong with my home machine, that is preventing ssh from recognizing the private key as a private key, or some other such thing, given that it works on a daily basis from the other machine at work

[kevin]

@Stobor is right. Thanks for paying attention, despite my poor communication.. :)

[Stobor]

@kevin: ssh-keygen -y -f kev_rsa should either print out the public key ("ssh-rsa AAAAB3N....") or fail with load error, depending on whether the key is valid. If the key is valid, then the problem is on the server end.

[kevin]

@Stobor, I did that earlier too. It prints out the public key as expected. The reason I'm perplexed, and leaning toward a problem here on this home machine, is because it works perfectly at work. by "it works perfectly" i mean sshing onto the server.

[Stobor]

It could still be a problem on the home machine, but it probably isn't related to any error in the keyfile...

[Scott Pack]

@kevin It is possible to only permit that key to be used from certain addresses, and if this is a "privileged system" then your key may only be authorized from work. Have you talked to the systems administrator about your access issues?

[Admin]

So you are trying to ssh from your client , on the "server" , but you are using port 22312? I guess that you have changed the config file on the server and instead of the default port 22 you have put the server to listen to port 22312. Have you also instruct your server firewall to leave tcp/udp packets for port 22312 to pass through ?

[kevin]

I should have been more clear. There are two clients, one server. I can't access the server, or the other client machine. I will be able to access the server as soon as this damn key will authenticate ;)

[kevin]

I was under the impression it ignores those, that they are simply comments to help you identify them when viewing authorized_keys. And anyway, again, I just copy/pasted the keys. So they are identical. I seriously doubt that it checks your hostname. If it did, I could change that easily. What the hell, I'll try that anyway...

[kevin]

Hi, Thank you for your effort here. I do appreciate that. It's definitely not a permissions problem. I've verified permissions are correct. (I should have added that as a caveat). Also, although I cannot access the original keys right now, I've duplicated the process that I used to copy the key I'm using. I even did an md5sum to verify that the files are identical. Make sense?

[kevin]

And again, I cannot access the server. Kind of the whole problem here... ;)

[mlp]

@Scott: make a copy of the private key file should be public key (as shown in your examples)