thr3ads.net - openssh unix dev - Client-side public key causing mess [Apr 2016]

If this information is useful, please help other people find it:
Share via:

Elouan Keryell-Even

2016-Apr-19 12:04 UTC

Client-side public key causing mess

Hello,



I have a client machine and a server machine. I generated a pair of
private-public rsa keys using ssh-keygen.



On the client-machine, I uploaded my private key onto ~/.ssh/id_rsa

On the server machine, I appended the content of the public key to
.ssh/authorized_keys



I can successfully connect from the client to the server with that config.



However, on the client-side, if I add a ~/.ssh/id_rsa.pub public key file
that doesn?t match  the private key file ~/.ssh/id_rsa, it will fail with
?Permission denied (publickey).?



Error on the server-side (sshd logs):

error: RSA_public_decrypt failed:
error:0407006A:lib(4):func(112):reason(106)





# openssl errstr 0407006A

error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is
not 01



It seems weird to me that a public key on the client side is taken into
account, when it works well without.



Linux distrib: CentOS 7

ssh version on the client side: OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb
2013

ssh version on the server side: OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb
2013



Full verbose output of ssh-client:

# ssh -vvv <server-ip>

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 *

debug2: ssh_connect: needpriv 0

debug1: Connecting to <server-ip> [<server-ip>] port 22.

debug1: Connection established.

debug1: permanently_set_uid: 0/0

debug3: Incorrect RSA1 identifier

debug3: Could not load "/root/.ssh/id_rsa" as a RSA1 public key

debug1: identity file /root/.ssh/id_rsa type 1

debug1: identity file /root/.ssh/id_rsa-cert type -1

debug1: identity file /root/.ssh/id_dsa type -1

debug1: identity file /root/.ssh/id_dsa-cert type -1

debug1: identity file /root/.ssh/id_ecdsa type -1

debug1: identity file /root/.ssh/id_ecdsa-cert type -1

debug1: identity file /root/.ssh/id_ed25519 type -1

debug1: identity file /root/.ssh/id_ed25519-cert type -1

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 3 setting O_NONBLOCK

debug3: load_hostkeys: loading entries for host "<server-ip>"
from file
"/root/.ssh/known_hosts"

debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:1

debug3: load_hostkeys: loaded 1 keys

debug3: order_hostkeyalgs: prefer hostkeyalgs:
ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at
openssh.com,ecdsa-sha2-nistp521-cert-v01 at
openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit:
curve25519-sha256 at
libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit:
ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at
openssh.com,ecdsa-sha2-nistp521-cert-v01 at
openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01
at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at
openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at
openssh.com,ssh-ed25519,ssh-rsa,ssh-dss

debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at
openssh.com
,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
rijndael-cbc at lysator.liu.se

debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at
openssh.com
,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
rijndael-cbc at lysator.liu.se

debug2: kex_parse_kexinit:
hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at
openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at
openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at
openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at
openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at
openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at
openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit:
hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at
openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at
openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at
openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at
openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at
openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at
openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib

debug2: kex_parse_kexinit: none,zlib at 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:
curve25519-sha256 at
libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256

debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at
openssh.com
,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
rijndael-cbc at lysator.liu.se

debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at
openssh.com
,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
rijndael-cbc at lysator.liu.se

debug2: kex_parse_kexinit:
hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at
openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at
openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at
openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at
openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at
openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at
openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit:
hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at
openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at
openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at
openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at
openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at
openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at
openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib at openssh.com

debug2: kex_parse_kexinit: none,zlib at 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: setup hmac-md5-etm at openssh.com

debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none

debug2: mac_setup: setup hmac-md5-etm at openssh.com

debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none

debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16

debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16

debug1: sending SSH2_MSG_KEX_ECDH_INIT

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host key: ECDSA <fingerprint>

debug3: load_hostkeys: loading entries for host "<server-ip>"
from file
"/root/.ssh/known_hosts"

debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:1

debug3: load_hostkeys: loaded 1 keys

debug1: Host '<server-ip>' is known and matches the ECDSA host
key.

debug1: Found key in /root/.ssh/known_hosts:1

debug1: ssh_ecdsa_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: /root/.ssh/id_rsa (0x7fb0334d5fd0),

debug2: key: /root/.ssh/id_dsa ((nil)),

debug2: key: /root/.ssh/id_ecdsa ((nil)),

