Questão Permissões na chave privada na pasta .ssh?


Eu mudei minhas permissões no meu .ssh pasta e agora quando eu uso um software que usa minha chave privada, eu tenho que digitar minha senha toda vez. Quais devem ser minhas permissões no meu id_rsa arquivo para não ter que digitar uma senha cada vez que eu uso um aplicativo que usa?

Atualmente minhas permissões estão definidas para:

-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

276


origem




Respostas:


Normalmente você quer o .ssh permissões de diretório para ser 700 (drwx------) e a chave pública (.pub arquivo) para ser 644 (-rw-r--r--). Sua chave privada (id_rsa) deveria estar 600 (-rw-------). Por último, o seu diretório home não deve ser gravável pelo grupo ou por outras pessoas (no máximo 755 (drwxr-xr-x)).

Eu estou supondo que você quer dizer que você tem que digitar sua senha do sistema / usuário a cada vez, e que anteriormente você não precisava. A resposta do cdhowie é assumir que você definiu uma senha / frase secreta ao gerar suas chaves, e se você fez isso, como ele diz, você terá que digitar sua senha toda vez, a menos que você use um agente ssh.


480



Eu encontrei em outro lugar que, se usando o arquivo authorized_keys, que deveria ser chmod'd para 640, ou seja, -rw-r -----. - AnneTheAgile
Onde posso encontrar essa informação em man pages? - Sonique
Eu voltei a este post cerca de 30 vezes agora. Eu não posso acreditar que eu não consigo lembrar. - JREAM
As únicas coisas importantes são que nada em .ssh é gravável para qualquer outra pessoa e nenhuma das chaves secretas é legível para qualquer outra pessoa. - Markus Kuhn
@Cerin permissão de execução em um diretório concede a capacidade de listar arquivos / diretórios filhos imediatos desse diretório, os arquivos dentro da pasta não "herdam" o bit de execução de sua pasta pai. - Thomas


Eu estava lutando com isso para sempre e finalmente descobri o que é necessário. Substituir $USER em todos os lugares com o nome de usuário SSH que você deseja fazer no servidor. Se você está tentando fazer login como root você precisaria usar /root/.ssh etc., em vez de /home/root/.ssh que é como é para usuários não-root.

  • O diretório inicial no servidor não deve ser gravável por outros: chmod go-w /home/$USER
  • A pasta SSH no servidor precisa de 700 permissões: chmod 700 /home/$USER/.ssh
  • O arquivo Authorized_keys precisa de 644 permissões: chmod 644 /home/$USER/.ssh/authorized_keys
  • Certifique-se de que user possui os arquivos / pastas e não root: chown user:user authorized_keys e chown user:user /home/$USER/.ssh
  • Coloque a chave pública gerada (de ssh-keygen) no usuário authorized_keys arquivo no servidor
  • Certifique-se de que o diretório pessoal do usuário esteja configurado para o que você espera e que ele contenha .ssh pasta que você modificou. Se não, use usermod -d /home/$USER $USER para corrigir o problema
  • Finalmente, reinicie o ssh: service ssh restart
  • Em seguida, certifique-se de que o cliente tenha a chave pública e os arquivos de chave privada no usuário local .ssh pasta e login: ssh user@host.com

62



Em relação ao seu primeiro parágrafo, eu posso ssh com chaves públicas / privadas com um usuário na minha caixa linux local (por exemplo, abc), diferente do usuário no servidor remoto (por exemplo, def@123.456.789). Eu só tinha que garantir que o usuário local possuísse os arquivos .ssh locais (por exemplo, abc:abc, não root:abc) - Michael
Obrigado por colocar todos os passos e comandos para iniciantes, Alex. A sua é uma das respostas mais úteis aqui. - Nav
+1. "O arquivo Authorized_keys precisa de 644 permissões" <= isso foi crucial! - Le Quoc Viet
Se você está dando o diretório .ssh 700 modo, então há sem sentido em dar r-- para grupo e outros, porque só você pode "passar por" .ssh (assumindo que não existam links físicos para esses arquivos). O mesmo para a resposta aceita. Padrão 755 é suficiente. - user3125367


Além disso, certifique-se de que seu diretório pessoal não seja gravável por outros usuários.

chmod g-w,o-w ~


31



FYI, este comando assume que você está logado como usuário e não root - Alex W


Permissões não devem ter nada a ver com isso. Sua chave privada é criptografada com a senha, portanto, é necessário inseri-la para que a chave privada seja descriptografada e utilizável.

Você pode considerar a execução de um agente ssh, que pode armazenar em cache as chaves descriptografadas e fornecê-las aos aplicativos que precisam delas.


4



Obrigado pela informação adicional sobre o agente ssh. Parece que há um construído no Leopard, então acho que vou fazer isso. Tendo um pouco de dificuldade com isso, mas vou fazer outra pergunta.
Não subestime as permissões. Eles definitivamente ainda entram em jogo. - Alex W
@AlexW Eles entram em jogo com outros aspectos do ssh, mas não o questionado na questão. - cdhowie
Se você não tiver nenhuma senha em chaves privadas (whink de scripts chamados remotos automatizados), isso não o ajudará. Permissões são necessárias aqui. - nerdoc


Felipe está correto - o diretório que contém seu diretório .ssh não deve ser gravável por grupo ou outro. portanto chmod go-w ~ é a próxima coisa lógica para tentar se você ainda for solicitado para uma senha quando ssh'ing após a execução ssh-keygen -t rsa; cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys, supondo que você não tenha atribuído uma frase secreta no comando ssh-keygen, e seu diretório .ssh esteja em seu diretório pessoal.


4