AVISO: ARQUIVO CHAVE PRIVADO NÃO PROTEGIDO! ao tentar fazer o SSH na instância do Amazon EC2

Estou trabalhando para configurar o Panda em uma instância do Amazon EC2. Eu configurei minha conta e ferramentas ontem à noite e não tive nenhum problema ao usar o SSH para interagir com minha própria instância pessoal, mas agora não estou recebendo permissão para entrar na instância do EC2 do Panda. Introdução ao Panda

Estou recebendo o seguinte erro:

@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @

Permissions 0644 for '~/.ec2/id_rsa-gsg-keypair' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

Eu modifiquei meu par de chaves para 600 para entrar na minha instância pessoal ontem à noite e experimentei por muito tempo definindo as permissões como 0 e até gerando novas cadeias de teclas, mas nada parece estar funcionando.

Qualquer ajuda seria uma grande ajuda!

Hm, parece que, a menos que as permissões sejam definidas como 777 no diretório, o script ec2-run-instance não consegue encontrar meus arquivos-chave. Eu sou novo no SSH, então posso estar negligenciando algo.

Eu mudei meu par de chaves para 600 para entrar na minha instância pessoal ontem à noite,

E é assim que deve ser.

Na documentação do EC2 , temos "Se você estiver usando o OpenSSH (ou qualquer cliente SSH razoavelmente paranóico), provavelmente precisará definir as permissões desse arquivo para que seja legível por você". A documentação do Panda que você vincula aos links da documentação da Amazon, mas realmente não transmite a importância de tudo isso.

A idéia é que os arquivos do par de chaves sejam como senhas e precisem ser protegidos. Portanto, o cliente ssh que você está usando exige que esses arquivos sejam protegidos e que somente sua conta possa lê-los.

Definir o diretório para 700 realmente deve ser suficiente, mas o 777 não será prejudicial enquanto os arquivos forem 600.

Quaisquer problemas que você está enfrentando são do lado do cliente, portanto, inclua informações do SO local com todas as perguntas de acompanhamento!

Verifique se o diretório que contém os arquivos de chave privada está definido como 700

chmod 700 ~/.ec2

Para corrigir isso, 1) você precisará redefinir as permissões para o padrão:

sudo chmod 600 ~/.ssh/id_rsa sudo chmod 600 ~/.ssh/id_rsa.pub

Se você estiver recebendo outro erro: Tem certeza de que deseja continuar se conectando (sim / não)? yes Falha ao adicionar o host à lista de hosts conhecidos (/home/geek/.ssh/known_hosts).

2) Isso significa que as permissões nesse arquivo também estão definidas incorretamente e podem ser ajustadas com isso:

sudo chmod 644 ~/.ssh/known_hosts

3) Por fim, também pode ser necessário ajustar as permissões do diretório:

sudo chmod 755 ~/.ssh

Isso deve fazer você voltar a funcionar.

O arquivo de chave privada deve ser protegido. No meu caso, eu uso a autenticação public_key há muito tempo e costumava definir a permissão como 600 (rw- --- ---) para chave privada e 644 (rw- r-- r--) e para a pasta .ssh na pasta inicial, você terá 700 permissões (rwx --- ---). Para definir isso, vá para a pasta inicial do usuário e execute o seguinte comando

Defina a permissão 700 para a pasta .ssh

chmod 700 .ssh

Defina a permissão 600 para o arquivo de chave privada

chmod 600 .ssh/id_rsa

Definir permissão 644 para arquivo de chave pública

chmod 644 .ssh/id_rsa.pub

Também tive o mesmo problema, mas o corrigi alterando minha permissão de arquivo de chave para 600.

sudo chmod 600 /path/to/my/key.pem

Link: http://stackabuse.com/how-to-fix-warning-unprotected-private-key-file-on-mac-and-linux/

Mantenha sua chave privada, chave pública, known_hosts no mesmo diretório e tente fazer o login como abaixo:

ssh -I(small i) "hi.pem" ec2-user@ec2-**-***-**-***.us-west-2.compute.amazonaws.com

• O mesmo diretório no sentido cd /Users/prince/Desktop,. Agora digite lscommand e você deverá ver **.pem **.ppk known_hosts

Nota: Você deve tentar fazer login no mesmo diretório ou obterá um erro de permissão negada, pois não consegue encontrar o arquivo .pem no seu diretório atual.

Se você deseja SSH a partir de qualquer diretório, pode adicionar o seguinte a você ~/.ssh/config arquivo ...

Host your.server
HostName ec2-user@ec2-**-***-**-***.us-west-2.compute.amazonaws.com
User ec2-user
IdentityFile ~/.ec2/id_rsa-gsg-keypair
IdentitiesOnly yes

Agora você pode fazer o SSH para o servidor, independentemente de onde o diretório esteja, simplesmente digitando ssh your.server(ou qualquer nome que você colocar após "Host").

No Windows, tente usar o git bash e use os comandos do Linux lá. Abordagem fácil

chmod 400 *****.pem

ssh -i "******.pem" ubuntu@ec2-11-111-111-111.us-east-2.compute.amazonaws.com

Alterar a permissão de arquivo usando o comando chmod

sudo chmod 700 keyfile.pem

Estou pensando em outra coisa, se você está tentando fazer login com um nome de usuário diferente que não existe, esta é a mensagem que você receberá.

Portanto, suponho que você esteja tentando fazer o ssh com o usuário ec2, mas eu lembro recentemente que a maioria das AMIs do centos, por exemplo, está usando o usuário centos em vez do usuário ec2

portanto, se estiver ssh -i file.pem centos@public_IP, me diga que você deseja usar o ssh com o nome de usuário correto, caso contrário, esse pode ser um forte motivo para você ver essa mensagem de erro, mesmo com as permissões corretas em seu ~ / .ssh / id_rsa ou file.pem

Apenas uma nota para quem se deparar com isso:

Se você está tentando fazer o SSH com uma chave que foi compartilhada com você, por exemplo:

ssh -i /path/to/keyfile.pem user@some-host

Onde keyfile.pema chave pública / privada é compartilhada com você e você a está usando para se conectar, salve-a no ~/.ssh/e chmod 777.

Tentar usar o arquivo quando ele foi salvo em outro lugar na minha máquina estava causando o erro do OP. Não tenho certeza se está diretamente relacionado.

A solução é torná-lo legível apenas pelo proprietário do arquivo, ou seja, os dois últimos dígitos da representação do modo octal devem ser zero (por exemplo, modo 0400).

O OpenSSH verifica isso authfile.cem uma função chamada sshkey_perm_ok:

/*
 * if a key owned by the user is accessed, then we check the
 * permissions of the file. if the key owned by a different user,
 * then we don't care.
 */
if ((st.st_uid == getuid()) && (st.st_mode & 077) != 0) {
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @");
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("Permissions 0%3.3o for '%s' are too open.",
        (u_int)st.st_mode & 0777, filename);
    error("It is required that your private key files are NOT accessible by others.");
    error("This private key will be ignored.");
    return SSH_ERR_KEY_BAD_PERMISSIONS;
}

Veja a primeira linha após o comentário: ele faz um "bit a bit e" no modo do arquivo, selecionando todos os bits nos dois últimos dígitos octais (já que 07é octal 0b111, onde cada bit representa r ​​/ w / x, respectivamente) .