Mi ci sono volute ore per risolvere questo problema SSH con uno dei miei account di classe sui server della mia scuola.
Non potevo accedere a un particolare account di classe senza inserire la mia password, mentre l'autenticazione senza password funzionava con gli altri account di classe. La directory .ssh/ e tutto il suo contenuto avevano le stesse autorizzazioni corrette degli altri account di classe.
Si scopre che il problema erano le autorizzazioni impostate sulla mia home directory. L'autenticazione senza password non funzionava quando i permessi nella mia directory HOME erano impostati su 770 (indipendentemente dai permessi impostati per .ssh/), ma funzionava con i permessi impostati su 755 o 700.
Qualcuno sa perché SSH fa questo? È perché i permessi della home directory sono troppo permissivi? Perché SSH si rifiuta di autenticarsi con le chiavi pubbliche/private quando la home directory è impostata su un valore più permissivo di 700?
Risposta accettata:
Questo è il comportamento predefinito per SSH. Protegge le chiavi utente applicando rwx------ su $HOME/.ssh e assicurandoti che solo il proprietario abbia i permessi di scrittura su $HOME . Se un utente diverso dal rispettivo proprietario ha il permesso di scrittura su $HOME directory, potrebbero modificare maliziosamente i permessi su $HOME/.ssh , potenzialmente dirottando le chiavi utente, known_hosts , o qualcosa di simile. In sintesi, le seguenti autorizzazioni su $HOME sarà sufficiente per il funzionamento di SSH.
rwx------rwxr-x---rwxr-xr-x
SSH non funzionerà correttamente e invierà avvisi alle strutture di log in caso di variazione di g+w o o+w esiste su $HOME directory. Tuttavia, l'amministratore può ignorare questo comportamento definendo StrictModes no nel sshd_config (o simile) file di configurazione, anche se dovrebbe essere chiaro che questo è non consigliato .