Recentemente li em algum lugar que:
As chaves SSH são para criptografia, enquanto as chaves SFTP são para autenticação.
Considere, temos uma máquina cliente C
e um servidor SFTP S
. Para estabelecer uma conexão SSH (usando chaves públicas/privadas), o cliente cria o par de chaves PU c e PR c . A chave pública PU c é adicionada ao authorized_keys
arquivo no servidor S, e o cliente C usa sua chave privada PR c para estabelecer a conexão.
No entanto, li que para SFTP, o par de chaves é criado no servidor em relação a um usuário e a chave privada é compartilhada com o cliente para que ele autentique a conexão SFTP. Ou seja, o servidor S cria PUs e PRs e a chave privada PRs é fornecida ao cliente C para autenticar sua conexão SFTP. Esse entendimento está correto?
Se sim, entendo que a configuração da conexão SSH ocorre em 3 etapas:
- Verificação do servidor pelo cliente (verificação de chave de host).
- Geração de uma chave de sessão para criptografar toda a comunicação.
- Autenticação do cliente.
Como o cliente autentica sua sessão SFTP (com a chave privada que obteve antes do servidor) na etapa 3?
Não existe "autenticação de chave SFTP", nem existe uma "chave SFTP".
O SFTP sempre usa o SSH padrão como transporte – as diferenças só começam depois que você se autentica com sucesso (o cliente então solicita uma sessão interativa ou uma sessão de subsistema 'sftp'). Em outras palavras, o SFTP funciona exatamente da mesma maneira que o Git-over-SSH ou o Rsync-over-SSH.
Finalmente, as chaves SSH não são usadas para criptografia; todos eles são usados apenas para autenticação (em ambas as direções). Portanto, a frase que você leu e citou é falsa em todos os sentidos possíveis.
Existem , no entanto, dois pares de chaves usados para autenticação – um pertencente ao servidor (criado durante a instalação) cuja chave pública é verificada pelo cliente e outro pertencente ao cliente, cuja chave pública é verificada pelo servidor.
O processo geral para SFTP e SSH interativo é:
known_hosts
. (Os dados assinados incluem a chave de sessão negociada anteriormente e outros parâmetros, evitando ataques MitM.)authorized_keys
. (Nesta fase, os dados são apenas um desafio aleatório.)O cliente pode até abrir várias sessões na mesma conexão - clientes que suportam multiplexação, como OpenSSH ou Tunnelier, permitirão que você autentique apenas uma vez e, em seguida, execute vários shells interativos e/ou transferências SFTP na mesma conexão.
(Além disso, é muito provável que eu esteja misturando a ordem relativa de 'sessões' SSH versus 'canais', mas pelo menos você tem uma ideia aproximada.)
Observe que o cliente na etapa 3 pode se autenticar de outras maneiras (como Kerberos ou uma senha simples) em vez de precisar usar um par de chaves. Isso ainda é exatamente o mesmo para SFTP e SSH interativo.