Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I just uploaded my public key to a server, ensured permissions are right, and when i try to log it simply refuses it.

after enabling loglevel DEBUG in sshd_config i get:

Nov 22 06:53:36 host-1 sshd[8612]: debug1: Forked child 8617.
Nov 22 06:53:36 host-1 sshd[8617]: Set /proc/self/oom_score_adj to 0
Nov 22 06:53:36 host-1 sshd[8617]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 22 06:53:36 host-1 sshd[8617]: debug1: inetd sockets after dupping: 3, 3
Nov 22 06:53:36 host-1 sshd[8617]: Connection from some_ip port 50466
Nov 22 06:53:36 host-1 sshd[8617]: debug1: HPN Disabled: 0, HPN Buffer Size: 87380
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Client protocol version 2.0; client software version OpenSSH_6.0p1 Debian-3
Nov 22 06:53:36 host-1 sshd[8617]: SSH: Server;Ltype: Version;Remote: some_ip-50466;Protocol: 2.0;Client: OpenSSH_6.0p1 Debian-3
Nov 22 06:53:36 host-1 sshd[8617]: debug1: match: OpenSSH_6.0p1 Debian-3 pat OpenSSH*
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Remote is NON-HPN aware
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Enabling compatibility mode for protocol 2.0
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Local version string SSH-2.0-OpenSSH_5.8p1-hpn13v10
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Config token is loglevel
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Config token is passwordauthentication
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Config token is permitemptypasswords
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Config token is usepam
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Config token is subsystem
Nov 22 06:53:36 host-1 sshd[8617]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Nov 22 06:53:36 host-1 sshd[8617]: debug1: trying public key file /home/xxx/.ssh/authorized_keys
Nov 22 06:53:36 host-1 sshd[8617]: debug1: fd 4 clearing O_NONBLOCK
Nov 22 06:53:36 host-1 sshd[8617]: debug1: restore_uid: 0/0
Nov 22 06:53:36 host-1 sshd[8617]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Nov 22 06:53:36 host-1 sshd[8617]: debug1: trying public key file /home/xxx/.ssh/authorized_keys2
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Could not open authorized keys '/home/xxx/.ssh/authorized_keys2': No such file or directory
Nov 22 06:53:36 host-1 sshd[8617]: debug1: restore_uid: 0/0
Nov 22 06:53:36 host-1 sshd[8617]: Failed publickey for xxx from some_ip port 50466 ssh2
Nov 22 06:53:36 host-1 sshd[8617]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Nov 22 06:53:36 host-1 sshd[8617]: debug1: trying public key file /home/xxx/.ssh/authorized_keys
Nov 22 06:53:36 host-1 sshd[8617]: debug1: fd 4 clearing O_NONBLOCK
Nov 22 06:53:36 host-1 sshd[8617]: debug1: restore_uid: 0/0
Nov 22 06:53:36 host-1 sshd[8617]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Nov 22 06:53:36 host-1 sshd[8617]: debug1: trying public key file /home/xxx/.ssh/authorized_keys2
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Could not open authorized keys '/home/xxx/.ssh/authorized_keys2': No such file or directory
Nov 22 06:53:36 host-1 sshd[8617]: debug1: restore_uid: 0/0
Nov 22 06:53:36 host-1 sshd[8617]: Failed publickey for xxx from some_ip port 50466 ssh2
Nov 22 06:53:36 host-1 sshd[8617]: debug1: do_cleanup

it keep trying authorized_keys2 (which i though were deprecated everywhere) but it does open authorized_keys at some time (the correct file with my keys) and then says absolutely nothing more about it and goes back to authorized_keys2

what's wrong here?

I do have in my sshd_config:

PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

and there's no authorized_keys2 string in that file anywhere. And yes, sshd restarted before tests.

I guess i can just use authorized_keys2 but want to understand what's happening here. Any clues?


edit: ssh -v host

client$ ssh -v host
OpenSSH_6.0p1 Debian-3, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to host [someip] port 22.
debug1: Connection established.
debug1: identity file /home/xxx/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/xxx/.ssh/id_rsa-cert type -1
debug1: identity file /home/xxx/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: identity file /home/xxx/.ssh/id_dsa-cert type -1
debug1: identity file /home/xxx/.ssh/id_ecdsa type -1
debug1: identity file /home/xxx/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1-hpn13v10
debug1: match: OpenSSH_5.8p1-hpn13v10 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA xx:xx...
debug1: Host 'host' is known and matches the ECDSA host key.
debug1: Found key in /home/xxx/.ssh/known_hosts:11
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /home/xxx/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering RSA public key: /home/xxx/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/xxx/.ssh/id_ecdsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
xxx@host's password: 
share|improve this question
1  
Can you supply the output of ssh -v xxx@host-1 too? authorized_keys2 is deprecated, but it's still checked in sshd (historical reasons), the checking will be removed sometime in the future. –  ott-- Nov 22 '12 at 7:55
    
@ott-- added ssh -v host –  gcb Nov 22 '12 at 8:24

2 Answers 2

up vote 4 down vote accepted

It looks like it's falling back to authorized_keys2 for compatibility reasons when it fails to find a valid authorized_keys file. Check that your authorized_keys file is correctly formed.

share|improve this answer
    
it has only one key. it's practically cat id_rsa.pub > authorized_keys... don't know what can go wrong. also, it checks for authorized_keys2 twice, before caring about authorized_keys and then go right back to checking authorized_keys2. it's weird. –  gcb Nov 22 '12 at 8:18
1  
@gcb: Your log snippet only shows it checking authorised_keys the falling back to the deprecated versions. –  Iain Nov 22 '12 at 8:20
    
@lain you are correct... i will blame the lack of sleep. i read a 2 on the first log line that file was mentioned. Ok, so it's less weird now. Also, i recreate the keys and more carefully move pub to the server, nothing. any way i can parse that file? or make sshd log more verbose? –  gcb Nov 22 '12 at 8:26
    
ok, i think it parses OK ssh-keygen -l -f ~/.ssh/authorized_keys does show the only key there as RSA –  gcb Nov 22 '12 at 8:32
    
it was malformed. the above command was reporting a 5k instead a 2k RSA key size... somehow i managed to screw up a simple cat > twice –  gcb Nov 22 '12 at 8:43

Can the user with uid=1000 access the .ssh/authorized_keys directory? What OS are you running? Some distributions with SELinux enabled can disallow sshd to read from .ssh/authorized_keys. You can restore that using: restorecon -R -V /home/xxx/.ssh/

share|improve this answer
    
standard gentoo from linode, no selinux as far as i can tell. permissions are ok. home dir, .ssh, and auth file are only readable by user xxx[uid=1000] –  gcb Nov 22 '12 at 7:23

Your Answer

 
discard

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.