Původně zveřejněno na Ask Ubuntu
Pokud jste vyloučili nějaké „externí“ faktory, následující soubor kroků obvykle pomůže je zúžit. Takže i když to přímo neodpovídá na vaši otázku, může to pomoci zjistit příčinu chyby.
Odstraňování problémů sshd
Co považuji obecně za velmi užitečné v takových případech, je spustit sshd aniž by se nechal démonizovat. Problém v mém případě byl, že ani syslog ani auth.log ukázal něco smysluplného.
Když jsem to spustil z terminálu, dostal jsem:
# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.
Mnohem lepší! Tato chybová zpráva mi umožnila zjistit, co je špatně, a opravit to. Žádný ze souborů protokolu tento výstup neobsahoval.
Poznámka: alespoň na Ubuntu $(which sshd) je nejlepší metodou, jak vyhovět sshd požadavek absolutní cesty. Jinak se zobrazí následující chyba:sshd re-exec requires execution with an absolute path . -p 10222 dělá sshd poslouchat na tomto alternativním portu a přepsat konfigurační soubor - to proto, aby se nekolidoval s potenciálně spuštěným sshd instance. Zde si vyberte bezplatný port.
Nakonec:připojte se k alternativnímu portu (ssh -p 10222 [email protected] ).
Tato metoda mi mnohokrát pomohla při hledání problémů, ať už jde o problémy s autentizací nebo jiné typy. Chcete-li získat opravdu podrobný výstup na stdout , použijte $(which sshd) -Ddddp 10222 (všimněte si přidaného dd pro zvýšení výřečnosti). Pro další ladění zkontrolujte man sshd .
Hlavní výhodou této metody je, že vám umožňuje zkontrolovat sshd konfigurace bez musíte restartovat sshd na výchozím portu. Normálně to by nemělo narušovat stávající připojení SSH, ale viděl jsem to. To vám umožňuje ověřit konfigurační soubor předtím, než - potenciálně - odříznete přístup ke vzdálenému serveru (například to mám pro některé VPS a dokonce i pro fyzické servery, kde musím platit navíc, abych získal přístup mimo pásmo). do stroje).
Můžete také mít hostitele, jehož paměť je tak silně fragmentovaná, že nemůže přidělit stránce souvislou paměť pro rozvětvení procesu hostování relace SSH.
V takovém případě můžete obdržet jednu ze zpráv:
ssh_exchange_identification: read: Connection reset by peer
nebo:
Connection closed by aaa.bbb.ccc.ddd
v závislosti na tom, jak daleko se hostitel dostane, než se zachrání.
Pokud je zřejmou příčinou fragmentace paměti, řešením je přístup k serveru jinými prostředky a restartování některých příslušných služeb. Zjistil jsem, že Apache a MySQL jsou viníkem na VM, protože VM nemají odkládací oddíl. Pokud se tak nestane, restartujte hostitele.
Pro jistotu, protože se mi to stalo. Ujistěte se, že v hostiteli běží sshd!
Je to hloupé selhání, ale může to být opravdu váš problém.