SVN + SSH No Ubuntu: Bloqueando a segurança - Senhas

1

Bom dia,

Eu configurei um servidor rodando o Ubuntu 12.04 LTS. Deixei a porta SSH padrão como está por enquanto e configurei uma conta DynDNS.org.

De uma máquina executando Linux, em uma rede separada, posso consultar meu servidor via SVN + SSH:

svn --username myName ls svn+ssh://[email protected]/usr/local/svn/repos/private

Até aqui tudo bem: eu sou questionado pela senha do usuário, e um par de chave privada / pública SSH parece ser gerado. No entanto, estou preocupado.

Eu achei que o ponto das chaves privadas / públicas era que eu teria que fornecer ao cliente a chave apropriada com antecedência. Eu quero bloquear este servidor para que as pessoas se conectando ao meu servidor SVN tenham tanto um arquivo de chaves que eu dei a eles com antecedência, quanto a senha para o usuário "myName". Tem algo que estou perdendo? Neste ponto, tudo que alguém parece precisar é o URL para o meu servidor SVN e a senha para o usuário "myName", e eles estão em.

Como posso bloquear isso com mais força?

Obrigado!

    
por DevNull 29.09.2013 / 04:28

1 resposta

2

No SSH, autenticação de chave pública e autenticação de senha (ou autenticação interativa de teclado) são coisas separadas. Você pode usar o PAM, senhas ou chaves públicas (ou qualquer um dos outros recursos disponíveis, como o kerberos GSSAPI). Qual deles é usado é negociado entre o cliente e o servidor com base nos recursos.

Por causa disso, você não pode exigir uma chave pública e uma senha; você deve usar qualquer um. A chave também está vinculada a um usuário específico por natureza, é claro. Teoricamente, você poderia fazer isso com o PAM, mas como não é um cliente SSH, ele suportaria isso.

Se me lembro, você pode criptografar as chaves, para que um usuário precise de uma senha para descriptografá-las, mas o usuário pode descriptografar a chave com o openssl e armazená-la descriptografada para evitar digitar a senha (se você estiver preocupado com elas ser roubado), e se você está realmente preocupado com o fato de eles estarem rachados, o atacante pode fazer o mesmo, quer tenha fornecido a chave privada para o usuário criptografado ou não (mas isso é muito, muito difícil de ser feito). / p>

O outro aspecto disso é a impressão digital do servidor, que você deve publicar de maneira otimizada antecipadamente, fornecendo-a ao cliente ou usando o SSHFP RRtype no DNS. Isso permite que o cliente verifique se está conectando ao servidor correto e é validado, independentemente do mecanismo de autenticação usado. Isso é sempre importante, embora seja mais importante com a autenticação por senha e interativa por teclado (para impedir que as credenciais sejam roubadas).

    
por 29.09.2013 / 04:52