Claves de host para la compatibilidad con el protocolo de transferencia de archivos SSH (SFTP) en Azure Blob Storage

Este artículo contiene una lista de claves de host válidas que se usan para conectarse a Azure Blob Storage desde clientes SFTP.

Blob Storage es ahora compatible con el protocolo de transferencia de archivos SSH (SFTP). Esta compatibilidad proporciona la capacidad de conectarse de forma segura a Blob Storage a través de un punto de conexión de SFTP, lo que le permite aprovechar SFTP para obtener acceso a los archivos, la transferencia de archivos y la administración de archivos. Para obtener más información, consulte Compatibilidad con el protocolo de transferencia de archivos SSH (SFTP) para Azure Blob Storage (versión preliminar).

Al conectarse a Blob Storage mediante un cliente de SFTP, es posible que se le pida que confíe en una clave de host. Puede comprobar la clave de host mediante la búsqueda de esa clave en la lista presentada en este artículo.

Preguntas más frecuentes

¿Qué son las claves de host SSH?

Las claves de host SSH son pares de claves públicas y privadas que pertenecen a servidores SSH y SFTP. Los clientes los usan para comprobar la identidad del servidor al conectarse. La clave privada se almacena en el lado servidor, mientras que la clave pública se presenta al cliente durante la operación de conexión. La mayoría de los clientes mostrarán al usuario una opción para comprobar la clave y aceptarla, lo que permitirá que la conexión continúe.

Puede encontrar más detalles aquí: Administración de claves de host SSH Demystified.

¿Las claves de host SSH son diferentes de las claves SSH usadas para el inicio de sesión?

Sí. Las claves de host SSH son pares de claves privadas o públicas independientes que pertenecen al servidor. El par de claves privadas y públicas que se usan para el inicio de sesión es completamente independiente y administrado por el usuario. La rotación de claves de host no afecta a las claves SSH del usuario.

¿Qué deben hacer los clientes con las claves de host?

Se recomienda agregar la nueva clave de host a la lista de hosts de confianza del cliente. Tenga en cuenta que los pasos de esta acción variarán en función del cliente SFTP usado. Estas son las formas más comunes en que los clientes almacenarán hosts de confianza:

• archivo known_hosts
• Clave del Registro de Windows (clientes específicos de Windows)
• Variable (clientes basados en biblioteca)

Ejemplo de known_hosts

Este archivo se almacena a menudo en la siguiente ruta de acceso local: ~/.ssh/known_hosts. El archivo tendrá una línea por host conocido y cada línea puede seguir un formato similar al siguiente: <server hostname> <algorithm> <host key>.

Es probable que ya haya una entrada para la cuenta de almacenamiento desde la primera vez que se haya conectado. Se puede agregar una nueva entrada debajo con la clave más reciente para la misma región y algoritmo. Una vez agregado, tendría un aspecto similar al de este ejemplo para y Australia Centralecdsa-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=

La primera entrada es para la clave usada actualmente por el servicio, que expirará antes. La segunda entrada es para la siguiente clave que se usará después de la rotación. Tener ambas entradas permitirá una transición sin problemas cuando se produzca la rotación.

Ejemplo de clave del Registro

Para un cliente basado en Windows, como WinSCP, los hosts de confianza se almacenan en una clave del Registro: HKEY_CURRENT_USER\Software\Martin Prikryl\WinSCP 2\SshHostKeys.

Cuando se presente una nueva clave de host, WinSCP le pedirá que acepte la clave. Puede comparar la huella digital SHA256 con la clave pertinente de la tabla siguiente y aceptar si coincide. WinSCP agregará la nueva clave a la memoria caché para el futuro.

Ejemplo de cliente de biblioteca

Para un cliente basado en biblioteca, como SSH.NET, la comprobación de claves de host es similar al siguiente fragmento 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 tener en cuenta la siguiente clave de host, se podría realizar el siguiente cambio:

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();
}

¿Los clientes solo pueden aceptar la nueva clave de host cuando expire la antigua?

Sí, pero esto no será una transición sin problemas. Cuando se presenta la nueva clave por primera vez, el cliente puede devolver este tipo de mensaje y 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

Esto sucede porque el cliente solo tiene la clave antigua en known_hosts, que difiere de la clave presentada por el servidor. La desconexión se produce como una medida de seguridad. Para volver a conectarse, el cliente tendrá que eliminar la entrada antigua de known_hosts y, a continuación, intentar conectarse de nuevo. Esto proporcionará al cliente la oportunidad de comprobar la clave de host y aceptarla:

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])?

La comprobación implicaría comparar la huella digital de la salida del cliente con la almacenada en la tabla siguiente. Si coinciden, escriba yes para continuar y el cliente almacenará automáticamente la nueva clave en known_hosts para el futuro.

¿Cuál es el calendario para la rotación de tonalidades?

Cuando una clave de host expira, Azure Storage comienza el proceso de rotar las claves de host entre todas las cuentas de almacenamiento. Diferentes cuentas de almacenamiento experimentarán la rotación de claves en distintos momentos. Todas las cuentas de almacenamiento deberían ver sus claves de host rotadas en un plazo de varios meses.

¿Cuánto tarda la rotación?

Las rotaciones son graduales y pueden durar varias semanas. Una vez que ha comenzado la rotación de la clave de host para una cuenta de almacenamiento, el servicio de Azure puede presentar la clave de host antigua o la nueva. Durante la rotación, los clientes podían ver cómo se presentaba la clave de host antigua incluso después de que se viera la nueva.

¿Es una caducidad estricta?

N.º La fecha de caducidad marca la fecha en que Azure Storage comenzará a rotar las claves de host. Si no actualizas a tus clientes antes de esa fecha, es posible que empieces a ver inmediatamente la nueva clave de host, pero también es posible que sigas viendo la clave de host anterior hasta que todas las claves de host hayan sido rotadas.

¿Por qué expiran las claves de host?

La rotación periódica de secretos es una práctica de seguridad estándar y puede ayudar a reducir los vectores de ataque.

¿Está bien deshabilitar la comprobación estricta de la clave de host?

No, no se recomienda deshabilitar la comprobación estricta de la clave de host. La comprobación de la clave de host presentada durante la conexión con las claves de host publicadas aquí permite a los clientes protegerse de un posible ataque man-in-the-middle (MITM).

Claves de host válidas

¹ La huella digital SHA 256 la usa Open SSH y WinSCP.

Vea también

• Compatibilidad del protocolo de transferencia de archivos SSH (SFTP) con Azure Blob Storage
• Conexión a Azure Blob Storage mediante el protocolo de transferencia de archivos SSH (SFTP)
• Limitaciones y problemas conocidos de la compatibilidad con el Protocolo de transferencia de archivos de SSH (SFTP) en Azure Blob Storage
• Consideraciones de rendimiento del protocolo de transferencia de archivos de SSH (SFTP) en Azure Blob Storage