Soluzione 1:
Sì, puoi farlo, proprio come lo hai descritto.
[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] ~$
Soluzione 2:
È un po' una digressione, ma.....
Se utilizzi sempre lo stesso nome utente per un server remoto, potresti anche trovare utile aggiungere un host nella tua configurazione ssh:
Host remotesystem
User baruser
In questo modo non devi ricordarti di specificare il nome utente quando accedi e lo escludi in caso di problemi con le chiavi in futuro.
Soluzione 3:
Il tuo nome utente locale non ha molta importanza (a parte la chiave privata che deve risiedere nella home directory dell'utente locale). Basta copiare la chiave nello authorized_keys dell'utente remoto sezione e funzionerà.
Soluzione 4:
Con qualsiasi problema relativo a ssh, la prima cosa da fare è aumentare la verbosità del client:
ssh [email protected] -vvv
Se questo non riesce a darti informazioni su cosa c'è che non va, devi cambiare il livello di log sul server e riavviare il demone.
LogLevel DEBUG3
Dovresti trovare l'output di debug in /var/log/auth.log (o ovunque ssh sia configurato per accedere). Una volta trovato il problema, ricordati di reimpostarlo su come l'hai trovato.
Soluzione 5:
I permessi sulle directory .ssh su entrambe le macchine sono molto corretti. Generalmente, ciò significa 700 nella directory .ssh e al massimo 755 nella home directory. Oltre a 600 su tutti i file nelle directory .ssh.
Se l'utente sul sistema remoto è root, assicurati che root possa eseguire ssh. (PermitRootLogin in sshd_config) e quella chiave pubblica (PubkeyAuthentication) e se necessario RSA (RSAAuthentication) sono abilitate.