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: [email protected],[email protected],ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: [email protected],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: [email protected],[email protected],ssh-rsa,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],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.

Improve this question
9
  • root@palm-webos is the name of the private key used.
    – user1133275
    Commented Aug 2, 2017 at 1:28
  • No, "root@palm-webos" is in the public file
    – flz
    Commented Aug 2, 2017 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
    Commented Aug 2, 2017 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.
    – FelixJN
    Commented Aug 2, 2017 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 ...
    – FelixJN
    Commented Aug 2, 2017 at 8:46

2 Answers 2

Reset to default
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

Improve this answer
4
  • 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
    Commented Aug 2, 2017 at 15:39
  • ssh-add -l will list this key. If you want to remove it, run ssh-add -D.
    – Jakuje
    Commented Aug 2, 2017 at 15:40
  • If I don't have ssh-add how can I find or remove it?
    – flz
    Commented Aug 2, 2017 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
    Commented Aug 2, 2017 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.

Improve this answer
1
  • Then you should accept Jakuje's answer.
    – xhienne
    Commented Aug 2, 2017 at 16:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .