Permissões na chave privada na pasta .ssh?


381

Alterei minhas permissões na minha .sshpasta e agora, quando uso um software que usa minha chave privada, tenho que digitar minha senha todas as vezes. Quais devem ser minhas permissões no meu id_rsaarquivo para não precisar digitar uma senha toda vez que uso um aplicativo que a utilize?

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

Respostas:


640

Normalmente você deseja que as permissões sejam:

  • .ssh diretório: 700 (drwx------)
  • chave pública ( .pubarquivo):644 (-rw-r--r--)
  • chave privada ( id_rsa):600 (-rw-------)
  • por fim, o diretório inicial não deve ser gravável pelo grupo ou por outros (no máximo 755 (drwxr-xr-x)).

Estou assumindo que você quer dizer que precisa digitar sua senha de sistema / usuário toda vez e que anteriormente não precisava. A resposta do cdhowie está assumindo que você definiu uma senha / frase secreta ao gerar suas chaves, e se você o fez, como ele diz, terá que digitar sua senha todas as vezes, a menos que use um agente ssh.


13
Eu descobri em outro lugar que, se estiver usando o arquivo allowed_keys, ele deve ser chmod'd para 640, ou seja, -rw-r -----.
AnneTheAgile

5
Onde posso encontrar essas informações nas páginas de manual?
Sonique

131
Voltei a este post cerca de 30 vezes. Não acredito que não consigo me lembrar.
JREAM 02/04

7
As únicas coisas importantes são que nada no .ssh pode ser gravado por mais ninguém e nenhuma das chaves secretas pode ser lida por mais ninguém.
Markus Kuhn

5
A permissão de execução do @Cerin em um diretório concede a capacidade de listar arquivos / diretórios filho imediatos desse diretório, os arquivos dentro da pasta não "herdam" o bit de execução da pasta pai.
Thomas

87

Eu estava lutando com isso para sempre e finalmente descobri o que é necessário. Substitua $USERtodos os lugares pelo nome de usuário SSH no qual você deseja fazer login no servidor. Se você estiver tentando fazer o login como rootprecisaria usar /root/.sshetc., em vez de /home/root/.sshcomo é para usuários não-root.

  • O diretório inicial no servidor não deve ser gravável por terceiros: 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 userpossui os arquivos / pastas e não root: chown user:user authorized_keysechown user:user /home/$USER/.ssh
  • Coloque a chave pública gerada (de ssh-keygen) no authorized_keysarquivo do usuário no servidor
  • Verifique se o diretório pessoal do usuário está definido como o esperado e que contém a .sshpasta correta que você está modificando. Caso contrário, use usermod -d /home/$USER $USERpara corrigir o problema
  • Por fim, reinicie o ssh: service ssh restart
  • Em seguida, verifique se o cliente possui os arquivos de chave pública e de chave privada na .sshpasta do usuário local e faça o login:ssh user@host.com

Em relação ao seu primeiro parágrafo, sou capaz de 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

1
Obrigado por colocar todas as etapas e comandos para iniciantes, Alex. A sua é uma das respostas mais úteis aqui.
Nav

6
+1. "O arquivo Authorized_keys precisa de 644 permissões" <= isso foi crucial!
Le Quoc Viet

Se você está dando o modo de diretório .ssh 700 , não há sentido em atribuir r-- ao grupo e a outros, porque somente você pode "passar" pelo .ssh (assumindo que não existem links físicos para esses arquivos). O mesmo para a resposta aceita. O padrão 755 é suficiente.
User3125367

400 para os arquivos pem são suficientes na minha experiência.
AT

37

Verifique também se o diretório inicial não pode ser gravado por outros usuários.

chmod g-w,o-w ~


8
Para sua informação, este comando assume que você está logado como usuário e não root
Alex W

6

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 executar um agente ssh, que pode armazenar em cache chaves descriptografadas e fornecê-las aos aplicativos que precisam delas.


Obrigado pelas informações adicionais sobre o agente ssh. Parece que existe um embutido no Leopard, então acho que vou fazer isso. Tendo um pouco de dificuldade, mas vou fazer outra pergunta.

5
Não subestime 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 pergunta.
Cdhowie 24/05

Se você não tiver uma senha em chaves privadas (conjunto de scripts chamados remotos automatizados), isso não ajudará. As permissões são necessárias aqui.
Nerdoc

"Tenho que digitar minha senha todas as vezes. Quais devem ser minhas permissões no meu arquivo id_rsa para não precisar digitar uma senha toda vez que uso um aplicativo que a utiliza?"
Craig Hicks

4

Felipe está correto - o diretório que contém o diretório .ssh não deve ser gravável por grupo ou outro. Portanto, chmod go-w ~é a próxima coisa lógica a tentar se você ainda solicitar uma senha ao executar a ssh'ing após a execução ssh-keygen -t rsa; cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys, supondo que você não atribua uma senha no comando ssh-keygen, e o diretório .ssh esteja no diretório inicial.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.