Fix: ssh_exchange_identification: läs: återställning av anslutning av peer

Lyckligtvis är ssh_exchange_identification: läs: Återställning av anslutning med peer-fel är ganska sällsynt, men du kan stöta på det om du försöker ssh till någon typ av Unix-server. Det spelar ingen roll om du använder Windows med cygwin för att komma åt Ubuntu eller macOS med terminalen för att ssh till Arch, Fedora eller CentOS. Eftersom ssh är universellt i Unix och Linux kan detta fel uppstå när fjärrservern återställer anslutningen utan din tillåtelse.

Metod 1: Kontrollera filen hosts.deny

Om du har administrativa behörigheter på servern och ett sätt att komma åt den, är det överlägset enklaste sättet att lösa problemet att gå till en fråga som är inloggad direkt på serverns dator och titta på filen hosts.deny.

Typ på servern för att se om din maskin är listad som förbjuden av någon anledning.

Om det är så är det i allmänhet ett misstag och du kan ta bort det säkert och sedan ansluta igen via ssh på den andra maskinen. Kontrollera annars att det inte finns några konstiga jokertecken som skulle förbjuda din maskin att anslutas. En ny fil med ingenting annat än standardtexten som lagts till av serverns distribution skulle dock inte vara den skyldige i de flesta fall.

Prova om du vill lägga till fjärranloggningen manuellt för att säkerställa att den kan anslutas. Tänk på att detta sällan är nödvändigt, men om du lägger till dem måste du följa den informationstext som distributionen tillhandahöll. Du skulle till exempel lägga till en rad längst ner som läser som ALL: appuals.com så att alla på appuals.com kan ansluta till servern. Se till att du skriver din värd korrekt om du gör det, tryck sedan på Ctrl + O för att spara filen och Ctrl + X för att avsluta.

Du bör kunna ssh in på servern vid denna tidpunkt.

Metod 2: Ändra konfigurationsalternativ för ssh

Om du inte kan komma till fjärrservern eller om den tidigare metoden inte fixade alternativet, rensa sedan dina gamla ssh-konfigurationsfiler och se om det gör tricket efter en uppdatering. Förutsatt att det inte gör det, lägg sedan till -v-alternativet till ssh och försök att ansluta igen. Om du fortfarande får ett felmeddelande, försök lägga till -c aes256-ctr till ditt ssh-kommando och se om det gör tricket. Detta bör förkorta chifferlistan och låta dig ansluta till servern du försökte ssh in eftersom detta förkortar paketstorleken i sin tur.

Vissa användare har noterat att detta är särskilt användbart vid felsökning av vissa typer av Cisco-märkt utrustning eftersom vissa bitar av serverhårdvara förväntar sig mindre paketstorlekar som standard. Lägg helt enkelt till -c aes256-ctr till ditt vanliga ssh-kommando så ska du kunna komma in.

Metod 3: Åsidosätt oavsiktliga IP-förbud

Om du har försökt logga in några gånger tidigare och nekats kan din egen server ha misstagit dig för en dålig IP-adress. Detta händer vanligtvis om du fortsätter att försöka anslutningen under felsökning, vilket är ett rationellt svar men det kan se ut som en attack mot underrutinen fail2ban. För att se till att detta inte är fallet, kör sudo iptables -L –line-nummer från fjärranslutningen och leta efter din IP-adress. Du kommer antagligen att upptäcka att det finns ett antal icke-relaterade anslutningar som du kan ignorera.

När du har hittat problemet, kör iptables -D följt av den kränkande kedjan och kedjan för att förhindra att du blir utestängd av din egen programvara igen. Du borde inte ha några ytterligare problem som ett resultat. Men om du gör det,

du kan redigera följande fil.

Ladda upp det i din favorittextredigerare, mer än troligt nano eller vi, som root. Du kommer antagligen vilja köra något liknande och leta sedan efter en rad som läser ignorip. Lägg till din IP-adress till den här raden för att permanent blockera fail2ban från att lägga till din IP-adress till några blocklistor.

Olika Linux-distributioner gör saker lite annorlunda, men dessa ändringar bör träda i kraft omedelbart i de flesta fall.