Home / server / Questions / 299051
In Process
kevin
Asked: 2011-08-09 16:26:07 +0800 CST

What does this ssh error mean?

  • 772

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?

ssh rsa keys private-key

4 Answers

  1. 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.

    • 7

  2. 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.

    • 0

  3. 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"?

    • 0

  4. Try comparing the ssh config files between the two servers.

    ie. something like cat /etc/sshd_config

    • -3