Clés d’hôte pour la prise en charge du protocole SFTP SSH pour le Stockage Blob Azure (préversion)

Cet article contient une liste de clés d’hôte valides utilisées pour se connecter à Stockage Blob Azure à partir de clients SFTP.

Stockage Blob prend désormais en charge le protocole SFTP. Cette prise en charge permet de se connecter de manière sécurisée à Stockage Blob via un point de terminaison SFTP, ce qui vous permet d’exploiter SFTP pour l’accès aux fichiers, le transfert de fichiers, ainsi que la gestion des fichiers. Pour plus d’informations, consultez Prise en charge du protocole SFTP pour Stockage Blob Azure.

Lorsque vous vous connectez à Stockage Blob à l’aide d’un client SFTP, vous pouvez être invité à approuver une clé d’hôte. Vous pouvez vérifier la clé d’hôte en recherchant cette clé dans la liste présentée dans cet article.

Forum aux questions

Qu’est-ce que les clés d’hôte SSH ?

Les clés hôtes SSH sont des paires de clés publiques/privées qui appartiennent à des serveurs SSH et SFTP. Ils sont utilisés par les clients pour vérifier l’identité du serveur lors de la connexion. La clé privée est stockée côté serveur, tandis que la clé publique est présentée au client pendant l’opération de connexion. La plupart des clients présentent à l’utilisateur une option permettant de vérifier la clé et de l’accepter, ce qui permettra à la connexion de continuer.

Vous trouverez plus d’informations ici : Démystifier la gestion des clés d’hôte SSH.

Les clés d’hôte SSH sont-elles différentes des clés SSH utilisées pour la connexion ?

Oui. Les clés hôtes SSH sont des paires de clés privées/publiques distinctes appartenant au serveur. La paire de clés privée/publique utilisée pour la connexion est complètement distincte et gérée par l’utilisateur. La rotation des clés d’hôte n’a aucun impact sur les clés SSH de l’utilisateur.

Que doivent faire les clients avec les clés hôtes ?

Nous vous recommandons d’ajouter la nouvelle clé hôte à la liste des hôtes approuvés du client. Notez que les étapes de cette action diffèrent en fonction du client SFTP utilisé. Voici les méthodes les plus courantes pour les clients qui stockent les hôtes approuvés :

• Fichier known_hosts
• Clé de Registre Windows (clients spécifiques à Windows)
• Variable (clients basés sur une bibliothèque)

Exemple known_hosts

Ce fichier est souvent stocké sous le chemin local suivant : ~/.ssh/known_hosts. Le fichier aura une ligne par hôte connu et chaque ligne peut suivre un format similaire à ceci : <server hostname> <algorithm> <host key>.

Il existe probablement déjà une entrée pour votre compte de stockage à partir de la première fois que vous avez connecté. Une nouvelle entrée peut être ajoutée ci-dessous avec la clé la plus récente pour la même région et le même algorithme. Une fois ajouté, il ressemblerait à cet exemple pour l’exemple Australia Central et 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=

La première entrée concerne la clé actuellement utilisée par le service, qui expirera plus tôt. La deuxième entrée concerne la clé suivante qui sera utilisée après la rotation. La présence des deux entrées permet une transition fluide lorsque la rotation se produit.

Exemple de clé de Registre

Pour un client Windows tel que WinSCP, les hôtes approuvés sont stockés dans une clé de Registre : HKEY_CURRENT_USER\Software\Martin Prikryl\WinSCP 2\SshHostKeys.

Lorsqu’une nouvelle clé hôte est présentée, WinSCP vous invite à accepter la clé. Vous pouvez comparer l’empreinte digitale SHA256 à la clé appropriée dans le tableau ci-dessous et accepter si elle correspond. WinSCP ajoute ensuite la nouvelle clé au cache pour l’avenir.

Exemple de client de bibliothèque

Pour un client basé sur une bibliothèque, tel que SSH.NET, la vérification de la clé hôte ressemble à l’extrait de code suivant :

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

Pour tenir compte de la clé hôte suivante, la modification suivante peut être apportée :

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

Les clients peuvent-ils simplement accepter la nouvelle clé hôte à l’expiration de l’ancien ?

Oui, mais cela ne sera pas une transition transparente. Lorsque la nouvelle clé est présentée pour la première fois, le client peut retourner ce type de message et se déconnecter :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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

Cela se produit parce que le client a uniquement l’ancienne clé dans known_hosts, qui diffère de la clé présentée par le serveur. La déconnexion se produit en tant que mesure de sécurité. Pour vous reconnecter, le client doit supprimer l’ancienne entrée known_hosts , puis réessayer de vous connecter. Cela permet au client de vérifier la clé hôte et de l’accepter :

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 vérification implique la comparaison de l’empreinte digitale de la sortie du client avec celle stockée dans le tableau ci-dessous. S’ils correspondent, tapez yes pour continuer et le client stocke automatiquement la nouvelle clé à l’avenir known_hosts .

Quel est le calendrier de rotation des clés ?

Lorsqu’une clé hôte expire, stockage Azure commence à faire tourner les clés hôtes sur tous les comptes de stockage. Différents comptes de stockage subiront la rotation des clés à différents moments. Tous les comptes de stockage devraient voir leurs clés d’hôte tournées dans les quelques mois.

Combien de temps prend la rotation ?

Les rotations sont graduelles et peuvent durer plusieurs semaines. Une fois la rotation de la clé hôte commencée pour un compte de stockage, l’ancienne ou la nouvelle clé hôte peuvent être présentées par le service Azure pendant cette période. Pendant la rotation, les clients pouvaient voir l’ancienne clé hôte être présentée même après que la nouvelle ait été vue pour la première fois.

Est-ce une expiration stricte ?

Non. La date d’expiration marque la date à laquelle stockage Azure commencera à faire tourner les clés hôte. Si vous ne mettez pas à jour vos clients avant cette date, il est possible que vous commenciez immédiatement à voir la nouvelle clé hôte, mais il est aussi possible que vous voyiez toujours la clé hôte précédente jusqu’à ce que toutes les clés hôtes aient été tournées.

Pourquoi les clés hôtes expirent-elles ?

La rotation périodique des secrets est une pratique de sécurité standard et peut aider à réduire les vecteurs d’attaque.

Est-il correct de désactiver la vérification stricte de la clé hôte ?

Non, nous vous déconseillons de désactiver la vérification stricte de la clé hôte. La vérification de la clé hôte présentée lors de la connexion aux clés hôtes publiées ici permet aux clients de se protéger contre une attaque mitM (Man-In-The-Middle) potentielle.

Clés d’hôte valides

¹ L’empreinte digitale SHA 256 est utilisée par Open SSH et WinSCP.

Voir aussi

• Prise en charge du protocole SFTP SSH pour Stockage Blob Azure
• Se connecter au Stockage Blob Azure à l’aide du protocole SFTP SSH
• Limitations et problèmes connus avec la prise en charge du protocole SSH SFTP (Secure File Transfer Protocol) dans le service Stockage Blob Azure
• Considérations relatives aux performances du protocole SFTP (SSH File Transfer Protocol) dans le Stockage Blob Azure