1

I am using Openwrt here, I find that I can login remote host without a password or private key. I added a SSH-Keys (public key) in System->Administration tab, this public key is a key pair with the remote host's private key.

I thought that ssh client must using private key to login, situation here seems it used a public key?

SSH debug log:

root@OpenWrt:~# ssh <HOST> -p 443 -vvv
OpenSSH_6.8p1, OpenSSL 1.0.2e 3 Dec 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to <HOST> [<HOST>] port 443.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
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.8
debug1: Remote protocol version 2.0, remote software version dropbear_2011.54
debug1: no match: dropbear_2011.54
debug2: fd 3 setting O_NONBLOCK
debug3: put_host_port: [<HOST>]:443
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from [<HOST>]:443
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,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-group1-sha1,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug2: bits set: 1004/2048
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: ssh-rsa SHA256:H/MgAoUz/bDefD1KiHrrpPjo8BOqXqUDPd0bhlJr4eE
debug3: put_host_port: [<HOST>]:443
debug3: put_host_port: [<HOST>]:443
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from [<HOST>]:443
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from [<HOST>]:443
debug1: Host '[<HOST>]:443' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug2: bits set: 1008/2048
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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: root@palm-webos (0x77d53ee0),
debug2: key: /root/.ssh/id_rsa ((nil)),
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 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@palm-webos
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp SHA256:wfA3yC7+sEIeTSQp6NUmP14XlgEX5WuJyVoL9m3WrX4
debug3: sign_and_send_pubkey: RSA SHA256:wfA3yC7+sEIeTSQp6NUmP14XlgEX5WuJyVoL9m3WrX4
debug1: Authentication succeeded (publickey).
Authenticated to <HOST> ([<HOST>]:443).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 24576 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

I searched for id_rsa file and found nothing

root@OpenWrt:~# find / -type f -name id_rsa

Left is the problem one, right is normal ssh login using private key:

weird login

Update: Update ssh debug to level 3 and a comparison picture with normal private key login.

  • root@palm-webos is the name of the private key used. – user1133275 Aug 2 '17 at 1:28
  • No, "root@palm-webos" is in the public file – flz Aug 2 '17 at 2:16
  • do you have a Host entry in your ~/.ssh/config (or in /etc/ssh/ssh_config) for that host with an IdentityFile option? – cas Aug 2 '17 at 3:07
  • 1
    I think you're not aware of the authentication process: 1) server checks if the public key the client offers is in authorized_keys file 2) if "yes" then the server will use this public key to encrypt a challenge message (that can only be decrypted if the client has the private key matching this public key) 3) if the client can solve the riddle, access is granted. ---- I strongly assume you have a private key for this public key though. Move it out of the way an you will be denied access. – Fiximan Aug 2 '17 at 6:57
  • 1
    @flz - sorry for underestimating you there. || As for the difference in the screenshots: my wild guess here is that in one case, you use a pem file which has both keys in a single file, while in the other case public and private keys are separate file (I now assume you already knew...). Maybe the different steps/step order can be found there? Especially as it says read PEM private key done: type RSA it looks like it is more about knowing what type of key the (private) pem holds then actually using the private part of the pem file. Just a guess, though ... – Fiximan Aug 2 '17 at 8:46
4
debug3: sign_and_send_pubkey: RSA SHA256:wfA3yC7+sEIeTSQp6NUmP14XlgEX5WuJyVoL9m3WrX4
debug1: Authentication succeeded (publickey).
Authenticated to <HOST> ([<HOST>]:443).

says that you are using public key authentication, that succeeded. The key does not have a path, most probably because it is offered by the ssh-agent.

Update: Update ssh debug to level 3 and a comparison picture with normal private key login.

In the image, you compare connection using one private key with connection using different private key. The difference is that the first one is sending public key test at first to verify if it can succeed, the second sends the signature directly without this test. What is the difference is described in the RFC 4252, Section 7

  • Looks like ssh is using a private key? debug2: key: root@palm-webos (0x77d53ee0),. Maybe I once used a private key and deleted it, ssh cached it somewhere? Now I found no private key in my router and no ssh-agent is running. The string root@palm-webos only appeared in public key's comment. – flz Aug 2 '17 at 15:39
  • ssh-add -l will list this key. If you want to remove it, run ssh-add -D. – Jakuje Aug 2 '17 at 15:40
  • If I don't have ssh-add how can I find or remove it? – flz Aug 2 '17 at 15:47
  • It should be part of OpenSSH clients package. Otherwise, have a look if your SSH_AUTH_SOCK environment variable is set. If so, you have some ssh agent running. – Jakuje Aug 2 '17 at 15:48
0

I think I may found the reason. As @Jakuje mentioned, is because the ssh-agent. My ssh console have an agent holding private keys for authenticating other host. The private key I using to login my Openwrt is the same with my remote host, so when I connect the remote host it using the key.

  • Then you should accept Jakuje's answer. – xhienne Aug 2 '17 at 16:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.