SSH: Connection closed by remote host [SOLVED]

Banana · Veteran Joined: 21 May 2004 Posts: 1384 Location: Germany

https://www.bjornjohansen.com/ssh-timeout
_________________
My personal space
My delta-labs.org snippets do expire

PFL - Portage file list - find which package a file or command belongs to.

audiodef · Posted: Tue Mar 02, 2021 12:32 am Post subject:

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

-v -v -v:

mike155 · Posted: Tue Mar 02, 2021 12:46 am Post subject:

Maybe this: https://serverfault.com/questions/1015547/what-causes-ssh-error-kex-exchange-identification-connection-closed-by-remote, second answer?

NeddySeagoon · Posted: Tue Mar 02, 2021 10:11 am Post subject:

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

mike155 · Posted: Tue Mar 02, 2021 1:45 pm Post subject:

@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 · Posted: Tue Mar 02, 2021 2:12 pm Post subject:

mike155,

Well spotted.
Something is listening on port 22 though.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

mike155 · Posted: Tue Mar 02, 2021 3:15 pm Post subject:

@Audiodef: please try

eccerr0r · Posted: Tue Mar 02, 2021 6:05 pm Post subject:

If it's a Gentoo box, might be that update that required sshd to be restarted before you log back in :(
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

audiodef · Posted: Tue Mar 02, 2021 9:17 pm Post subject:

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.

_________________
decibel Linux: https://decibellinux.org
Github: https://github.com/Gentoo-Music-and-Audio-Technology
Facebook: https://www.facebook.com/decibellinux
Discord: https://discord.gg/73XV24dNPN

figueroa · Posted: Wed Mar 03, 2021 3:18 am Post subject:

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.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi

eccerr0r · Posted: Wed Mar 03, 2021 4:01 pm Post subject:

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...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

figueroa · Posted: Wed Mar 03, 2021 4:38 pm Post subject:

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.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi

Hu · Moderator Joined: 06 Mar 2007 Posts: 21607

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.