Heldigvis ssh_exchange_identification: les: Tilkobling tilbakestilt av peer-feil er ganske sjelden, men du kan støte på den hvis du prøver å ssh inn i en hvilken som helst type Unix-server. Det spiller ingen rolle om du bruker Windows med cygwin for å få tilgang til Ubuntu eller macOS med terminalen for å ssh inn i Arch, Fedora eller CentOS. Siden ssh er universelt på tvers av Unix og Linux, kan denne feilen oppstå når den eksterne serveren tilbakestiller tilkoblingen uten din tillatelse.
Metode 1: Sjekk hosts.deny-filen
Hvis du har administratorrettigheter på serveren og en måte å få tilgang til den, er den uten tvil den enkleste måten å løse dette problemet på å gå over til en ledelse som er logget direkte på serverens datamaskin og se på hosts.deny-filen.
Type
på serveren for å se om maskinen din er oppført som utestengt av en eller annen grunn.
Hvis det er, er dette vanligvis en feil, og du kan trygt fjerne den og deretter koble til via ssh på den andre maskinen. Ellers må du kontrollere at det ikke er rare jokertegn som forbyr maskinen din å koble til. En fersk fil uten annet enn standardteksten som ble lagt til av serverens distribusjon, vil imidlertid ikke være skyldige i de fleste tilfeller.
Prøve
hvis du vil legge til ekstern pålogging manuelt for å sikre at den kan kobles til. Husk at dette sjelden er nødvendig, men hvis du legger til dem, må du følge informasjonsteksten som distribusjonen ga. Du vil for eksempel legge til en linje nederst som lyder som ALLE: appuals.com for å tillate alle på appuals.com å koble til serveren. Forsikre deg om at du skriver verten riktig hvis du gjør dette, og trykk deretter Ctrl + O for å lagre filen og Ctrl + X for å avslutte.
Du bør kunne ssh inn på serveren på dette tidspunktet.
Metode 2: Endring av ssh-konfigurasjonsalternativer
Hvis du ikke kommer til den eksterne serveren eller hvis den forrige metoden ikke løste alternativet, fjerner du de gamle ssh-konfigurasjonsfilene og ser om det gjør susen etter en oppdatering. Forutsatt at det ikke gjør det, legg deretter til -v-alternativet til ssh og prøv å koble til igjen. Hvis du fremdeles får en feilmelding, kan du prøve å legge til -c aes256-ctr til ssh-kommandoen din og se om det gjør trikset. Dette bør forkorte krypteringslisten og tillate deg å koble til serveren du prøvde å ssh inn siden dette forkorter pakkestørrelsen i sin tur.
Noen brukere har bemerket at dette er spesielt nyttig når man feilsøker noen typer Cisco-merket utstyr, fordi noen stykker servermaskinvare forventer mindre pakkestørrelser som standard. Bare legg til -c aes256-ctr til din vanlige ssh-kommando, og du skal kunne komme inn.
Metode 3: Overstyring av utilsiktet IP-forbud
Hvis du har prøvd å logge på noen ganger før og ble nektet, kan det hende at din egen server mistet deg for en dårlig IP-adresse. Dette skjer vanligvis hvis du fortsetter å prøve tilkoblingen mens du feilsøker, noe som er et rasjonelt svar, men det kan se ut som et angrep på fail2ban-underrutinen. For å sikre at dette ikke er tilfelle, kjør sudo iptables -L –line-nummer fra ekstern tilkobling og se etter IP-adressen din. Du vil sannsynligvis oppdage at det er et hvilket som helst antall urelaterte tilkoblinger du kan ignorere.
Når du har funnet problemet, løp iptables -D etterfulgt av den fornærmende kjeden og kjedenummeret for å forhindre at du blir utestengt av din egen programvare igjen. Du bør ikke ha noen ytterligere problemer som et resultat. Men hvis du gjør det,
du kan redigere følgende fil.
Last den opp i favoritt teksteditoren din, mer enn sannsynlig nano eller vi, som root. Du vil sannsynligvis ønske å kjøre noe sånt
og se etter en linje som leser ignorip. Legg til IP-adressen din på denne linjen for å blokkere permanent fail2ban fra å legge til IP-adressen din i noen blokkeringslister.
Ulike Linux-distribusjoner gjør ting litt annerledes, men disse endringene bør tre i kraft umiddelbart i de fleste tilfeller.
