4

I've been able to set up SSH authentication keys on my ubuntu, fedora core and mac systems, however, I'm not able to get SSH keys to work properly with redhat enterprise linux 5 (RHEL5). I've tried created the keys with 2048 bit encryption, but nothing seems to work. Here's the debug output that i get when i try to connect via my mac osx leopard (10.5.7)

I've checked permissions and i'm not able to figure it out... thanks

UPDATE: I've doubled checked my permissions, and they are 0700 for .ssh, and 0600 for .ssh/authorized_keys

royrico@mac ~ $ ssh -vv linuxbox
OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to linuxbox [192.168.2.3] port 22.
debug1: Connection established.
debug1: identity file /Users/royrico/.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /Users/royrico/.ssh/id_rsa type 1
debug1: identity file /Users/royrico/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 138/256
debug2: bits set: 493/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'linuxbox' is known and matches the RSA host key.
debug1: Found key in /Users/royrico/.ssh/known_hosts:1
debug2: bits set: 504/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/royrico/.ssh/identity (0x0)
debug2: key: /Users/royrico/.ssh/id_rsa (0x107ea0)
debug2: key: /Users/royrico/.ssh/id_dsa (0x0)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/royrico/.ssh/identity
debug1: Offering public key: /Users/royrico/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /Users/royrico/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
royrico@linuxbox's password:
Roy Rico
  • 602
  • 1
  • 7
  • 20
  • 1
    What do the logs on the server-side look like? – womble May 20 '09 at 03:18
  • 2
    And what are the permissions on the parent directory (i.e. /home/royrico) on the server? If they're too permissive you'll see this error too. – GodEater May 20 '09 at 11:08
  • Thanks Bryan, that was the issue... could you write this as an answer so i can give u the proper credit? – Roy Rico May 20 '09 at 18:44

5 Answers5

3

Check the permissions on your ~/.ssh/authorized_keys file. They should be 0600.

% chmod 0700 .ssh
% chmod 0600 .ssh/authorized_keys

Is my standard pattern

Update: Check that your home directory is owned by you alone, ensure that your primary group does not have write access to your home directory. There is an attach vector where someone in your primary group could move your .ssh directory away if they have write permission to the root of your $HOME

Dave Cheney
  • 18,307
  • 7
  • 48
  • 56
  • i've already checked these and this doesn't fix the issue. :( like i said, i'm stumped... – Roy Rico May 20 '09 at 01:46
  • 1
    update: updating comment to reflect answer update. It was infact the permissions on the home (~) directory, and not just the ~/.ssh directory. Bryan Childs deserves credit as well, he's the first to post that idea, but didn't put it in answer bucket :( – Roy Rico May 27 '09 at 17:57
0
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'

These messages look pretty important. It appears you have the wrong type of key in your identity file.

Zoredache
  • 128,755
  • 40
  • 271
  • 413
  • i don't have a ~/.ssh/identity file, could the error be because i dont? I haven't needed it for other machines. – Roy Rico May 20 '09 at 00:10
  • 5
    Nah, that's just the v1 key parser getting it's knickers in a twist over nothing. It's harmless. – womble May 20 '09 at 03:19
  • @womble: Thank you, this comment just saved me hours of wild hunting. – aviv Dec 01 '15 at 21:54
0

When you generate a key pair, you generally have a public key named id_rsa.pub or id_dsa.pub. The contents of this file is what gets pasted into the authorized_keys file on the remote server. Double-check to make sure you added the public half of the key pair to authorized_keys.

The private key is generally named the same as your public key but without the .pub extension e.g. id_rsa or id_dsa. Perhaps your local system can't find the correct private key to use? Try ssh -i /path/to/private/key linuxbox.

Charles Hepner
  • 425
  • 1
  • 3
  • 10
  • i tried that, same issue, i get the same output as i do when posted this issue when i do `ssh -i .ssh/id_rsa linuxbox` as i do `ssh linuxbox`. Thanks for your time. – Roy Rico May 20 '09 at 02:31
0

It should not require more than (example)

ssh-keygen -t rsa 
ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.tld
ssh-copy-id -i ~/.ssh/id_rsa.pub another@host2.tld
ssh-copy-id -i ~/.ssh/id_rsa.pub etc@etc.tld
raspi
  • 811
  • 1
  • 9
  • 21
0

hum quick question how is your selinux settings ? what does getenforce says ? if you haven't desactived selinux, maybe you can take a look at the /var/log/audit.log and use audit2why: http://linux.die.net/man/8/audit2why

or you can as well desactive selinux, editing /etc/sysconfig/selinux

hope this helps

Xinity
  • 184
  • 1
  • 4