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

— JakeGould
fonte

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.

— Fabs
fonte

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

— Alex W
fonte

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 ~

— Felipe Alvarez
fonte

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.

— cdhowie
fonte

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.

— mikentalk
fonte