Řešení 1:
Ano, můžete to udělat, jak jste to popsali.
[email protected] ~$ ssh-add -l 4096 10:b3:fd:29:08:86:24:a6:da:0a:dd:c6:1e:b0:66:6a id_rsa (RSA) [email protected] ~$ ssh [email protected] motd message, etc. [email protected] ~$
Řešení 2:
Je to trochu stranou, ale......
Pokud pro vzdálený server vždy používáte stejné uživatelské jméno, může být užitečné přidat hostitele do vaší konfigurace ssh:
Host remotesystem
User baruser
Tímto způsobem nemusíte pamatovat na zadání uživatelského jména při přihlašování a vyloučíte to, když budete mít v budoucnu problémy s klíči.
Řešení 3:
Na vašem místním uživatelském jménu opravdu nezáleží (kromě soukromého klíče, který musí být umístěn v domovském adresáři vašeho místního uživatele). Stačí zkopírovat klíč do authorized_keys vzdáleného uživatele a bude to fungovat.
Řešení 4:
V případě jakýchkoli problémů souvisejících s ssh je první věcí, kterou musíte udělat, je zvýšit výřečnost klienta:
ssh [email protected] -vvv
Pokud vám to neposkytne žádné informace o tom, co je špatně, musíte změnit úroveň protokolu na serveru a restartovat démona.
LogLevel DEBUG3
Výstup ladění byste měli najít v /var/log/auth.log (nebo kdekoli, kde je ssh nakonfigurováno k přihlášení). Jakmile problém najdete, nezapomeňte jej nastavit zpět do stavu, v jakém jste jej našli.
Řešení 5:
Oprávnění v adresářích .ssh na obou počítačích jsou velmi správná. Obecně to znamená 700 v adresáři .ssh a maximálně 755 v domovském adresáři. Kromě 600 na všechny soubory v adresářích .ssh.
Pokud je uživatel na vzdáleném systému root, ujistěte se, že root může ssh. (PermitRootLogin v sshd_config) a tento veřejný klíč (PubkeyAuthentication) a v případě potřeby RSA (RSAAuthentication) jsou povoleny.