Mens i mange tilfeller ssh_exchange_identification: Connection closed by remote host error kan være forårsaket av problemer relatert til hosts.deny og hosts.all konfigurasjonsfiler, er det andre ting som kan forårsake problemet. Hvis du leser dette, er sjansen stor for at du allerede har sjekket for å forsikre deg om at begge disse filene ikke blokkerte IP-adressen din fra å prøve å bruke ssh på en ekstern server.
Forutsatt at dette er tilfelle, kan du se på et avhengighetsproblem, noe relatert til minnefragmentering eller til og med et for stort antall økter som kommer fra individuelle klienter. Den gode nyheten er at når du har tatt vare på problemet, bør du ikke se feilen igjen.
Metode 1: Løse manglende avhengigheter
Hvis du først har fått ssh_exchange_identification: tilkobling av ekstern vertfeil etter oppdatering av OpenSSL eller glibc, kan du se på en manglende avhengighet. Kjør sudo lsof -n | grep ssh | grep DEL fra kommandolinjen i denne situasjonen. Dette vil gi deg en liste over åpne filer, og se bare etter de som nylig ble slettet relatert til ssh-demonen.
Hvis du ikke får noe tilbake, kan du fortsatt prøve å starte demonen eller selve systemet på nytt. Du vil prøve å starte på nytt hvis en rekke feil ble kastet tilbake på deg, selv om du trygt kan ignorere de som er relatert til / run / user / 1000 / gvfs-meldinger, da disse er forårsaket av et ikke-relatert problem som må gjøre med et virtuelt filsystem.
Du kan prøve å bruke apt-get, pacman eller yum for å oppdatere pakkene dine også hvis du mistenker at avhengigheter er et problem. Hvis du bruker et Debian- eller Ubuntu-basert system, kan det være lurt å prøve sudo apt-get -f oppgradering og se om det løser ødelagte pakker som du kanskje har falt for.
Metode 2: Korrigere minnefragmentering
Hvis dette ikke hjalp, kan det hende du har et problem på vertssiden av ligningen. Verter som kjører inne i en VM, har ikke alltid en byttepartisjon, noe som kan føre til minnefragmentering. Få tilgang til verten på noen annen måte, kanskje fysisk hvis mulig, og start deretter alle tjenester som lider av problemer på nytt. MySQL, Apache, nginx og andre slike tjenester kan være skyldige.
Selv om det ikke alltid er mulig å starte verten på nytt, kan dette løse problemet, og det kan være en god ide hvis du har vekslet mellom denne feilmeldingen og en som returnerer en IP-adresse. Husk at hvis du har noen form for tilgang til serveren, kan du kjøre kommandoen vmstat -s og få noen viktige statistikker om hvordan minne blir vant til og med som en vanlig bruker i mange tilfeller.
Metode 3: Se etter ekstra ssh-forekomster
Sperre dette, og sjekk deretter om verter prøver å koble til serveren. Du har kanskje overskredet maksimalt antall ssh-økter uten å vite det. Fjern de gamle øktene, og prøv å koble til igjen. En enkel måte å gjøre dette på er å kjøre hvem- kommandoen for å se hvilke brukerprosesser som er logget inn. Du bør bare se en eller to brukere pålogget. Hvis det er flere parallelle, drep brukerprosessene og prøv å logge inn igjen .
Dette kan skje hvis sshd ikke kan følge med et skript som starter mange forskjellige ssh-økter i en løkke. Hvis dette noen gang skjedde med deg, så legg sleep 0.3- kommandoen til løkken slik at sshd-demonen har tid til å følge med.
Metode 4: Finn sshd Connection Limit
Tilkoblingsproblemer som dette er spesielt utbredt når du prøver å bruke ssh for å få tilgang til en ruter eller en annen type diskret boksebryter, siden standard maksimalt antall tilkoblinger er så lite. Selv om du ikke vil tillate deg selv å overbelaste serveren, kan du se på standardinnstillingen.
Prøv å kjøre 
på serveren for å finne hvor mange tilkoblinger som sshd kan håndtere. I de fleste tilfeller bør systemet som standard ha 10 samtidige tilkoblinger, noe som bør være tilstrekkelig for de fleste serverstrukturer som et flertall av brukerne sannsynligvis trenger å bruke ssh på regelmessig.
