0

I was trying to upgrade debian buster to bullseye, during the installation/upgrade of packages putty crashed. Since then I cant connect anymore to my server.

I tried via ssh, telnet, virtualmin(some kind of a control panel). All failed. Via putty I get the following error: Network error: Software caused connection abort.

Powershell:kex_exchange_identification: read: Connection reset

ssh -v [email protected]

OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug1: Connecting to my.server.ip.address [my.server.ip.address] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\mypc/.ssh/id_rsa type -1
debug1: identity file C:\\Users\\mypc/.ssh/id_rsa-cert type -1
debug1: identity file C:\\Users\\mypc/.ssh/id_dsa type -1
debug1: identity file C:\\Users\\mypc/.ssh/id_dsa-cert type -1
debug1: identity file C:\\Users\\mypc/.ssh/id_ecdsa type -1
debug1: identity file C:\\Users\\mypc/.ssh/id_ecdsa-cert type -1
debug1: identity file C:\\Users\\mypc/.ssh/id_ed25519 type -1
debug1: identity file C:\\Users\\mypc/.ssh/id_ed25519-cert type -1
debug1: identity file C:\\Users\\mypc/.ssh/id_xmss type -1
debug1: identity file C:\\Users\\mypc/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1
kex_exchange_identification: read: Connection reset

I dont have physical access to the server. I contacted the host but they said they cant help. From my control panel in the host I have 3 buttons Reinstall, Reboot, Netboot.

The server is up and running, the websites etc. are also working fine. I want to try Reboot but Im just afraid that it will make things worse... I would highly appreciate any help! How in the world I can access my server?

Update: I found out that my host has a rescue mode, I rebooted in rescue mode and found out that the sshd.conf was overwritten. I renamed the old configuration file and rebooted again. Now I have ssh access.

2
  • 1
    A wise admin once said: "remote update leads to far travel". You misread the Debian upgrade instructions which do cover this issue by suggesting to use screen or tmux precisely to avoid interruption of the long-running terminal bound processes due to various network-related reasons. Commented May 14 at 5:52
  • Please accept an answer if one was helpful; resolutions are better tracked as answers. You may answer your own question. Commented May 17 at 0:16

1 Answer 1

2

kex_exchange_identification is an OpenSSH function early in a ssh conversation, when ssh version is being negotiated. A read getting a connection reset does not explain much about how ssh might be broken, only that a socket could not be read, possibly a TCP conversation was reset.

Not to be confused with an OpenSSH server logging kex_exchange_identification errors. Internet noise like port scans throw a lot of malformed SSH traffic around, which may end up with these in logs.

Find an out of band way to rescue the system that does not rely on ssh. A serial console can provide a text prompt very early in boot, even before IP is working. If this is a rented VM, its generally on the hosting provider to provide such a feature. And any appropriate access methods such as ssh to a jump box to access it.

Absent a console, when IP and/or ssh is not working, be creative about rebooting the instance and on which disk. Power off the VM and attach the disk to some other instance, mount the volume, and examine logs. Restore the system from backup to a previously working state.

Consider additional testing of the software upgrade in an environment where you have full local access. Even without a VM server on premises, a hypervisor on a desktop could be a personal playground. Not ideal, but a host you cannot access is not great either.

You must log in to answer this question.

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