too - ssh file permissions chmod




ssh “permissões são muito abertas” (10)

Eu tive um problema com o meu Mac, onde eu não podia mais salvar qualquer tipo de arquivo no disco. Eu tive que reiniciar o leão OSX e redefinir as permissões em arquivos e acls.

Mas agora, quando quero confirmar um repositório, recebo o seguinte erro do ssh:

Permissions 0777 for '/Users/username/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

Quais níveis de permissão devo dar ao arquivo id_rsa?


0600 é o que o meu está definido (e está funcionando)


A solução independente de localidade que funciona no Windows 8.1 é:

chgrp 545 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa

O GID 545 é um ID especial que sempre se refere ao grupo "Usuários", mesmo que você use uma palavra diferente para Usuários.


As chaves precisam ser legíveis apenas por você:

chmod 400 ~/.ssh/id_rsa

600 parece estar bem também (na verdade melhor na maioria dos casos, porque você não precisa alterar as permissões de arquivo para editá-lo).

A parte relevante da manpage ( man ssh )

 ~/.ssh/id_rsa
         Contains the private key for authentication.  These files contain sensitive 
         data and should be readable by the user but not
         accessible by others (read/write/execute).  ssh will simply ignore a private 
         key file if it is              
         accessible by others.  It is possible to specify a
         passphrase when generating the key which will be used to encrypt the sensitive 
         part of this file using 3DES.

 ~/.ssh/identity.pub
 ~/.ssh/id_dsa.pub
 ~/.ssh/id_ecdsa.pub
 ~/.ssh/id_rsa.pub
         Contains the public key for authentication.  These files are not sensitive and 
         can (but need not) be readable by anyone.

Eu estou usando o VPC no EC2 e estava recebendo as mesmas mensagens de erro. Percebi que estava usando o DNS público. Eu mudei isso para o DNS privado e vola !! funcionou...


Há uma exceção para o requisito de permissões "0x00" em uma chave. Se a chave for de propriedade de raiz e pertencente ao grupo por um grupo com usuários, ela poderá ser "0440" e qualquer usuário desse grupo poderá usar a chave.

Eu acredito que isso funcionará com qualquer permissão no conjunto "0xx0", mas eu não testei todas as combinações com todas as versões. Eu tentei 0660 com 5.3p1-84 no CentOS 6, e o grupo não é o grupo primário do usuário, mas um grupo secundário, e funciona bem.

Isso normalmente não seria feito para a chave pessoal de alguém, mas para uma chave usada para automação, em uma situação em que você não deseja que o aplicativo seja capaz de mexer na chave.

Regras semelhantes se aplicam às restrições do diretório .ssh.


Intersting mensagem aqui. Os Syatems Operacionais são inteligentes o suficiente para negar conexões remotas se sua chave privada estiver aberta demais. Ele entende o risco em que as permissões para o id_rsa estão abertas (leia-se, é editável por qualquer pessoa).

{Um pode ter alterado seu bloqueio primeiro e depois abri-lo com as chaves que ele já tinha. }

cd ~/.ssh
chmod 400 id_rsa

PS:

Ao trabalhar nos vários servidores (não produção), a maioria de nós precisa conectar o servidor remoto com o ssh. Uma boa idéia é ter um código de nível de aplicativo (pode ser java usando jsch) para criar relações de confiança ssh entre servidores. Desta forma, a conexão será sem senha. Incase, o perl é instalado - também é possível usar o módulo ssh da rede.


Para mim (usando o Subsistema Ubuntu para Linux) a mensagem de erro mudou para:

 Permissions 0555 for 'key.pem' are too open

depois de usar o chmod 400. Acontece que usar root como usuário padrão foi o motivo.

Altere isso usando o cmd:

 ubuntu config --default-user your_username


o que funcionou para mim

Usuários de chgrp FOLDER

chmod 600 FOLDER


para Win10 precisa mover sua chave para dir home do usuário para linuxlike so você precisa chmod para 700 como ou 600 etc.