debug2: key: /root/.ssh/id_ed25519 ((nil)),

debug1: Authentications that can continue: publickey

debug3: start over, passed a different list publickey

debug3: preferred
gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password

debug3: authmethod_lookup publickey

debug3: remaining preferred: keyboard-interactive,password

debug3: authmethod_is_enabled publickey

debug1: Next authentication method: publickey

debug1: Offering RSA public key: /root/.ssh/id_rsa

debug3: send_pubkey_test

debug2: we sent a publickey packet, wait for reply

debug1: Authentications that can continue: publickey

debug1: Trying private key: /root/.ssh/id_dsa

debug3: no such identity: /root/.ssh/id_dsa: No such file or directory

debug1: Trying private key: /root/.ssh/id_ecdsa

debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory

debug1: Trying private key: /root/.ssh/id_ed25519

debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory

debug2: we did not send a packet, disable method

debug1: No more authentication methods to try.

Permission denied (publickey).



Elouan

Jakub Jelen

2016-Apr-19 13:18 UTC

head link

Client-side public key causing mess

On 04/19/2016 02:04 PM, Elouan Keryell-Even wrote:> However, on the client-side, if I add a ~/.ssh/id_rsa.pub public key file
> that doesn?t match  the private key file ~/.ssh/id_rsa, it will fail with
> ?Permission denied (publickey).?
Why would you do that?> It seems weird to me that a public key on the client side is taken into
> account, when it works well without.The pubkey authentication works in two steps.
  * The first one is verification only with public key (cheap fast 
operation, which does not require to decode your private key and to 
enter pass-phrase).
  * If the first succeeds (or there is not corresponding public key) 
then the server verifies if you have corresponding private key. If you 
provide signature with different private key, server will fail to verify 
the signature and fails.> debug1: Next authentication method: publickey
>
> debug1: Offering RSA public key: /root/.ssh/id_rsa
>
> debug3: send_pubkey_test
>
> debug2: we sent a publickey packet, wait for reply
>
> debug1: Authentications that can continue: publickeyIt is certainly miss-configuration, but client should probably validate 
what data does it send. I played with similar issue few weeks ago. If I 
am right, it worked the same way in recent openssh versions. But I would 
not consider this as a high priority.

-- 
Jakub Jelen
Security Technologies
Red Hat

Elouan Keryell-Even

2016-Apr-20 07:33 UTC

head link

Client-side public key causing mess

2016-04-19 15:18 GMT+02:00 Jakub Jelen <jjelen at redhat.com>:
> On 04/19/2016 02:04 PM, Elouan Keryell-Even wrote:
>
>> However, on the client-side, if I add a ~/.ssh/id_rsa.pub public key
file
>> that doesn?t match  the private key file ~/.ssh/id_rsa, it will fail
with
>> ?Permission denied (publickey).?
>>
> Why would you do that?
Well it just happened to me, though not in that order. I had old keys
id_rsa & id_rsa.pub files in my .ssh directory. I uploaded a new id_rsa
private key file (generated on another machine) to replace the old one.
However, the id_rsa.pub stayed the same, and I spent a looot of time to
figure out it was the cause of my problem.
>
> It seems weird to me that a public key on the client side is taken into
>> account, when it works well without.
>>
> The pubkey authentication works in two steps.
>  * The first one is verification only with public key (cheap fast
> operation, which does not require to decode your private key and to enter
> pass-phrase).
>  * If the first succeeds (or there is not corresponding public key) then
> the server verifies if you have corresponding private key. If you provide
> signature with different private key, server will fail to verify the
> signature and fails.
 Ok, I understand better know. I guess my mistake was to upload only the
private key on the client side, while I should have uploaded both keys
(wiping out the unnecessary old config which was causing trouble).
>
> debug1: Next authentication method: publickey
>>
>> debug1: Offering RSA public key: /root/.ssh/id_rsa
>>
>> debug3: send_pubkey_test
>>
>> debug2: we sent a publickey packet, wait for reply
>>
>> debug1: Authentications that can continue: publickey
>>
> It is certainly miss-configuration, but client should probably validate
> what data does it send. I played with similar issue few weeks ago. If I am
> right, it worked the same way in recent openssh versions. But I would not
> consider this as a high priority.

Thank you Jakub,

Elouan
>
>
> --
> Jakub Jelen
> Security Technologies
> Red Hat
>
>

