Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 user@ -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 [] 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?

share|improve this question
And what does /var/log/auth.log on the server say? – womble Aug 9 '11 at 0:33
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? – Dru Aug 9 '11 at 0:47
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 Aug 9 '11 at 0:54
@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 Aug 9 '11 at 1:16
What are the operating systems on the two client machines? Could the transfer of the private key have munged the line-endings or introduced text (possibly blank lines or spaces) before the opening line? – Stobor Aug 9 '11 at 1:29

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/ remotehost:~/.ssh/authorized_keys
or, if you have your public key on the same system you can do
cat ~/.ssh/ >> ~/.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.

share|improve this answer
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 Aug 9 '11 at 1:23
And again, I cannot access the server. Kind of the whole problem here... ;) – kevin Aug 9 '11 at 1:24
@Scott: make a copy of the private key file should be public key (as shown in your examples) – mlp Aug 9 '11 at 2:52

Although, you will likely have to generate a new key pair for machine 2 to connect to the server. Often the public key will list the user and machine name of those that generated them. This should be apparent in your authorized_keys file on the server.

share|improve this answer
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 Aug 9 '11 at 1:12

The debug messages you give mean that a private key file is read with the assumption that it is actually a public key/authorized hosts file. This may not be a fatal error (I get such messages even for working connections). Does it say anything about "Offering" or "we sent"?

share|improve this answer

Try comparing the ssh config files between the two servers.

ie. something like cat /etc/sshd_config

share|improve this answer
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 Aug 9 '11 at 0:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.