1

Hello there! I was having issues with my Debian VM that runs my Unifi server. After several failed attempts to get it running properly (apt kept returning errors when attempting to upgrade the OS) I finally decided just to back up my application and rebuild the server fresh on Debian 12. So far, so good. I reinstalled the Unifi app, restored my Unifi configuration, and it all worked! I can manage my network again using the Unifi web interface. However when I tried to SSH into the server from my Windows 11 machine Putty and Windows SSH both crashed. From what I can tell from my research my issue is I used the same IP Address and server name for the rebuilt server, so my SSH keys are incorrect. No problem, just delete the keys and let Putty or Windows request verification of the new keys. No dice. I deleted the keys from my .ssh in my user folder and Putty still crashes with the message: Network error: Software caused connection abort. Windows SSH gives the error: kex_exchange_identification: read: Connection reset, followed by Connection reset by {IP Address} port 22. I know the issue is on my local PC because I can connect to the server using my iPad with no issues. iPad asked me to verify the keys of a new server and off it went with no issues… Does anyone have any ideas? Thanks in advance for reading all that!

6 Spice ups
2

Pull up Windows Terminal, connect using ssh username@ipaddress and login with the password. See if that at least gets you something?

1 Spice up
3

Same Windows error message as above - kex_exchange_identification: read: Connection reset

2 Spice ups
4

Can you try that from a different machine that’s never attempted logging into this before? Somewhere, something is holding onto that key. Maybe check your credentials manager in Windows?

1 Spice up
5

If you’re using SSH from Terminal or putty.

Go to C:\users\you\.ssh\ and rename the file (known_hosts) in there.

Try again.

If this works you will need to re-add all keys from other sessions as normal.

2 Spice ups
6

Works from my iPad so I know it is just this PC. Windows Credential Manager does not seem to have the keys anywhere under the server name or IP address.

1 Spice up
7

It only saves passwords, not SSH session information. See above.

2 Spice ups
8

First, I am not using keys for identification, just encryption. I log in with a username and password. Works from my iPad. I renamed the rsa files in the .ssh folder adding .save to the end. Same error messages from Putty and Windows. There has to be somewhere this is saved. I tried looking in the Registry - there was a key saved in there for Putty but it was to a different IP/Server.

1 Spice up
9

It’s not a really old version of Debian is it?

2 Spice ups
10

Debian 12 - latest stable version - and Windows 11

1 Spice up
11

I never said you was, I am saying SSH keys (generically speaking) are not saved in credential manager, SSH logins, regardless of how, are saved in c:\users\you\.ssh\known_hosts.

The known_hosts files contains an SSH key for each host you connect to, it’s unrelated to authentication keys. Think of it as an SSH hash.

Putty stores keys here

HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys

To figure out the issue, use verbose mode in terminal/CMD

ssh -vvv user@your-server-ip

If it’s not clear to you, please share the output

2 Spice ups
12

Thanks - will try that. And sorry if I sounded like I was questioning you - I was just trying to clarify. Back in a minute…thanks again!

1 Spice up
13

I didn’t think you was questioning me, I think you misunderstood my meaning of keys, hence I clarified.

2 Spice ups
14

The output is long so I have shortened it below:
OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2
debug3: Failed to open file:C:/Users/muber/.ssh/config error:2
debug3: Failed to open file:C:/ProgramData/ssh/ssh_config error:2
debug2: resolve_canonicalize: hostname 192.168.1.252 is address
debug3: expanded UserKnownHostsFile ‘~/.ssh/known_hosts’ → ‘C:\Users\muber/.ssh/known_hosts’
debug3: expanded UserKnownHostsFile ‘~/.ssh/known_hosts2’ → ‘C:\Users\muber/.ssh/known_hosts2’
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.1.252 [192.168.1.252] port 22.
debug1: Connection established.
debug3: Failed to open file:C:/Users/muber/.ssh/id_rsa error:2
debug3: Failed to open file:C:/Users/muber/.ssh/id_rsa.pub error:2
debug3: failed to open file:C:/Users/muber/.ssh/id_rsa error:2
debug1: identity file C:\Users\muber/.ssh/id_rsa type -1
… this continues for all the available security types then you get this…
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_9.5
debug3: recv - from CB(2) ERROR:108, io:0000023A69B2D5A0
kex_exchange_identification: read: Connection reset
Connection reset by 192.168.1.252 port 22

I can post it all if you like, but the middle is all just trying different file names…

1 Spice up
15

Are you running fail2ban on your Debian box?

The session does connect, the known_hosts is NOT the issue, something on the Debian side is closing the connection.

Fail2ban or too many invalid attempts is usually the case.

Try this (Debian side), you’ll need to do so at the console or from your iPad.

sudo journalctl -u ssh
or
sudo tail -f /var/log/auth.log

One of these should give you a clue.

While the logs are running, try connecting from your Windows machine

2 Spice ups
16

(post deleted by author)

1 Spice up
17

From what I saw of that, it appears your key-type is not compatible. You might want to review what encryption methods are available on your local machine.

1 Spice up
18

Sorry - deleted it due to IP addresses - here it is without the IPs

ssh_issue
ssh_issue872×325 13.1 KB

Interesting - maybe the new Debian requires stricter keys? I will have to look into that on WIndows 11. Thanks for the pointer and your time.

1 Spice up
19

image
Correct, SSH-RSA key not permitted. Use the list below to select a different key-type.

You’re welcome and enjoy your weekend!

2 Spice ups
20

You as well. Thank you! Interesting that Apple kept up with it on the iPad but Microsoft…nevermind. Have a great weekend!

1 Spice up