SSH: Connection closed by remote host [SOLVED]

[audiodef]

Code: Select all

ssh user@x.x.x.x
kex_exchange_identification: Connection closed by remote host
Connection closed by x.x.x.x port 22

Never encountered this before. Did some searching, but I don't even know what I'm looking for. The SSH is to a remote hosted server, so I have no access unless I fix this. (Although I can get a virtual screen on request from the data center, so that's an option.)

Happened after my SSH terminated because my laptop was on a hotspot and I left the house with my phone. I was expecting that but that has never triggered this issue and I don't think it did. Mentioning it for completeness.

[mike155]

Code: Select all

ssh -v user@x.x.x.x

Code: Select all

ssh -v -v user@x.x.x.x

Code: Select all

ssh -v -v -v user@x.x.x.x

[Banana]

https://www.bjornjohansen.com/ssh-timeout

[audiodef]

I have it set on the server side to not time out, but thanks.

-v -v -v:

Code: Select all

OpenSSH_8.4p1, OpenSSL 1.1.1j  16 Feb 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname x.x.x.x is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/audiodef/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/audiodef/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug2: ssh_connect_direct
debug1: Connecting to x.x.x.x [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/audiodef/.ssh/id_rsa type -1
debug1: identity file /home/audiodef/.ssh/id_rsa-cert type -1
debug1: identity file /home/audiodef/.ssh/id_dsa type -1
debug1: identity file /home/audiodef/.ssh/id_dsa-cert type -1
debug1: identity file /home/audiodef/.ssh/id_ecdsa type -1
debug1: identity file /home/audiodef/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/audiodef/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/audiodef/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/audiodef/.ssh/id_ed25519 type -1
debug1: identity file /home/audiodef/.ssh/id_ed25519-cert type -1
debug1: identity file /home/audiodef/.ssh/id_ed25519_sk type -1
debug1: identity file /home/audiodef/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/audiodef/.ssh/id_xmss type -1
debug1: identity file /home/audiodef/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4
kex_exchange_identification: Connection closed by remote host
Connection closed by x.x.x.x port 22

[mike155]

Maybe this: https://serverfault.com/questions/10155 ... -by-remote, second answer?

[NeddySeagoon]

audiodef.

Some old now insecure ciphers were dropped from ssh.

If one end is new, with the old ciphers missing and the other end is old, with the new ciphers missing, both ends try all their ciphers but can't negotiate a common cipher, so they won't talk to one another.

You can force old ciphers from your end if they are built into ssh but they won't be offered by default.

Hmm. it goes back to news item

Code: Select all

 [22]  N  2015-08-13  (2015-08-13-openssh-weak-keys - removed?)

I remember it as it bit me. :)

[mike155]

@NeddySeagoon: the connection seems to terminate long before cipher negotiation starts. Audiodef doesn't even get the 'remote protocol' message, which usually follows directly after the 'local version' message.

Most likely, Audiodef doesn't to talk to a SSH server at all. That's what the Serverfault article discusses.

[NeddySeagoon]

mike155,

Well spotted.
Something is listening on port 22 though.

[mike155]

@Audiodef: please try

Code: Select all

telnet x.x.x.x 22

If it is an SSH server, it will answer:

Code: Select all

Trying x.x.x.x...
Connected to x.x.x.x.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.4

[eccerr0r]

If it's a Gentoo box, might be that update that required sshd to be restarted before you log back in :(

[audiodef]

My only option at this point was to trigger a restart/reset, so I started with the simplest and requested a ctrl-alt-del. Once my server was back up, it was working again. So sshd needing to be restarted was probably the reason.

Thanks, Gentoodudes, I appreciate it.

[figueroa]

On a remote server, I keep net-misc/dropbear installed and running on a different port as a backup method of accessing the machine should (when) openssh becomes difficult.

[eccerr0r]

Have the dictionary ssh hackers found the extra dropbear port? :(

Seems people do portscan my machines. Very annoying.

I was thinking: I wonder if anyone tried doing this:

Run dropbear on port... get this...

($dayofmonth)+31*($hourofday)+($fixedoffset)

So if someone finds your ssh port, in one hour, it disappears for a month! But only if you remember the offset you chose and if you have a watch and calendar, you can always calculate this very simple hash and connect to your box. Of course you can use a modulus and make a truely pseudorandom but this would make calculation harder to compute.

Still security by obscurity but it keeps exposure down from drive-by portscanners without making it too difficult to connect to your box. Of course you will only have an hour to fix what you need to fix...

[figueroa]

Actually, the Dropbear port can only be reached from inside the LAN from one of several other desktop computers that can also be reached from the WAN.

All are protected by fail2ban. Two fails in 48 hrs get one banned for 72 hrs.

I have found in our use case that some ports, in addition to 22, are ssh hacker magnets. Switching ports a few times helped me find ports that appear to be free of ssh probes (knock on wood), and that for about six months now.

I have occasionally opened a service for as few as 5 minutes to allow another machine on the LAN perform a specific transaction. I could do something like that with Dropbear, but I think I'm good for now. The pseudorandom schedule idea made my stomach growl, but, it's a good idea if you can live with the constraints.

[Hu]

To make the pseudorandom bit really interesting, you could pick the port using a variant of the algorithm that drives common MFA schemes: a shared secret, hashed with the time, and some number of bits pulled out of that result gives you the port number to use. You would probably want to move far less often than a typical MFA jump (30 seconds), but relocating every 10-15 minutes would provide pretty good protection. Deriving it from the MFA secret instead of just a formula would make it much harder to predict, so linear scans would not likely stumble back into it.