Chaves de Host para suporte ao SFTP (Protocolo FTP SSH) no Armazenamento de Blobs do Azure

Este artigo contém uma lista de chaves de host válidas usadas para se conectar ao Armazenamento de Blobs do Azure de clientes SFTP.

O Armazenamento de blobs agora dá suporte ao SFTP (Protocolo FTP SSH). Este suporte possibilita a conexão segura ao Armazenamento de Blobs do Azure por meio de um ponto de extremidade SFTP, permitindo que você use o SFTP para acessar, transferir e gerenciar arquivos. Para obter mais informações, confira Suporte ao protocolo SFTP (Protocolo FTP SSH) no Armazenamento de Blobs do Azure.

Quando você se conectar ao Armazenamento de Blob usando um cliente SFTP, você pode ser solicitado a confiar em uma chave de host. Você pode verificar a chave do host encontrando essa chave na lista apresentada neste artigo.

Perguntas frequentes

O que são chaves de host SSH?

As chaves de host SSH são pares de chaves públicas/privadas que pertencem aos servidores SSH e SFTP. Eles são usados pelos clientes para verificar a identidade do servidor ao se conectar. A chave privada é armazenada no lado do servidor, enquanto a chave pública é apresentada ao cliente durante a operação de conexão. A maioria dos clientes apresentará ao usuário uma opção para verificar a chave e aceitá-la, o que permitirá que a conexão continue.

Mais detalhes podem ser encontrados aqui: Gerenciamento de chaves de host SSH desmistificado.

As chaves de host SSH são diferentes das chaves SSH usadas para login?

Sim. As chaves de host SSH são pares de chaves privadas/públicas separadas pertencentes ao servidor. O par de chaves privada/pública usado para login é completamente separado e gerenciado pelo usuário. A rotação de chaves do host não tem impacto nas chaves SSH do usuário.

O que os clientes devem fazer com as chaves de host?

Recomendamos adicionar a nova chave de host à lista de hosts confiáveis do cliente. Observe que as etapas para essa ação serão diferentes com base no cliente SFTP usado. Estas são as maneiras mais comuns pelas quais os clientes armazenam hosts confiáveis:

• Arquivo known_hosts
• Chave de registro do Windows (clientes específicos do Windows)
• Variável (clientes baseados em biblioteca)

Exemplo do known_hosts

Esse arquivo geralmente é armazenado no seguinte caminho local: ~/.ssh/known_hosts. O arquivo terá uma linha por host conhecido e cada linha pode seguir um formato semelhante a este: <server hostname> <algorithm> <host key>.

Provavelmente já existe uma entrada para sua conta de armazenamento desde a primeira vez que você se conectou. Uma nova entrada pode ser adicionada abaixo dela com a chave mais recente para a mesma região e algoritmo. Uma vez adicionado, seria semelhante a este exemplo para o Australia Central e ecdsa-sha2-nistp256:

<account>.blob.core.windows.net ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBElXRuNJbnDPWZF84vNtTjt4I/842dWBPvPi2fkgOV//2e/Y9gh0koVVAYp6MotNodg4L9MS7IfV9nnFSKaJW3o=

<account>.blob.core.windows.net ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBLs9yqrEGdGvgdSWkAK5YkyazMWi30X+E6J/CiGpJwbuczVJwT/cwh+mxnE7DMTwhEo57jL7/wi/WT8CPfPpD4I=

A primeira entrada é para a chave atualmente usada pelo serviço, que expirará mais cedo. A segunda entrada é para a próxima chave que será usada após a rotação. Ter ambas as entradas permitirá uma transição suave quando a rotação ocorrer.

Exemplo de chave do Registro

Para um cliente baseado em Windows, como o WinSCP, os hosts confiáveis são armazenados em uma chave do Registro: HKEY_CURRENT_USER\Software\Martin Prikryl\WinSCP 2\SshHostKeys.

Quando uma nova chave de host é apresentada, o WinSCP solicitará que você aceite a chave. Você pode comparar a impressão digital SHA256 com a chave relevante na tabela abaixo e aceitar se ela corresponder. O WinSCP adicionará a nova chave ao cache para o futuro.

Exemplo de cliente de biblioteca

Para um cliente baseado em biblioteca, como o SSH.NET, a verificação da chave do host é semelhante ao seguinte snippet de código:

string expectedFingerPrint = "m2HCt3ESvMLlVBMwuo9jsQd9hJzPc/fe0WOJcoqO3RA=";

