On 08/08/2017 01:48 PM, Steven Chamberlain wrote: > Hi, > > I often run my SSH sessions via Tor using tsocks. But today I see: > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle > attack)! > It is also possible that a host key has just been changed. > The fingerprint for the RSA key sent by the remote host is > e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a.
I've seen that happen with Digital Ocean droplets. And when I've checked, I've found that the host key had, in fact, changed. Did you check for that? > Further investigation shows that this happens for any destination IP > address, even where there's no SSH service running: > > $ tsocks ssh -vC root@8.8.8.8 > OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016 > debug1: Reading configuration data /home/steven/.ssh/config > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 19: Applying options for * > debug1: Connecting to 8.8.8.8 [8.8.8.8] port 22. > debug1: Connection established. > debug1: identity file /home/steven/.ssh/id_rsa type 1 > debug1: key_load_public: No such file or directory > debug1: identity file /home/steven/.ssh/id_rsa-cert type -1 > debug1: identity file /home/steven/.ssh/id_dsa type 2 > debug1: key_load_public: No such file or directory > debug1: identity file /home/steven/.ssh/id_dsa-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /home/steven/.ssh/id_ecdsa type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /home/steven/.ssh/id_ecdsa-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /home/steven/.ssh/id_ed25519 type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /home/steven/.ssh/id_ed25519-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 > debug1: Remote protocol version 2.0, remote software version > dropbear_2015.67 > debug1: no match: dropbear_2015.67 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: server->client aes128-ctr hmac-sha2-256 z...@openssh.com > debug1: kex: client->server aes128-ctr hmac-sha2-256 z...@openssh.com > debug1: sending SSH2_MSG_KEX_ECDH_INIT > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > debug1: Server host key: RSA > e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a > The authenticity of host '8.8.8.8 (8.8.8.8)' can't be established. > RSA key fingerprint is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a. > Are you sure you want to continue connecting (yes/no)? : That's not even a host key change. It's just that you don't yet have the host key. > I could be wrong, but I think this "dropbear" service is most likely > something malicious, running on one or more Tor exit nodes, attempting > to collect passwords of people logging in this way. No, dropbear is an SSH server that 8.8.8.8 seems to be running. > If a user ignored the error (or trusts the fingerprint without > verifying), their password, and further activity on the shell could all > be captured by the attacker. > > Since Tor makes my client connections anonymous, and the dropbear is > seen even for hosts that don't provide an SSH service, makes me think > this attack is indiscriminate, not targetted only at me or my servers. > > The first time you connect to some machine, be careful to verify the > fingerprint through independent means. Pay attention to notices like > this of changed key fingerprints. And if you haven't already, disable > PasswordAuthentication to something that cannot be intercepted (like > authorization of private RSA/ECDSA keys). > > Regards, > > > > _______________________________________________ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays