Värdnycklar för SSH File Transfer Protocol (SFTP) stöd för Azure Blob Storage

Den här artikeln innehåller en lista över giltiga värdnycklar som används för att ansluta till Azure Blob Storage från SFTP-klienter.

Blob Storage stöder nu SSH File Transfer Protocol (SFTP). Det här stödet ger möjlighet att på ett säkert sätt ansluta till Blob Storage via en SFTP-slutpunkt, så att du kan använda SFTP för filåtkomst, filöverföring och filhantering. Mer information finns i Stöd för SSH File Transfer Protocol (SFTP) för Azure Blob Storage.

När du ansluter till Blob Storage med hjälp av en SFTP-klient kan du uppmanas att lita på en värdnyckel. Du kan verifiera värdnyckeln genom att hitta nyckeln i listan som visas i den här artikeln.

Vanliga frågor och svar

Vad är SSH-värdnycklar?

SSH-värdnycklar är offentliga/privata nyckelpar som tillhör SSH- och SFTP-servrar. De används av klienter för att verifiera serverns identitet vid anslutning. Den privata nyckeln lagras på serversidan, medan den offentliga nyckeln visas för klienten under anslutningsåtgärden. De flesta klienter visar användaren ett alternativ för att verifiera nyckeln och acceptera den, vilket gör att anslutningen kan fortsätta.

Mer information finns här: SSH Host Key Management Demystified.

Skiljer sig SSH-värdnycklar från de SSH-nycklar som används för inloggning?

Ja. SSH-värdnycklar är separata privata/offentliga nyckelpar som tillhör servern. Det privata/offentliga nyckelpar som används för inloggning är helt separat och hanteras av användaren. Rotation av värdnyckeln påverkar inte användarens SSH-nycklar.

Vad ska klienter göra med värdnycklarna?

Vi rekommenderar att du lägger till den nya värdnyckeln i klientens lista över betrodda värdar. Observera att stegen för den här åtgärden skiljer sig beroende på vilken SFTP-klient som används. Det här är de vanligaste sätten som klienter lagrar betrodda värdar på:

• known_hosts fil
• Windows-registernyckel (Windows-specifika klienter)
• Variabel (biblioteksbaserade klienter)

known_hosts exempel

Den här filen lagras ofta under följande lokala sökväg: ~/.ssh/known_hosts. Filen har en rad per känd värd och varje rad kan följa ett format som liknar detta: <server hostname> <algorithm> <host key>.

Det finns förmodligen redan en post för ditt lagringskonto från första gången du anslöt. En ny post kan läggas till under den med den nyare nyckeln för samma region och algoritm. När det har lagts till skulle det se ut ungefär som i det här exemplet för Australia Central och 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=

Den första posten är för den nyckel som för närvarande används av tjänsten, som upphör att gälla tidigare. Den andra posten är för nästa nyckel som ska användas efter rotation. Att ha båda posterna möjliggör en smidig övergång när rotationen sker.

Exempel på registernyckel

För en Windows-baserad klient, till exempel WinSCP, lagras betrodda värdar i en registernyckel: HKEY_CURRENT_USER\Software\Martin Prikryl\WinSCP 2\SshHostKeys.

När en ny värdnyckel visas uppmanar WinSCP dig att acceptera nyckeln. Du kan jämföra SHA256-fingeravtrycket med relevant nyckel i tabellen nedan och acceptera om det matchar. WinSCP lägger sedan till den nya nyckeln i cacheminnet för framtiden.

Exempel på biblioteksklient

För en biblioteksbaserad klient, till exempel SSH.NET, liknar verifiering av värdnyckel följande kodfragment:

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

För att kunna ta hänsyn till nästa värdnyckel kan följande ändring göras:

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

Kan klienter bara acceptera den nya värdnyckeln när den gamla upphör att gälla?

Ja, men det här blir inte en smidig övergång. När den nya nyckeln först visas kan klienten returnera den här typen av meddelande och koppla från:

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

Detta beror på att klienten bara har den gamla nyckeln i known_hosts, som skiljer sig från nyckeln som presenteras av servern. Frånkopplingen sker som en säkerhetsåtgärd. För att kunna ansluta igen måste klienten ta bort den gamla posten från known_hosts och sedan försöka ansluta igen. Detta ger klienten möjlighet att verifiera värdnyckeln och acceptera den:

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

Verifiering skulle innebära att man jämför fingeravtrycket från klientutdata med det som lagras i tabellen nedan. Om de matchar skriver yes du för att fortsätta och klienten lagrar sedan automatiskt den nya nyckeln i known_hosts framtiden.

Vad är tidsplanen för nyckelrotation?

När en värdnyckel går ut börjar Azure Storage processen att rotera värdnycklar över alla lagringskonton. Olika lagringskonton kommer att uppleva nyckelrotation vid olika tidpunkter. Alla lagringskonton bör få sina värdnycklar roterade inom några månader.

Hur lång tid tar rotationen?

Rotationerna är gradvisa och kan ta flera veckor. När värdnyckelrotation har påbörjats för ett lagringskonto kan antingen den gamla eller nya värdnyckeln presenteras av Azure-tjänsten under denna tid. Under rotationen kunde klienterna se den gamla värdnyckeln presenteras även efter att den nya först har setts.

Är det ett hårt utgångsdatum?

No. Utgångsdatumet markerar det datum då Azure Storage börjar rotera värdnycklar. Om du inte uppdaterar dina klienter före detta datum är det möjligt att du omedelbart börjar se den nya värdnyckeln, men det är också möjligt att du fortfarande ser den tidigare värdnyckeln tills alla värdnycklar har roterats.

Varför upphör värdnycklarna att gälla?

Att regelbundet rotera hemligheter är en standardsäkerhetspraxis och kan bidra till att minska angreppsvektorer.

Är det bra att inaktivera strikt verifiering av värdnyckeln?

Nej, vi rekommenderar inte att du inaktiverar strikt verifiering av värdnyckeln. Genom att verifiera värdnyckeln som visas under anslutningen mot värdnycklarna som publiceras här kan klienter skydda sig mot en potentiell MITM-attack (Man-In-The-Middle).

Giltiga värdnycklar

¹ SHA 256-fingeravtrycket används av Open SSH och WinSCP.

Se även

• Stöd för SSH File Transfer Protocol (SFTP) för Azure Blob Storage
• Ansluta till Azure Blob Storage med SSH File Transfer Protocol (SFTP)
• Begränsningar och kända problem med SFTP-stöd (SSH File Transfer Protocol) för Azure Blob Storage
• Prestandaöverväganden för SSH File Transfer Protocol (SFTP) i Azure Blob Storage