Proč je mi odepřeno oprávnění (publicky) při pokusu o SSH z místního Ubuntu na server Amazon EC2?

Řešení 1:

První věc, kterou v této situaci udělat, je použít -v možnost ssh , takže můžete vidět, jaké typy autentizace jsou vyzkoušeny a jaký je výsledek. Pomůže to osvětlit situaci?

Ve své aktualizaci vaší otázky uvádíte „na jiném místním Ubuntu“. Zkopírovali jste soukromý klíč ssh do druhého počítače?

Řešení 2:

Protože to nebylo výslovně uvedeno, sshd je ve výchozím nastavení velmi přísné na oprávnění pro authorized_keys soubory. Pokud tedy authorized_keys je zapisovatelný pro kohokoli jiného než uživatele nebo může být upraveno pro zápis kýmkoli jiným než uživatelem, odmítne ověření (pokud není sshd nakonfigurováno s StrictModes no )

To, co mám na mysli slovem "lze vytvořit zapisovatelný", je to, že pokud je do kteréhokoli z nadřazených adresářů zapisovatelný pro kohokoli jiného než uživatele, uživatelé s povolením upravovat tyto adresáře mohou začít upravovat oprávnění takovým způsobem, že mohou upravovat/nahradit autorizované_klíče.

Navíc, pokud /home/username/.ssh adresář není ve vlastnictví uživatele, a proto uživatel nemá žádná oprávnění ke čtení klíče, můžete se setkat s problémy:

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

Všimněte si, že jane nevlastní .ssh soubor. Opravte to pomocí

chown -R jane:jane /home/jane/.ssh

Tyto druhy problémů s oprávněními k souborovému systému se s ssh -v nezobrazí a ani se nezobrazí v protokolech sshd (!), dokud nenastavíte úroveň protokolu na DEBUG.

• Upravit /etc/ssh/sshd_config . Chcete řádek, který zní LogLevel DEBUG tam někde. Znovu načtěte server SSH pomocí mechanismu poskytovaného distribucí. (service sshd reload na RHEL/CentOS/Scientific.) Pěkné opětovné načtení nezruší existující relace.
• Zkuste ověření znovu.
• Zjistěte, kam se ukládají vaše protokoly ověřovacího zařízení, a přečtěte si je. (IIRC, /var/log/auth.log v distribucích založených na Debianu; /var/log/secure na RHEL/CentOS/Scientific.)

Mnohem snazší zjistit, co je špatně s výstupem ladění, který zahrnuje chyby oprávnění souborového systému. Nezapomeňte vrátit změnu na /etc/ssh/sshd_config až bude hotovo!

Řešení 3:

Tato chyba se mi zobrazila, protože jsem zapomněl přidat -l volba. Moje místní uživatelské jméno nebylo stejné jako na vzdáleném systému.

Toto není odpověď na vaši otázku, ale dostal jsem se sem, abych hledal odpověď na svůj problém.

Řešení 4:

Tuto zprávu jsem dostal na nové instanci založené na Ubuntu AMI. Použil jsem volbu -i k poskytnutí PEM, ale stále se mi zobrazovalo "Povolení odepřeno (publickey)".

Můj problém byl, že jsem nepoužil správného uživatele. Spuštěním ssh s [email protected] to fungovalo jako normálně.

Řešení 5:

Něco, co je snáze čitelné než ssh -v (podle mého názoru samozřejmě), je tail -f /var/log/auth.log . To by mělo být spuštěno na serveru, ke kterému se pokoušíte připojit, při pokusu o připojení. Zobrazí chyby v prostém textu.

Toto mi pomohlo vyřešit můj problém:

Uživatel [uživatelské jméno] z xx.yy.com není povolen, protože žádná z uživatelských skupin není uvedena v AllowGroups