Fix: ssh_exchange_identification & lsquo; forbindelse lukket af ekstern vært & rsquo;

Mens i mange tilfælde ssh_exchange_identification: Forbindelse lukket af ekstern værtsfejl kan være forårsaget af problemer relateret til hosts.deny og hosts.alle konfigurationsfiler, er der andre ting, der kan forårsage problemet. Hvis du læser dette, er chancerne for, at du allerede har kontrolleret for at sikre, at begge disse filer ikke blokerede din IP-adresse fra at prøve at bruge ssh på en ekstern server.

Hvis vi antager, at dette er tilfældet, ser du måske på et afhængighedsproblem, noget relateret til hukommelsesfragmentering eller endda et for stort antal sessioner, der kommer fra individuelle klienter. Den gode nyhed er, at når du først har taget dig af problemet, skal du ikke se fejlen igen.

Metode 1: Rettelse af manglende afhængigheder

Hvis du først har fået ssh_exchange_identification: forbindelsen lukket ved fjernværtsfejl efter opdatering af OpenSSL eller glibc, ser du muligvis på en manglende afhængighed. Kør sudo lsof -n | grep ssh | grep DEL fra kommandolinjen i denne situation. Dette giver dig en liste over åbne filer, og kig derefter kun efter dem, der for nylig blev slettet relateret til ssh-dæmonen.

Hvis du ikke får noget tilbage, kan du stadig prøve at genstarte dæmonen eller selve systemet. Du vil prøve en genstart, hvis et antal fejl blev kastet tilbage på dig, selvom du sikkert kan ignorere dem, der er relateret til / run / user / 1000 / gvfs-meddelelser, da disse er forårsaget af et ikke-relateret problem, der skal gøre med et virtuelt filsystem.

Du kan også prøve at bruge apt-get, pacman eller yum til at opdatere dine pakker, hvis du har mistanke om, at afhængigheder er et problem. Hvis du bruger et Debian- eller Ubuntu-baseret system, kan du prøve sudo apt-get -f opgradering og se, om det løser eventuelle ødelagte pakker, som du muligvis er kommet i fare for.

Metode 2: Korrigering af hukommelsesfragmentering

Hvis dette ikke hjalp, har du muligvis et problem på værtssiden af ​​ligningen. Værter, der kører inde i en VM, har ikke altid en swap-partition, hvilket kan føre til hukommelsesfragmentering. Få adgang til værten på anden måde, måske fysisk, hvis det er muligt, og genstart derefter alle tjenester, der lider af problemer. MySQL, Apache, nginx og andre sådanne tjenester kan være synderne.

Selvom det måske ikke altid er muligt at genstarte værten, kan dette rette problemet og det kan være en god ide, hvis du har skiftet mellem denne fejlmeddelelse og en, der returnerer en IP-adresse. Husk, at hvis du har nogen form for adgang til serveren, kan du køre kommandoen vmstat -s og få nogle vigtige statistikker om, hvordan hukommelse bliver brugt, selv som en almindelig bruger i mange tilfælde.

Metode 3: Kontroller for ekstra ssh-forekomster

Udeluk dette, og kontroller derefter, om værter forsøger at oprette forbindelse til serveren. Du har muligvis overskredet det maksimale antal ssh-sessioner uden at vide det. Ryd de gamle sessioner op, og prøv derefter at oprette forbindelse igen. En nem måde at gøre dette på er at køre hvem- kommandoen for at se, hvilke brugerprocesser der er logget ind. Du skal kun se en eller to brugere logget ind. Hvis der er et antal parallelle, skal du dræbe brugerprocesserne og prøve at logge ind igen .

Dette kan ske, hvis sshd ikke kan følge med et script, der starter mange forskellige ssh-sessioner i en løkke. Hvis dette nogensinde er sket for dig, skal du tilføje kommandoen sleep 0.3 til sløjfen, så sshd-dæmonen har tid til at følge med.

Metode 4: Find sshd-forbindelsesgrænsen

Forbindelsesproblemer som dette er især udbredt, når du forsøger at bruge ssh til at få adgang til en router eller en anden type diskret bokseafbryder, da det maksimale standardforbindelse er så lille. Mens du ikke vil tillade dig selv at overbelaste serveren, kan du se på, hvad standardindstillingen er.

Prøv at køre på serveren for at finde ud af, hvor mange forbindelser sshd kan håndtere. I de fleste tilfælde skal systemet som standard have 10 samtidige forbindelser, hvilket skal være rigeligt for de fleste serverstrukturer, som et flertal af brugere sandsynligvis har brug for at bruge ssh regelmæssigt.