Medan i många fall ssh_exchange_identification: Connection closed by remote host error kan orsakas av problem relaterade till hosts.deny och hosts.allow konfigurationsfiler, det finns andra saker som kan orsaka problemet. Om du läser detta är chansen att du redan har kontrollerat för att se till att båda dessa filer inte blockerar din IP-adress från att försöka använda ssh på en fjärrserver.
Om vi antar att detta är fallet, kan du titta på en beroendeproblem, något relaterat till minnesfragmentering eller till och med ett alltför stort antal sessioner som kommer från enskilda klienter. Den goda nyheten är att när du har tagit hand om problemet borde du inte se felet igen.
Metod 1: Åtgärda saknade beroenden
Om du har fått ssh_exchange_identification: anslutningen stängdes av fjärrvärdfel först efter uppdatering av OpenSSL eller glibc, kanske du tittar på ett saknat beroende. Kör sudo lsof -n | grep ssh | grep DEL från kommandoraden i denna situation. Detta ger dig en lista över öppna filer och leta bara efter de som nyligen har tagits bort relaterade till ssh-demonen.
Om du inte får tillbaka något kan du fortfarande försöka starta om demonen eller själva systemet. Du vill prova omstart om ett antal fel kastades tillbaka på dig, men du kan säkert ignorera de som är relaterade till / run / user / 1000 / gvfs-meddelanden eftersom dessa orsakas av ett orelaterat problem som måste gör med ett virtuellt filsystem.
Du kan också försöka använda apt-get, pacman eller yum för att uppdatera dina paket om du misstänker att beroenden är ett problem. Om du använder ett Debian- eller Ubuntu-baserat system kanske du vill prova sudo apt-get -f uppgradering och se om det löser några trasiga paket som du kanske har fallit fel med.
Metod 2: Korrigera minnesfragmentering
Om det inte hjälpte kan du ha ett problem på värdsidan av ekvationen. Värdar som körs inuti en virtuell dator har inte alltid en växlingspartition, vilket kan leda till minnesfragmentering. Åtkomst till värden på något annat sätt, kanske fysiskt om möjligt, och starta sedan om alla tjänster som lider av problem. MySQL, Apache, nginx och andra sådana tjänster kan vara synderna.
Även om det kanske inte alltid är möjligt att starta om värden, kan detta rätta till problemet och det kan vara en bra idé om du har växlat mellan detta felmeddelande och en som returnerar en IP-adress. Tänk på att om du har någon form av åtkomst till servern kan du köra kommandot vmstat -s och få viktig statistik om hur minnet blir vant även som en vanlig användare i många fall.
Metod 3: Sök efter extra ssh-instanser
Spärra detta och kontrollera om värdarna försöker ansluta till servern. Du kanske har överskridit det maximala antalet ssh-sessioner utan att veta det. Rensa upp de gamla sessionerna och försök sedan återansluta. Ett enkelt sätt att göra detta är att köra kommandot who för att se vilka användarprocesser som är inloggade. Du bör bara se en eller två användare inloggade. Om det finns ett antal parallella, döda sedan användarprocesserna och försök logga in igen .
Detta kan hända om sshd inte kan följa med ett skript som startar många olika ssh-sessioner i en slinga. Om detta någonsin hänt dig, lägg sedan till sleep 0.3- kommandot i slingan så att sshd-demonen har tid att fortsätta.
Metod 4: Hitta sshd Connection Limit
Anslutningsproblem som detta är särskilt vanliga när du försöker använda ssh för att komma åt en router eller en annan typ av diskret boxed switch eftersom standard maximalt antal anslutningar är så litet. Medan du inte vill tillåta dig själv att överbelasta servern kan du ta en titt på vad standardinställningen är.
Försök att köra 
på servern för att hitta hur många anslutningar som sshd klarar. I de flesta fall bör systemet vara standard för 10 samtidiga anslutningar, vilket borde vara gott för de flesta serverstrukturer som en majoritet av användarna sannolikt kommer att behöva använda ssh på regelbundet.
