Ecco una breve nota sulla configurazione degli accessi senza password tra 2 sistemi Linux. Il processo consiste sostanzialmente nel generare una chiave di autenticazione pubblica e aggiungerla al file ~/.ssh/authorized_keys degli host remoti.
Genera chiave di autenticazione
Se non esiste un file di chiave di autenticazione SSH, generarne uno eseguendo ssh-keygen comando. Quando viene richiesta una passphrase, utilizza una passphrase vuota se è richiesto un accesso completamente senza password:
# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: 1e:b2:f4:89:5a:7f:2d:a5:a5:4d:6d:66:2c:82:d8:18 root@remote-host
Copia la chiave pubblica sull'host remoto
Utilizza ssh-copy-id comando per installare la metà pubblica della chiave di autenticazione appena generata nella home directory di un utente specifico sull'host remoto. Il comando ssh-copy-id aggiungerà quindi automaticamente le informazioni sull'identità in ~/.ssh/authorized_keys per l'utente specificato sull'host remoto (creando ~/.ssh e~/.ssh/authorized_keys se necessario).
# ssh-copy-id -i ~/.ssh/id_rsa.pub user@remote-host user@remote-hosts's password:
In alternativa se il server non è installato con openssh-clients (un pacchetto che fornisce l'utilità di comando ssh-copy-id) puoi copiare la chiave di autenticazione con il comando:
# cat ~/.ssh/id_rsa.pub | ssh user@remote-host "cat >> ~/.ssh/authorized_keys"
Se tutto è configurato correttamente, dovresti essere in grado di accedere all'host remoto senza password.
Risoluzione dei problemi
Verifica le autorizzazioni corrette
La causa più comune dei problemi con il funzionamento dell'autenticazione ssh basata su chiave sono le autorizzazioni dei file sul server ssh remoto
Se sono stati seguiti i passaggi precedenti e l'invio di ssh all'utente appropriato continua a richiedere le password, controllare le autorizzazioni su entrambi i file dell'utente locale e remoto . I permessi delle directory dovrebbero essere esattamente come mostrati di seguito. L'esempio mostrato qui è per l'utente "oracle"
drwx------. 25 oracle oinstall 4096 Aug 21 11:01 /home/oracle/ drwx------. 2 oracle oinstall 4096 Aug 17 13:13 /home/oracle/.ssh -rw-------. 1 oracle oinstall 420 Aug 17 13:13 /home/oracle/.ssh/authorized_keys
Se i permessi non sono quelli mostrati sopra, impostali correttamente :
# chmod 600 ~/.ssh/authorized_keys chmod 700 ~/.ssh/
Riavvia il servizio sshd per rendere effettive le modifiche:
# service sshd restart
disabilitazione di SElinux
SELinux può anche potenzialmente impedire a sshd di accedere alla directory ~/.ssh sul server. Questo problema può essere escluso (o risolto) eseguendo restorecon come segue nella directory ~/.ssh dell'utente remoto:
# restorecon -Rv ~/.ssh