using (var client = new SshClient("<account>.blob.core.windows.net", "<account>.<user>", "<pwd>"))
{
    client.HostKeyReceived += (sender, e) =>
        {
            e.CanTrust = expectedFingerPrint.Equals(e.FingerPrintSHA256);
        };
    client.Connect();
}

Para levar em conta a próxima chave de host, a seguinte alteração pode ser feita:

List<string> expectedFingerPrints = new List<string>() { "m2HCt3ESvMLlVBMwuo9jsQd9hJzPc/fe0WOJcoqO3RA=", "5Vot7f2reXMzE6IR9GKiDCOz/bNf3lA0qYnBQzRgObo=" };

using (var client = new SshClient("<account>.blob.core.windows.net", "<account>.<user>", "<pwd>"))
{
    client.HostKeyReceived += (sender, e) =>
        {
            e.CanTrust = expectedFingerPrints.Contains(e.FingerPrintSHA256);
        };
    client.Connect();
}

Os clientes podem simplesmente aceitar a nova chave de host quando a antiga expirar?

Sim, mas esta não será uma transição perfeita. Quando a nova chave é apresentada pela primeira vez, o cliente pode retornar esse tipo de mensagem e se desconectar:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:Q3zIFfOI1UfCrMq6Eh7nP1/VIvgPn3QluTBkyZ2lfCw.
Please contact your system administrator.
Add correct host key in C:\\Users\\<user>/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in C:\\Users\\<user>/.ssh/known_hosts:8
Host key for <account>.blob.core.windows.net has changed and you have requested strict checking.
Host key verification failed.
Connection closed

Isso acontece porque o cliente só tem a chave antiga em known_hosts, que difere da chave apresentada pelo servidor. A desconexão acontece como medida de segurança. Para se conectar novamente, o cliente precisará excluir a entrada antiga e known_hosts tentar se conectar novamente. Isso dará ao cliente a oportunidade de verificar a chave de host e aceitá-la:

The authenticity of host 'blob.cbn06prdstr01a.store.core.windows.net' can't be established.
ECDSA key fingerprint is SHA256:Q3zIFfOI1UfCrMq6Eh7nP1/VIvgPn3QluTBkyZ2lfCw.
This host key is known by the following other names/addresses:
    C:\Users\<user>/.ssh/known_hosts:12: blob.cbn06prdstr01a.store.core.windows.net
Are you sure you want to continue connecting (yes/no/[fingerprint])?

A verificação envolveria a comparação da impressão digital da saída do cliente com a armazenada na tabela abaixo. Se eles corresponderem, digite yes para continuar e o cliente armazenará automaticamente a nova chave no known_hosts futuro.

Qual é o cronograma para a rotação de chaves?

Quando uma chave de host expira, o Armazenamento do Azure inicia o processo de rotação das chaves de host entre todas as contas de armazenamento. Diferentes contas de armazenamento passarão pela rotação de chaves em momentos distintos. Todas as contas de armazenamento devem ter suas chaves de host rotacionadas em alguns meses.

Quanto tempo leva a rotação?

As rotações são graduais e podem levar várias semanas. Uma vez iniciada a rotação da chave de host para uma conta de armazenamento, tanto a chave antiga quanto a nova pode ser apresentada pelo serviço Azure durante esse período. Durante a rotação, os clientes podiam ver a chave de host antiga sendo apresentada mesmo depois que a nova era vista pela primeira vez.

É uma expiração rígida?

Não. A data de expiração marca a data em que o Armazenamento do Azure começará a rodar as chaves do host. Se você não atualizar seus clientes antes dessa data, é possível que comece imediatamente a ver a nova chave host, mas também é possível que ainda veja a chave host anterior até que todas as chaves de host tenham sido rotacionadas.

Por que as chaves de host expiram?

A rotação periódica de segredos é uma prática de segurança padrão e pode ajudar a reduzir os vetores de ataque.

É correto desabilitar a verificação estrita da chave do host?

Não, não recomendamos desabilitar a verificação estrita da chave do host. A verificação da chave de host apresentada durante a conexão em relação às chaves de host publicadas aqui permite que os clientes se protejam de um possível ataque Man-In-The-Middle (MITM).

Chaves de host válidas

¹ A impressão digital SHA 256 é usada pelo Open SSH e WinSCP.

Confira também

• Suporte ao SFTP (protocolo FTP SSH) para Armazenamento de Blobs do Azure
• Conectar-se ao Armazenamento de Blobs do Azure usando o SFTP (protocolo FTP SSH)
• Limitações e problemas conhecidos com o suporte para protocolo SFTP SSH no Armazenamento de Blobs do Azure
• Considerações sobre desempenho do protocolo SFTP do SSH no Armazenamento de Blobs do Azure