Damien Miller

2016-Apr-22 07:41 UTC

head link

Client-side public key causing mess

On Tue, 19 Apr 2016, Elouan Keryell-Even wrote:
> Hello,
> 
> I have a client machine and a server machine. I generated a pair of
> private-public rsa keys using ssh-keygen.
> 
> On the client-machine, I uploaded my private key onto ~/.ssh/id_rsa
> 
> On the server machine, I appended the content of the public key to
> .ssh/authorized_keys
> 
> I can successfully connect from the client to the server with that config.
> 
> However, on the client-side, if I add a ~/.ssh/id_rsa.pub public key file
> that doesn?t match  the private key file ~/.ssh/id_rsa, it will fail with
> ?Permission denied (publickey).?
> 
> Error on the server-side (sshd logs):
> 
> error: RSA_public_decrypt failed:
> error:0407006A:lib(4):func(112):reason(106)
ssh uses the public key to avoid loading or decrypting the private
key for cases were it isn't necessary. We should improve the handling
of cases where they don't match.

diff --git a/sshconnect2.c b/sshconnect2.c
index 1cf48a2..5a27392 100644
--- a/sshconnect2.c
+++ b/sshconnect2.c
@@ -1243,6 +1243,14 @@ load_identity_file(Identity *id)
 			quit = 1;
 			break;
 		}
+		if (private != NULL && id->key != NULL &&
+		    !sshkey_equal(id->key, private)) {
+			error("Load key \"%s\": private key does not match "
+			    "public key", id->filename);
+			sshkey_free(private);
+			private = NULL;
+			quit = 1;
+		}
 		if (!quit && private != NULL && id->agent_fd == -1
&&
 		    !(id->key && id->isprivate))
 			maybe_add_key_to_agent(id->filename, private, comment,

Mauricio Tavares

2016-Apr-22 17:31 UTC

head link

Client-side public key causing mess

On Fri, Apr 22, 2016 at 3:41 AM, Damien Miller <djm at mindrot.org>
wrote:> On Tue, 19 Apr 2016, Elouan Keryell-Even wrote:
>
>> Hello,
>>
>> I have a client machine and a server machine. I generated a pair of
>> private-public rsa keys using ssh-keygen.
>>
>> On the client-machine, I uploaded my private key onto ~/.ssh/id_rsa
>>
>> On the server machine, I appended the content of the public key to
>> .ssh/authorized_keys
>>
>> I can successfully connect from the client to the server with that
config.
>>
>> However, on the client-side, if I add a ~/.ssh/id_rsa.pub public key
file
>> that doesn?t match  the private key file ~/.ssh/id_rsa, it will fail
with
>> ?Permission denied (publickey).?
>>
>> Error on the server-side (sshd logs):
>>
>> error: RSA_public_decrypt failed:
>> error:0407006A:lib(4):func(112):reason(106)
>
> ssh uses the public key to avoid loading or decrypting the private
> key for cases were it isn't necessary. We should improve the handling
> of cases where they don't match.
>      But if it does not have the public key whose name matches the
private key being used, it will still work, right? If that is the case
I too think it should handle non-matching key pairs better. i.e.
ignore behave as if there was just a private key there (which is how I
use it). Or let user decide if it should warn, ignore completely, or
quit.
> diff --git a/sshconnect2.c b/sshconnect2.c
> index 1cf48a2..5a27392 100644
> --- a/sshconnect2.c
> +++ b/sshconnect2.c
> @@ -1243,6 +1243,14 @@ load_identity_file(Identity *id)
>                         quit = 1;
>                         break;
>                 }
> +               if (private != NULL && id->key != NULL
&&
> +                   !sshkey_equal(id->key, private)) {
> +                       error("Load key \"%s\": private key
does not match "
> +                           "public key", id->filename);
> +                       sshkey_free(private);
> +                       private = NULL;
> +                       quit = 1;
> +               }
>                 if (!quit && private != NULL &&
id->agent_fd == -1 &&
>                     !(id->key && id->isprivate))
>                         maybe_add_key_to_agent(id->filename, private,
comment,
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Maybe Matching Threads

Search for more reasonably related threads

openssh unix dev - Apr 2016 - Client-side public key causing mess

Client-side public key causing mess

Client-side public key causing mess

Client-side public key causing mess

Client-side public key causing mess

Client-side public key causing mess

Maybe Matching Threads