Posso utilizzare l'autenticazione con chiave SSH per accedere a un sistema remoto con un nome utente diverso?

Supponiamo che io abbia un sistema remoto chiamato "remotesystem" e un account utente "foouser" su quel sistema.

So che sul mio sistema locale, posso generare una coppia di chiavi SSH come utente locale "foouser", inserire la chiave pubblica nel file "/home/foouser/.ssh/authorized_keys" su "remotesystem". Quando SSH come "foouser" dal mio sistema locale a "remotesystem", SSH utilizza la coppia di chiavi per autenticarmi.

Ma cosa succede se il mio nome utente locale non è lo stesso del nome utente sul sistema remoto? Cioè, cosa succede se voglio SSH come utente locale "baruser" in "remotesystem"? Ovviamente, dovrò generare una coppia di chiavi per "baruser" e aggiungere la chiave pubblica a "/home/foouser/.ssh/authorized_keys". Quindi, dovrei essere in grado di "ssh foouser @ remotesystem" mentre eseguo l'accesso come "baruser" localmente e SSH utilizzerà la coppia di chiavi per l'autenticazione, giusto?

Lo sto chiedendo perché sto cercando di far funzionare l'autenticazione chiave in questo scenario, senza successo. Non sono sicuro che sia dovuto alla mancata corrispondenza del nome utente o a un problema di configurazione con il server SSH sul sistema remoto.

Sì, puoi farlo, proprio come l'hai descritto.

baruser @ qui ~ $ ssh-add -l
4096 10: b3: fd: 29: 08: 86: 24: a6: da: 0a: dd: c6: 1e: b0: 66: 6a id_rsa (RSA)
baruser @ here ~ $ ssh foouser @ remotesystem
motd message, ecc.
foouser @ remotesystem ~ $

È un po 'un lato, ma .....

Se usi 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 è necessario ricordare di specificare il nome utente durante l'accesso e lo si esclude in caso di problemi con le chiavi in ​​futuro.

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 nella authorized_keyssezione dell'utente remoto e funzionerà.

Con eventuali problemi relativi a SSH, la prima cosa da fare è aumentare la verbosità del client:

ssh user @ machine -vvv

Se ciò non fornisce informazioni dettagliate sull'errore, è necessario modificare il livello di registro sul server e riavviare il daemon.

LogLevel DEBUG3

Dovresti trovare l'output di debug in /var/log/auth.log (o dove mai ssh è configurato per accedere). Una volta trovato il problema, ricordati di riportarlo su come l'hai trovato.

Le autorizzazioni per le directory .ssh su entrambe le macchine sono molto corrette. In genere, 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, assicurarsi che root possa ssh. (PermitRootLogin in sshd_config) e quella chiave pubblica (PubkeyAuthentication) e, se necessario, RSA (RSAAuthentication) sono abilitati.

Se hai abilitato SE Linux, dovrai anche fare quanto segue.

Aggiungi l'etichetta SELinux a in authorized_keysmodo che possa essere accessibile da sshd.

semanage fcontext -a -t sshd_key_t ~foo/.ssh/authorized_keys
restorecon -Rv ~user/.ssh

Sembra che tu stia facendo le cose correttamente, ma assicurati che i permessi siano corretti su authorized_keys. Dovrebbero essere impostati su 600.