Discussion:
Client-side public key causing mess
(too old to reply)
Elouan Keryell-Even
2016-04-19 12:04:33 UTC
Permalink
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-***@openssh.com,ecdsa-sha2-nistp384-cert-***@openssh.com,ecdsa-sha2-nistp521-cert-***@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-***@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-***@openssh.com,ecdsa-sha2-nistp384-cert-***@openssh.com,ecdsa-sha2-nistp521-cert-***@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-***@openssh.com,ssh-rsa-cert-***@openssh.com,ssh-dss-cert-***@openssh.com,ssh-rsa-cert-***@openssh.com,ssh-dss-cert-***@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss

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

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

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

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

debug2: kex_parse_kexinit: none,***@openssh.com,zlib

debug2: kex_parse_kexinit: none,***@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-***@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-***@openssh.com,aes256-***@openssh.com,chacha20-***@openssh.com
,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
rijndael-***@lysator.liu.se

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

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

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

debug2: kex_parse_kexinit: none,***@openssh.com

debug2: kex_parse_kexinit: none,***@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-***@openssh.com

debug1: kex: server->client aes128-ctr hmac-md5-***@openssh.com none

debug2: mac_setup: setup hmac-md5-***@openssh.com

debug1: kex: client->server aes128-ctr hmac-md5-***@openssh.com none

debug1: kex: curve25519-***@libssh.org need=16 dh_need=16

debug1: kex: curve25519-***@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-04-19 13:18:10 UTC
Permalink
Post by Elouan Keryell-Even
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?
Post by Elouan Keryell-Even
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.
Post by Elouan Keryell-Even
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.
--
Jakub Jelen
Security Technologies
Red Hat
Elouan Keryell-Even
2016-04-20 07:33:26 UTC
Permalink
Post by Jakub Jelen
Post by Elouan Keryell-Even
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.
Post by Jakub Jelen
It seems weird to me that a public key on the client side is taken into
Post by Elouan Keryell-Even
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).
Post by Jakub Jelen
debug1: Next authentication method: publickey
Post by Elouan Keryell-Even
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
Post by Jakub Jelen
--
Jakub Jelen
Security Technologies
Red Hat
Damien Miller
2016-04-22 07:41:10 UTC
Permalink
Post by Elouan Keryell-Even
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: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-04-22 13:06:14 UTC
Permalink
Post by Elouan Keryell-Even
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: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
Post by Elouan Keryell-Even
2013
ssh version on the server side: OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11
Feb
Post by Elouan Keryell-Even
2013
# ssh -vvv <server-ip>
What happens if you specify the private key (as in -i
/root/.ssh/id_rsa)?
Post by Elouan Keryell-Even
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
Post by Elouan Keryell-Even
debug3: load_hostkeys: loaded 1 keys
ecdsa-sha2-nistp384-cert-***@openssh.com,
ecdsa-sha2-nistp521-cert-***@openssh.com
,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
Post by Elouan Keryell-Even
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
,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
ecdsa-sha2-nistp384-cert-***@openssh.com,
ecdsa-sha2-nistp521-cert-***@openssh.com
,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
Post by Elouan Keryell-Even
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
chacha20-***@openssh.com
,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
Post by Elouan Keryell-Even
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
chacha20-***@openssh.com
,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
,umac-128-***@openssh.com,hmac-sha2-256-***@openssh.com,
hmac-sha2-512-***@openssh.com,hmac-ripemd160-***@openssh.com,
hmac-sha1-96-***@openssh.com,hmac-md5-96-***@openssh.com,hmac-md5,hmac-sha1,
umac-***@openssh.com,umac-***@openssh.com
,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-***@openssh.com
,hmac-sha1-96,hmac-md5-96
,umac-128-***@openssh.com,hmac-sha2-256-***@openssh.com,
hmac-sha2-512-***@openssh.com,hmac-ripemd160-***@openssh.com,
hmac-sha1-96-***@openssh.com,hmac-md5-96-***@openssh.com,hmac-md5,hmac-sha1,
umac-***@openssh.com,umac-***@openssh.com
,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-***@openssh.com
,hmac-sha1-96,hmac-md5-96
Post by Elouan Keryell-Even
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
,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
Post by Elouan Keryell-Even
debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
chacha20-***@openssh.com
,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
Post by Elouan Keryell-Even
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
chacha20-***@openssh.com
,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
,umac-128-***@openssh.com,hmac-sha2-256-***@openssh.com,
hmac-sha2-512-***@openssh.com,hmac-ripemd160-***@openssh.com,
hmac-sha1-96-***@openssh.com,hmac-md5-96-***@openssh.com,hmac-md5,hmac-sha1,
umac-***@openssh.com,umac-***@openssh.com
,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-***@openssh.com
,hmac-sha1-96,hmac-md5-96
,umac-128-***@openssh.com,hmac-sha2-256-***@openssh.com,
hmac-sha2-512-***@openssh.com,hmac-ripemd160-***@openssh.com,
hmac-sha1-96-***@openssh.com,hmac-md5-96-***@openssh.com,hmac-md5,hmac-sha1,
umac-***@openssh.com,umac-***@openssh.com
,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-***@openssh.com
,hmac-sha1-96,hmac-md5-96
Post by Elouan Keryell-Even
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
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
Post by Elouan Keryell-Even
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
_______________________________________________
openssh-unix-dev mailing list
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Mauricio Tavares
2016-04-22 17:31:09 UTC
Permalink
Post by Damien Miller
Post by Elouan Keryell-Even
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: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.
Post by Damien Miller
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
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Damien Miller
2016-04-23 00:39:50 UTC
Permalink
Post by Mauricio Tavares
Post by Damien Miller
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.
Having a mismatched private and public key is an invalid configuration.
We don't need to implement complicated recovery logic for it, we can
just tell the user and they can fix it themself (or not).

-d
Nico Kadel-Garcia
2016-04-23 16:18:50 UTC
Permalink
Post by Damien Miller
Post by Mauricio Tavares
Post by Damien Miller
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.
Having a mismatched private and public key is an invalid configuration.
We don't need to implement complicated recovery logic for it, we can
just tell the user and they can fix it themself (or not).
-d
Is a published requirement that a local copy of a key, such as
$HOME/.ssh/id_rsa, match a copy of the local public key, such as
$HOME/.ssh/id_rsa.pub, and vice versa? While it seems very sensible,
I've certainly seen people replicate one to a new working environment
without the other, and later accidentally copy the other file from a
new working environment. I've not really seen anyone get bitten hard
by this discrepancy since they'mostly using ssh-agent or the Windows
"Pageant" tool, but if it's a requirement I've seen nothing stating it
explicitly.

Is this a good reason to discard keeping public keys around?

Loading...