[Bug 2617] New: sign_and_send_pubkey: no separate private key for certificate

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2617

            Bug ID: 2617
           Summary: sign_and_send_pubkey: no separate private key for
                    certificate
           Product: Portable OpenSSH
           Version: 7.3p1
          Hardware: 68k
                OS: Mac OS X
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: pllewis72 at gmail.com

This worked back in openssh 6.  I'd just recently updated to OSX 10.12
and it stopped right after.  Openssh 7.2+ seems to be a point in which
I know it has changed.  I have since tested this on Ubuntu 16.04 with
openssh 7.2 with same results, so it's not a platform issue.  I also
updated ssh through homebrew on the mac to 7.3p1.  

First look on bugzilla, I thought it was related to the 2550 bug
(https://bugzilla.mindrot.org/show_bug.cgi?id=2550), but that was fixed
in 7.3p1.

The process using ssh certificate authentication through an SSH proxy
host.  The private key is in the downloaded certificate.  Openssh is
now looking for a separate ssh private key file.

Via 7.3 failure:
ssh -vvv -o 'ProxyCommand ssh -i ~/.ssh/bastion_key
my.name@<BASTIONHOST> -W %h:%p' ec2-user@<EC2HOST> -i
~/.ssh/bastion_key
OpenSSH_7.3p1, LibreSSL 2.4.2
debug1: Reading configuration data /Users/user/.ssh/config
debug1: /Users/user/.ssh/config line 27: Applying options for 10.*
debug1: Reading configuration data /usr/local/etc/ssh/ssh_config
debug1: Executing proxy command: exec ssh -i ~/.ssh/bastion_key
my.name@<BASTIONHOST> -W <EC2HOST>:22
debug1: permanently_drop_suid: ######
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/bastion_key type -1
debug1: identity file /Users/user/.ssh/bastion_key-cert type 5
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.3
no such identity: /Users/user/.ssh/bastion_key-cert: No such file or
directory
Permission denied (publickey).
ssh_exchange_identification: Connection closed by remote host

When I check out the bastion file, I get the following:
$ ls -l ~/.ssh/bastion_key*
-rw------- 1 user group 1675 Sep 26 14:09 /Users/user/.ssh/bastion_key
-rw-r--r-- 1 user group 1539 Sep 26 14:09
/Users/user/.ssh/bastion_key-cert.pub


Docker container with OpenSSH 6.6 works(docker is why its all as root):
[root at 18be76b35451 ~]# ssh -vvv -o 'ProxyCommand ssh -i
~/.ssh/bastion_key my.name@<BASTIONHOST> -W %h:%p' ec2-user@<EC2HOST>
-i ~/.ssh/bastion_key
OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Executing proxy command: exec ssh -i ~/.ssh/bastion_key
my.name@<BASTIONHOST> -W <EC2HOST>:22
debug1: permanently_set_uid: 0/0
debug1: permanently_drop_suid: 0
debug3: Incorrect RSA1 identifier
debug3: Could not load "/root/.ssh/bastion_key" as a RSA1 public key
debug1: identity file /root/.ssh/bastion_key type -1
debug1: ssh_rsa_verify: signature correct
debug1: identity file /root/.ssh/bastion_key-cert type 5
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 5 setting O_NONBLOCK
debug2: fd 4 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "<EC2HOST>" from file
"/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file
/root/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
....

[root at 18be76b35451 ~]# ls -l ~/.ssh/bastion_key*
-rw------- 1 root root 1679 Sep 26 18:25 /root/.ssh/bastion_key
-rw-r--r-- 1 root root 1539 Sep 26 18:25
/root/.ssh/bastion_key-cert.pub

Let me know if more logs are needed.  I can do more debugging also if
this isn't the right data.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.