Práticas recomendadas para .ssh? Devo estar desabilitando todos os acessos root e senha do usuário, ponto final?

0

Eu sou novo nisso, então, por favor, mude isso um pouco para mim.

Eu uso o OSX localmente, servidor Ubuntu para meu host remoto no Linode. E, no meu entender, posso usar ssh-keygen -b 4096 localmente para gerar dois arquivos:

~/.ssh/id_rsa e ~/.ssh/id_rsa.pub

E, no meu servidor, eu corro mkdir -p ~/.ssh && sudo chmod -R 700 ~/.ssh/ para criar a pasta .ssh e dar privilégios recursivos de leitura / gravação / execução para o "proprietário do arquivo" (seja lá o que for, de acordo com o chmod wiki).

Então eu chamo

scp ~/.ssh/id_rsa.pub [email protected]:~/.ssh/authorized_keys

Que eu acho que usa o protocolo ssh para carregar a chave pública para o servidor em um arquivo authorized_key recém-criado na pasta .ssh do servidor que acabei de criar.

Suponho que isso significa que o arquivo público vai para o servidor, enquanto o arquivo público e o arquivo privado residem em minha máquina local.

Agora digamos que eu edite meu arquivo /etc/ssh/sshd_config , no qual posso mexer com PermitRootLogin , PasswordAuthentication e ChallengeResponseAuthentication .

Minhas perguntas:

  1. Devo estar desabilitando o login do root? Devo definir PermitRootLogin para no ou without-password ? Devo estar desabilitando todas as senhas e usando apenas as chaves, ponto final? Que tal PasswordAuthentication e ChallengeResponseAuthentication ?

  2. É seguro ter os arquivos de chave privada e pública na minha máquina local? Devo estar excluindo o público e apenas segurando o privado?

  3. Se eu estou confiando apenas na chave, isso não significa que estou agora exposto a uma nova fraqueza: alguém entrando na minha máquina e, portanto, obtendo acesso ao meu arquivo de chave?

por user712268 14.07.2017 / 03:25

2 respostas

1

A "melhor prática" com o ssh, ou qualquer outro servidor, é:

  1. Avalie o valor do seu ativo e os dados no seu servidor onde você instala e configura o ssh. Isto é um computador doméstico atrás de uma lan? Ou um endereço IP público em um servidor com dados confidenciais, informações privadas, informações financeiras? etc.

  2. Leia TODAS as opções de segurança.

  3. Em seguida, decida como deseja equilibrar a segurança com facilidade de acesso, facilidade de configuração e valor dos seus recursos.

Para minhas considerações sobre o ssh, consulte link

    
por Panther 14.07.2017 / 03:59
0
% bl0ck_qu0te%

A chave pública pode ser derivada da chave privada (mas não o contrário). Como eu recupero a chave pública de uma chave privada SSH? A chave pública é fornecida meramente como uma questão de conveniência para que você não precisa gerá-lo toda vez que precisar adicionar sua chave a um novo servidor.

% bl0ck_qu0te%

É por isso que você não pressiona cegamente Enter ao executar ssh-keygen e usa uma senha strong (claro, diferente da senha do usuário) para criptografar sua chave.

% bl0ck_qu0te%

Ele é efetivamente desativado por padrão, já que os padrões permitem apenas login baseado em chave, e a raiz não tem authorized_keys por padrão.

% bl0ck_qu0te%

Está definido para without-password porque é um padrão seguro. Você pode configurá-lo para no , se desejar. No entanto, se você precisar de rsync / scp como root, você terá problemas.

% bl0ck_qu0te%

Se você conseguir seguir essa política, use apenas as chaves e desative as duas.

    
por muru 14.07.2017 / 03:43