Autorizzazioni per la chiave privata nella cartella .ssh?


381

Ho cambiato le mie autorizzazioni nella mia .sshcartella e ora quando uso un software che utilizza la mia chiave privata, devo digitare la mia password ogni volta. Quali dovrebbero essere le mie autorizzazioni sul mio id_rsafile per non dover digitare una password ogni volta che utilizzo un'app che la utilizza?

Attualmente le mie autorizzazioni sono impostate su:

-rw-------@ 1 Jody  staff   114 Nov  4 23:29 config
-rw-------  1 Jody  staff  1743 Oct 21  2009 id_rsa
-rw-------@ 1 Jody  staff   397 Oct 21  2009 id_rsa.pub 
-rw-------@ 1 Jody  staff  3855 Sep 13 22:35 known_hosts

Risposte:


640

In genere si desidera che le autorizzazioni siano:

  • .ssh directory: 700 (drwx------)
  • chiave pubblica ( .pubfile):644 (-rw-r--r--)
  • chiave privata ( id_rsa):600 (-rw-------)
  • infine la tua home directory non dovrebbe essere scrivibile dal gruppo o da altri (al massimo 755 (drwxr-xr-x)).

Suppongo che intendi dire che devi inserire la password di sistema / utente ogni volta e che in precedenza non dovevi farlo. La risposta di cdhowie sta assumendo che tu abbia impostato una password / passphrase durante la generazione delle tue chiavi, e se lo hai fatto, come dice lui, dovrai inserire la tua password ogni volta che non usi un agente ssh.


13
Ho scoperto altrove che se si utilizza il file authorized_keys, dovrebbe essere chmod'd a 640, cioè -rw-r -----.
AnneTheAgile,

5
Dove posso trovare queste informazioni nelle pagine man?
Sonique,

132
Sono tornato a questo post circa 30 volte. Non posso credere di non poterlo ricordare.
JREAM,

7
Le uniche cose importanti sono che nulla in .ssh è scrivibile a nessun altro e nessuna delle chiavi segrete è leggibile da nessun altro.
Markus Kuhn,

5
L'autorizzazione di esecuzione di @Cerin su una directory garantisce la possibilità di elencare i file / directory secondari immediati di quella directory, i file all'interno della cartella non "ereditano" il bit di esecuzione della loro cartella principale.
Thomas,

87

Ho lottato con questo per sempre e alla fine ho capito cosa è necessario. Sostituisci $USERovunque con il nome utente SSH a cui desideri accedere sul server. Se stai provando ad accedere come rootdovresti usare /root/.sshecc., Invece di /home/root/.sshcome è per gli utenti non root.

  • La home directory sul server non dovrebbe essere scrivibile da altri: chmod go-w /home/$USER
  • La cartella SSH sul server richiede 700 autorizzazioni: chmod 700 /home/$USER/.ssh
  • Il file Authorized_keys richiede autorizzazioni 644: chmod 644 /home/$USER/.ssh/authorized_keys
  • Assicurati di userpossedere i file / le cartelle e non root: chown user:user authorized_keysechown user:user /home/$USER/.ssh
  • Inserire la chiave pubblica generata (da ssh-keygen) nel authorized_keysfile dell'utente sul server
  • Assicurati che la home directory dell'utente sia impostata su come ti aspetti che sia e che contenga la .sshcartella corretta che hai modificato. In caso contrario, utilizzare usermod -d /home/$USER $USERper risolvere il problema
  • Infine, riavvia ssh: service ssh restart
  • Quindi assicurati che il client abbia la chiave pubblica e i file della chiave privata nella .sshcartella dell'utente locale e accedi:ssh user@host.com

Per quanto riguarda il tuo primo paragrafo, sono in grado di ssh con chiavi pubbliche / private con un utente sulla mia casella Linux locale (ad es. abc), Diverso dall'utente sul server remoto (ad es def@123.456.789.). Ho appena avuto per assicurarsi che l'utente locale di proprietà dei file .ssh locali (ad esempio abc:abc, non è root:abc) `
Michael

1
Grazie per aver messo tutti i passaggi e i comandi per i principianti, Alex. La tua è una delle risposte più utili qui.
Nav

6
+1. "Il file Authorized_keys necessita di 644 autorizzazioni" <= è stato fondamentale!
Le Quoc Viet,

Se stai dando la modalità .ssh directory 700 , allora non ha senso dare r-- al gruppo e ad altri, perché solo allora puoi "passare attraverso" .ssh (supponendo che non esistano collegamenti fissi per questi file). Lo stesso per la risposta accettata. Il valore predefinito 755 è sufficiente.
user3125367

400 per i file pem sono sufficienti nella mia esperienza.
AL

37

Assicurati anche che la tua home directory non sia scrivibile da altri utenti.

chmod g-w,o-w ~


8
Cordiali saluti, questo comando presuppone che tu sia loggato come utente e non come root
Alex W

6

Le autorizzazioni non dovrebbero avere nulla a che fare con questo. La tua chiave privata è crittografata con la password, quindi devi inserirla per poter decrittografare e utilizzare la chiave privata.

Potresti considerare di eseguire un agente ssh, che può memorizzare nella cache le chiavi decrittografate e le fornirà alle applicazioni che ne hanno bisogno.


Grazie per le informazioni aggiuntive sull'agente ssh. Sembra che ce ne sia uno integrato in Leopard, quindi penso che lo farò. Ho un po 'di problemi, ma farò un'altra domanda.

5
Non sottovalutare le autorizzazioni. Sicuramente entrano ancora in gioco.
Alex W,

@AlexW Entrano in gioco con altri aspetti di ssh, ma non quello chiesto nella domanda.
cdhowie,

Se non si dispone di password per le chiavi private (ad esempio il telecomando automatizzato chiamato script), non sarà di aiuto. Le autorizzazioni sono necessarie qui.
nerdoc,

"Devo digitare la mia password ogni volta. Quali dovrebbero essere le mie autorizzazioni sul mio file id_rsa per non dover digitare una password ogni volta che utilizzo un'app che la utilizza?"
Craig Hicks,

4

Felipe è corretto: la directory che contiene la directory .ssh non deve essere scrivibile per gruppo o altro. Quindi chmod go-w ~è la prossima cosa logica da provare se ti viene ancora richiesta una password quando ssh'ing dopo l'esecuzione ssh-keygen -t rsa; cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys, supponendo che non assegni una passphrase nel comando ssh-keygen e che la tua directory .ssh sia nella tua home directory.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.