Como proteger a conexão SFTP nos dois sentidos

Como proteger a conexão SFTP nos dois sentidos

Quero configurar uma conexão SFTP entre meu computador e um servidor.

Gerei um par de chaves no meu computador e escrevi minha chave pública no arquivo "authorized_keys" no servidor. Tenho certeza de que funciona porque quando tento me conectar de um computador que não possui minha chave privada (eu sei, ninguém mais deveria tê-la), uma senha é solicitada.

De acordo comesta imagem, meu servidor é Bob e meu computador é Alice. Quando o servidor está enviando uma mensagem, ele usa minha chave pública para criptografá-la e eu uso minha chave privada para descriptografá-la. Mas se eu enviar uma mensagem para o servidor, ela não será criptografada, certo? Se for, como é criptografado?

Pelo que entendi sobre criptografia assimétrica, se eu quiser criptografar as mensagens que envio, tenho que gerar um par de chaves no servidor e colocar sua chave pública no arquivo “authorized_keys” do meu computador, certo?

Como possoverificarque a conexão está protegida em ambos os sentidos (envio e recebimento)?

Obrigado!

Responder1

Existem duas coisas principais acontecendo nas conexões SSH:

Autenticação e criptografia do servidor

O servidor lhe envia sua chave pública e você deve confiar nela. Você poderia obtê-lo manualmente antes disso e, em um ambiente de segurança ideal, você nunca se conectaria a um servidor SSH ANTES de saber que sua chave pública está correta. É para isso que servem as CAs: elas assinam uma chave pública de servidores. Na maioria dos ambientes SSH você apenas aceita a chave pública do servidor como cliente. Esta é a pergunta inicial "você deseja confiar neste servidor e adicioná-lo à sua lista?"A chave pública do servidor é armazenada em .ssh/known_hosts no cliente em sistemas Linux.

A criptografia real da conexão não é assimétrica. Este é um grande equívoco que muitas pessoas têm sobre a criptografia de chave privada/pública. Seria MUITO lento. O que realmente acontece é que o servidor e o cliente geram um segredo compartilhado (também conhecido como senha longa) que écriptografia simétricapara esta sessão. O cliente e o servidor usam criptografia assimétrica até chegarem a um acordo sobre um segredo compartilhado. Depois disso, eles mudam para a criptografia simétrica com esse segredo compartilhado como chave.

Este tipo de criptografia é o mais comum e denominadocriptografia híbrida, embora quase todo mundo (erroneamente) chame isso de criptografia assimétrica.

Um exemplo de criptografia assimétrica pura e "real" é a criptografia de correio com PGP, porque CADA mensagem é criptografada assimetricamente.

Além disso: O segredo compartilhado não é armazenado permanentemente, a cada nova sessão um novo segredo compartilhado é negociado.

Autenticação de cliente

Isso é uma coisa totalmente diferente, é o que pode ser autenticação baseada em senha e/ou chave. A chave pública do cliente (localizada em ~/.ssh/id_rsa.pub) deve estar presente no arquivo de chaves_autorizadas do servidor (por exemplo, para root: /root/.ssh/authorized_keys). Antes de ssh-copy-idexistirem as pessoas fariam algo como

    cat ~/.ssh/id_rsa.pub | ssh root@server "cat >>  ~/.ssh/authorized_keys"

para anexar sua chave aos servidoresauthorized_keys.

O certificado do cliente NÃO é usado para criptografia, apenas para autenticação.

Edição IMPORTANTE:Tornou a postagem mais clara a respeito ssh-copy-idpara evitar mal-entendidos.

A partir de agora, ssh-copy-idé a melhor maneira de adicionar uma chave pública de cliente a um servidor. Acabei de postar o catmétodo para mostrar quais arquivos são manipulados em ambos os lados para mostrar a conexão entre chaves privadas e públicas e como elas são armazenadas.

Ao usar cat existe o risco de esquecer um ">", por exemplo, o quesubstituirseu arquivo autorizado_keys (no Linux ">>" significa anexar, ">" significa substituir). Seja responsável ao manipular diretamente os arquivos de configuração. Obrigado @Rallph por apontar isso.

Responder2

O servidor possui seu próprio par de chaves. Ao se conectar pela primeira vez a um servidor SSH, você deverá ser avisado pelo seu cliente SSH/SFTP, se você confia na chave de host do servidor (=chave pública).

Somente depois de verificar cuidadosamente se é realmente uma chave pública legítima do servidor, sua conexão estará segura. VermeuartigoOnde obtenho a impressão digital da chave do host SSH para autorizar o servidor?

Observe também que nem o seu par de chaves nem o par de chaves do servidor são realmente usados ​​para criptografar os dados. Isso é muito mais complicado.

Veja também:

informação relacionada