Puncte:1

eroare kex_exchange_identification cu serverul Windows10 OpenSSH

drapel bm

Am instalat OpenSSH-server pe computerul meu cu Windows 10 (probabil o versiune „acasă”, nu un server Windows) folosind ghidul Microsoft. Nu am schimbat C:/Windows/System32/OpenSSH/sshd_config_default fișier (deși oricum nu cred că este relevant aici). eu poate sa conectați-vă la mașină de la un terminal de pe aceeași mașină:

localhost SSH

Am o altă mașină care rulează pe aceeași rețea LAN (ambele conectate la același router SoHo). Din aceasta, încercarea de a vă conecta la Windows 10 eșuează cu:

kex_exchange_identification: Conexiune închisă de gazda la distanță
Conexiune închisă de 10.0.3.130 portul 22

Conform acest răspuns la un alt thread similar, această eroare se întâmplă atunci când serverul închide conexiunea TCP în timpul schimbului criptografic sau ceva de genul acesta. Așa că m-am uitat la firewall-ul Windows, dar acolo este o regulă de intrare activată pentru portul TCP 22 (și, în plus, dacă ar fi fost o problemă de regulă lipsă, clientul SSH ar expira, nu ar avea o eroare în kex_exchange_identification):

firewall

Așa că am încercat să rulez Wireshark pe server (10.0.3.130). Se pare că serverul acceptă strângerea de mână TCP, apoi cealaltă mașină (10.0.3.10) trimite un pachet SSH de protocol și apoi serverul doar închide conexiunea:

Wireshark OpenSSH a început

Pentru a vedea ce s-ar întâmpla, am fost la Windows' Servicii aplicația și a oprit OpenSSH SSH Server service, apoi am încercat același lucru, dar rezultatul cu Wireshark este același:

Wireshark OpenSSH sa oprit

Singurul lucru pe care l-am observat și pe care nu prea îl înțeleg este că alergarea netstat -ab într-un administrator, PowerShell arată că portul 22 are un ascultător activ pe el, chiar și atunci când OpenSSH este oprit (doar lucrurile Windows presupun...):

comanda netstat

Deci, da... Sunt ciocănit în acest moment. Vreo idee?

Puncte:0
drapel bm

TL;DR: După mai multe căutări și am încercat să repornesc așa cum au sugerat alții, am găsit o soluție simplă:

  1. Faceți ca Windows să pornească serverul OpenSSH pe un port care netstat -ab nu apare ca luat prin adăugarea liniei Port portNumber în %programdata%\ssh\sshd_config [*] (înlocuind numarul portului de portul ales desigur). Eu personal am ales portul 222, deoarece este ușor de reținut.
  2. Adăugați regula de intrare pentru portul TCP numarul portului în Firewall Windows Defender cu securitate avansată.

Ceea ce cred că a fost greșit este ceea ce am arătat ultima dată: acea ultimă imagine pare să arate că, în cazul meu, portul 22 (pe care este de obicei serverul OpenSSH) era deja ocupat de un alt server, fără legătură (din... orice motiv). ).Așadar, clientul SSH făcea strângere de mână TCP, pe care acel server fără legătură o accepta, iar apoi clientul a trimis un pachet de protocol OpenSSH (pe care serverul fără legătură nu îl înțelege), ceea ce a făcut ca acest server fără legătură să închidă pur și simplu conexiunea TCP.

Acum este adevărat că am putut să mă conectez la serverul ssh de pe portul 22 de la serverul însuși. Cred că asta se datorează faptului că te conectezi la gazdă locală trimite pachetele către interfața de loopback, pe care probabil că acel server fără legătură nu o asculta.

Deci soluția logică este să mutați pur și simplu serverul OpenSSH într-un alt port care nu este utilizat și apoi să adăugați regula de intrare la acel nou port în firewall-ul Windows. Cu toate acestea, o soluție adevărată ar fi să găsești în ce serverul neînrudit ascultă pe portul 22 și apoi fie să-l ucizi, fie să-l muți. aceasta într-un alt port.

[*]: Spre deosebire de ceea ce credeam, fișierul de configurare OpenSSH este nu C:/Windows/System32/OpenSSH/sshd_config_default ; este de fapt %programdata%\ssh\sshd_config conform acest ghid de la Microsoft. Asa de C:/Windows/System32/OpenSSH/sshd_config_default pare, așa cum indică și numele, să fie acolo doar pentru a arăta care este configurația serverului OpenSSH atunci când nu schimbăm nicio configurație în %programdata%\ssh\sshd_config, sau atunci când acel fișier nu există.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.