9

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@192.168.1.244 -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?

Skyhawk
  • 14,149
  • 3
  • 52
  • 95
kevin
  • 91
  • 1
  • 1
  • 3
  • And what does `/var/log/auth.log` on the server say? – womble Aug 09 '11 at 00: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 09 '11 at 00: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 09 '11 at 00: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 09 '11 at 01: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 09 '11 at 01:29
  • Also, if you're basing your assumption that it doesn't like the key based on the key_read errors logged above, be aware that they are logged even for successful logins. – Stobor Aug 09 '11 at 01:35
  • 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. – kevin Aug 09 '11 at 01:36
  • @kevin: If you can't get onto the server, how did you get your key in there? Enlist the services of someone who *can* get onto the server to look at the logs. – womble Aug 09 '11 at 01:41
  • @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. – Stobor Aug 09 '11 at 01:44
  • 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 Aug 09 '11 at 01:45
  • @Stobor is right. Thanks for paying attention, despite my poor communication.. :) – kevin Aug 09 '11 at 01:46
  • @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. – Stobor Aug 09 '11 at 01:46
  • @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. – kevin Aug 09 '11 at 01:53
  • It could still be a problem on the home machine, but it probably isn't related to any error in the keyfile... – Stobor Aug 09 '11 at 01:55
  • @kevin: So get the person with privileged access to check the server logs. Also, pertinent information should be edited into the question, not left in (voluminous) comments. – womble Aug 09 '11 at 02:00
  • @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? – Scott Pack Aug 09 '11 at 14:21
  • 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 ? –  Jun 04 '13 at 22:26

4 Answers4

7

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.

Scott Pack
  • 14,717
  • 10
  • 51
  • 83
  • 1
    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 09 '11 at 01:23
  • 1
    And again, I cannot access the server. Kind of the whole problem here... ;) – kevin Aug 09 '11 at 01:24
  • @Scott: `make a copy of the private key file` should be **public key** (as shown in your examples) – mlp Aug 09 '11 at 02:52
0

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.

Dru
  • 105
  • 2
  • 6
  • 2
    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 09 '11 at 01:12
0

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

Ansgar Esztermann
  • 291
  • 2
  • 3
-3

Try comparing the ssh config files between the two servers.

ie. something like cat /etc/sshd_config

ae.
  • 231
  • 1
  • 7
  • 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 09 '11 at 00:42