Chiavi host per il supporto di SSH File Transfer Protocol (SFTP) per Archiviazione BLOB di Azure

Questo articolo contiene un elenco di chiavi host valide usate per connettersi a Archiviazione BLOB di Azure dai client SFTP.

L'Archivio BLOB supporta ora il protocollo SFTP (SSH File Transfer Protocol). Questo supporto offre la possibilità di connettersi in modo sicuro all'archiviazione BLOB tramite un endpoint SFTP, consentendo di sfruttare SFTP per l'accesso ai file, il trasferimento di file e la gestione dei file. Per altre informazioni, vedere Supporto SFTP (SSH File Transfer Protocol) per Archiviazione BLOB di Azure.

Quando ci si connette all'archiviazione BLOB usando un client SFTP, potrebbe essere richiesto di considerare attendibile una chiave host. È possibile verificare la chiave host trovando tale chiave nell'elenco presentato in questo articolo.

Domande frequenti

Che cosa sono le chiavi host SSH?

Le chiavi host SSH sono coppie di chiavi pubbliche/private che appartengono ai server SSH e SFTP. Vengono usati dai client per verificare l'identità del server durante la connessione. La chiave privata viene archiviata sul lato server, mentre la chiave pubblica viene presentata al client durante l'operazione di connessione. La maggior parte dei client presenterà all'utente un'opzione per verificare la chiave e accettarla, in modo da consentire la continuazione della connessione.

Altri dettagli sono disponibili qui: SSH Host Key Management Demystified.

Le chiavi host SSH sono diverse dalle chiavi SSH usate per l'accesso?

Sì. Le chiavi host SSH sono coppie di chiavi private/pubbliche separate appartenenti al server. La coppia di chiavi privata/pubblica usata per l'accesso è completamente separata e gestita dall'utente. La rotazione delle chiavi host non ha alcun impatto sulle chiavi SSH dell'utente.

Cosa devono fare i client con le chiavi host?

È consigliabile aggiungere la nuova chiave host all'elenco di host attendibili del client. Si noti che i passaggi per questa azione differiscono in base al client SFTP usato. Questi sono i modi più comuni in cui i client archiviano host attendibili:

• File known_hosts
• Chiave del Registro di sistema di Windows (client specifici di Windows)
• Variabile (client basati su libreria)

known_hosts esempio

Questo file viene spesso archiviato nel percorso locale seguente: ~/.ssh/known_hosts. Il file avrà una riga per host noto e ogni riga può seguire un formato simile al seguente: <server hostname> <algorithm> <host key>.

È probabile che sia già presente una voce per l'account di archiviazione dalla prima volta che ci si è connessi. Una nuova voce può essere aggiunta di seguito con la chiave più recente per la stessa area e algoritmo. Dopo l'aggiunta, l'aspetto Australia Central sarà simile a questo esempio per 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=

La prima voce è per la chiave attualmente usata dal servizio, che scadrà prima. La seconda voce è per la chiave successiva che verrà usata dopo la rotazione. La presenza di entrambe le voci consentirà una transizione uniforme quando si verifica la rotazione.

Esempio di chiave del Registro di sistema

Per un client basato su Windows, ad esempio WinSCP, gli host attendibili vengono archiviati in una chiave del Registro di sistema: HKEY_CURRENT_USER\Software\Martin Prikryl\WinSCP 2\SshHostKeys.

Quando viene presentata una nuova chiave host, WinSCP chiederà di accettare la chiave. È possibile confrontare l'impronta digitale SHA256 con la chiave pertinente nella tabella seguente e accettare se corrisponde. WinSCP aggiungerà quindi la nuova chiave alla cache per il futuro.

Esempio di client di libreria

Per un client basato su libreria, ad esempio SSH.NET, la verifica della chiave host è simile al frammento di codice seguente:

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

Per tenere conto della chiave host successiva, è possibile apportare la modifica seguente:

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

I client possono accettare solo la nuova chiave host alla scadenza di quella precedente?

Sì, ma questa non sarà una transizione senza problemi. Quando la nuova chiave viene presentata per la prima volta, il client può restituire questo tipo di messaggio e disconnettersi:

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

Ciò si verifica perché il client ha solo la chiave precedente in known_hosts, che differisce dalla chiave presentata dal server. La disconnessione avviene come misura di sicurezza. Per connettersi di nuovo, il client dovrà eliminare la voce precedente da known_hosts e quindi riprovare a connettersi. In questo modo il client potrà verificare la chiave host e accettarla:

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 verifica implica il confronto dell'impronta digitale dall'output del client con quello archiviato nella tabella seguente. Se corrispondono, digitare yes per continuare e il client archivierà automaticamente la nuova chiave in known_hosts per il futuro.

Qual è la tempistica per la rotazione delle chiavi?

Quando una chiave host scade, Archiviazione di Azure inizia il processo di rotazione delle chiavi host su tutti gli account di storage. Diversi account di archiviazione sperimenteranno la rotazione delle chiavi in momenti diversi. Tutti gli account di archiviazione dovrebbero vedere le chiavi host ruotate entro diversi mesi.

Quanto tempo richiede la rotazione?

Le rotazioni sono graduali e potrebbero richiedere diverse settimane. Una volta iniziata la rotazione della chiave host per un account di storage, la chiave host vecchia o nuova può essere presentata dal servizio Azure durante questo periodo. Durante la rotazione, i clienti potevano vedere la vecchia chiave host presentata anche dopo che la nuova era stata vista per la prima volta.

È una scadenza rigida?

No. La data di scadenza indica la data in cui Archiviazione di Azure inizierà a ruotare le chiavi host. Se non aggiorni i tuoi clienti prima di questa data, è possibile che tu inizi immediatamente a vedere la nuova chiave host, ma è anche possibile che tu veda ancora la chiave host precedente finché tutte le chiavi host non saranno state ruotate.

Perché le chiavi host scadono?

La rotazione periodica dei segreti è una procedura di sicurezza standard e può contribuire a ridurre i vettori di attacco.

È consigliabile disabilitare la verifica rigorosa della chiave host?

No, non è consigliabile disabilitare la verifica rigorosa della chiave host. La verifica della chiave host presentata durante la connessione alle chiavi host pubblicate qui consente ai client di proteggersi da un potenziale attacco Man-In-The-Middle (MITM).

Chiavi host valide

¹ L'impronta digitale SHA 256 viene usata da Open SSH e WinSCP.

Vedi anche

• Supporto di SSH File Transfer Protocol (SFTP) per Archiviazione BLOB di Azure
• Connettersi ad Archiviazione BLOB di Azure usando il protocollo SSH File Transfer Protocol (SFTP)
• Limitazioni e problemi noti relativi al supporto di SSH File Transfer Protocol (SFTP) per Archiviazione BLOB di Azure
• Considerazioni sulle prestazioni di SSH File Transfer Protocol (SFTP) in Archiviazione BLOB di Azure