Popravak: ssh_exchange_identification 'vezu je zatvorio udaljeni domaćin'

Iako u mnogim slučajevima ssh_exchange_identification: Veza zatvorena pogreškom udaljenog hosta mogu nastati zbog problema povezanih s konfiguracijskim datotekama hosts.deny i hosts.allow, postoje i druge stvari koje mogu uzrokovati problem. Ako ovo čitate, vjerojatno ste već provjerili je li obje ove datoteke blokiralo vašu IP adresu u pokušaju upotrebe ssh-a na udaljenom poslužitelju.

Pod pretpostavkom da je to slučaj, tada možda tražite problem ovisnosti, nešto povezano s fragmentacijom memorije ili čak prevelik broj sesija koje dolaze od pojedinačnih klijenata. Dobra vijest je da nakon što riješite problem, pogrešku više ne biste trebali vidjeti.

Metoda 1: Ispravljanje nedostajućih ovisnosti

Ako ste ssh_exchange_identification: vezu zatvorili pogreškom udaljenog hosta tek nakon ažuriranja OpenSSL-a ili glibc-a, možda tražite ovisnost koja nedostaje. Trčanje sudo lsof -n | grep ssh | grep DEL iz naredbenog retka u ovoj situaciji. To će vam dati popis otvorenih datoteka, a zatim potražite samo one koje su nedavno izbrisane povezane sa ssh demonom.

Ako ništa ne vratite, još uvijek možete pokušati ponovno pokrenuti demon ili sam sustav. Pokušajte ponovno pokrenuti ako vam se vratio niz pogrešaka, iako možete sigurno zanemariti one povezane s / run / user / 1000 / gvfs porukama jer su one uzrokovane nepovezanim problemom koji mora učiniti s virtualnim datotečnim sustavom.

Možete pokušati upotrijebiti apt-get, pacman ili yum za ažuriranje paketa ako sumnjate da su ovisnosti problem. Ako ste na sustavu zasnovanom na Debianu ili Ubuntuu, možda biste htjeli pokušati nadogradnja sudo apt-get -f i provjerite popravlja li to slomljene pakete od kojih ste mogli pasti.

2. metoda: Ispravljanje fragmentacije memorije

Ako ovo nije pomoglo, možda imate problem na domaćoj strani jednadžbe. Domaćini koji se izvode unutar VM-a nemaju uvijek swap particiju, što može dovesti do fragmentacije memorije. Pristupite hostu na neki drugi način, možda fizički ako je moguće, a zatim ponovo pokrenite sve usluge koje pate od problema. Krivci bi mogli biti MySQL, Apache, nginx i druge takve usluge.

Iako nije uvijek moguće ponovno pokrenuti hosta, to može ispraviti problem i možda bi bilo dobro ako ste izmjenjivali ovu poruku o pogrešci i onu koja vraća IP adresu. Imajte na umu da ako imate bilo kakav pristup poslužitelju, tada možete pokrenuti vmstat -s naredbu i dobijte neke važne statistike o tome kako se memorija u mnogim slučajevima koristi čak i kao redoviti korisnik.

3. metoda: Provjerite ima li dodatnih ssh instanci

Ako to zabranite, provjerite pokušavaju li se domaćini povezati s poslužiteljem. Možda ste premašili maksimalan broj ssh sesija, a da to niste znali. Počistite stare sesije, a zatim se pokušajte ponovno povezati. Jedan jednostavan način za to je pokretanje Who naredba da biste vidjeli koji su korisnički procesi prijavljeni. Trebali biste vidjeti samo jednog ili dva prijavljena korisnika. Ako postoji niz paralelnih, ubijte korisničke procese i pokušajte se ponovo prijaviti.

To se može dogoditi ako sshd ne može pratiti skriptu koja započinje mnogo različitih ssh sesija u petlji. Ako vam se ovo ikad dogodilo, dodajte spavati 0.3 naredba petlji tako da sshd demon ima vremena održati korak.

Metoda 4: Pronađite ograničenje veze sshd

Ovakvi problemi s povezivanjem posebno su rašireni kada se pokušava koristiti ssh za pristup usmjerivaču ili drugoj vrsti diskretnog prekidača u kutiji, jer je zadani maksimalni broj veza tako mali. Iako si ne želite dopustiti preopterećenje poslužitelja, možete pogledati koja je zadana postavka.

Pokušajte trčati na poslužitelju kako biste pronašli koliko veza koje sshd može podnijeti. U većini slučajeva sustav bi trebao postaviti 10 simultanih veza, što bi trebalo biti dovoljno za većinu poslužiteljskih struktura za koje će većina korisnika vjerojatno trebati redovito koristiti ssh.