[Azure Service Health] ActionRequired:Update host keys to use SFTP on Azure Blob Storage

Hello Prasad Atmaram Mali

here’s how you can find out which of your storage accounts have SFTP turned on, and what to do once you’ve spotted them.

Identify SFTP-enabled accounts via command prompts:

az storage account list \ --query "[?enableSftp==\`true\`].{Name:name,RG:resourceGroup,Sku:sku.name}" \ -o table

Get-AzStorageAccount | Where-Object EnableSftp -EQ $true |Select-Object ResourceGroupName, StorageAccountName, SkuName

• Go to Storage accounts > use the filter on the top bar > choose Secure transfer or open each account’s SFTP blade to see if it’s enabled.

Next steps to resolve or change SFTP settings please Verify prerequisites

1. Storage account must be GPv2 or Premium Block Blob.
2. Hierarchical namespace (ADLS Gen2) must be enabled.
3. No blobs in a soft-deleted state if you’re upgrading.
4. Firewall/network rules allow outbound traffic on port 22.

Please Refer this Microsoft docs

How to Enable SFTP on a storage account (CLI/PowerShell/ARM)

Prerequisites for SFTP support

How to Configure SFTP user permissions

Host keys for SSH File Transfer Protocol (SFTP) support

I hope this has been helpful!

If the above is unclear or you are unsure about something, please add a comment below.

If these answer your question, click "Upvote" and click "Accept Answer" which may be beneficial to other community members reading this thread.

Azure Service Health is notifying that SFTP host keys for Azure Blob Storage are rotating and that any SFTP clients must trust the new host keys. Resolution has two parts:

1. Identify which storage accounts have SFTP enabled.
2. Update SFTP clients with the new host keys for the regions used by those accounts.

1. Identify storage accounts with SFTP enabled

Use the Azure Portal or automation (PowerShell/CLI/Policy) to list storage accounts and check the SFTP setting:

• In the Azure Portal, for each storage account:
  • Go to the storage account.
  • Open the SFTP configuration blade (under Data transfer or Settings, depending on UI).
  • If SFTP is enabled and local users are configured, that account is in scope.

(If using automation, query the storage account’s SFTP configuration property across subscriptions and resource groups and filter where SFTP is enabled.)

2. Determine which host keys apply

For each SFTP-enabled storage account, note its region (for example, East US, West US 2). Then look up the valid host keys for that region in the published host key list.

The host key list provides, per region:

• Host key type (for example, ecdsa-sha2-nistp256)
• Expiration date
• SHA-256 fingerprint
• Public key

Example entries from the list:

• East US:
  • ecdsa-sha2-nistp256, expires 2026-04-30, fingerprint eMxQHe6f1/jYEKvKWMYQ28EUYrSF5e/km5Nw9mNY9Lc=
  • ecdsa-sha2-nistp256, expires 2028-01-31, fingerprint 4+nbdL+SufuAtC5yOB5w54AJi0CkR1M6QyltDFhU/tU=
• West US 2:
  • ecdsa-sha2-nistp256, expires 2026-04-30, fingerprint 68JQ/P3TUrEAk2hMHXUF12kiH+J1s4wNbw2QsGHiX6g=
  • ecdsa-sha2-nistp256, expires 2028-01-31, fingerprint mWH/385GvOa8Sn7sb8S2QVfFjeqD3+ttzzLsl6teGhs=

All host keys that previously had an expiration date of 2026-01-31 have been extended to 2026-04-30.

3. Update SFTP clients with new host keys

For each SFTP client that connects to those storage accounts:

1. Connect once and capture the host key fingerprint the client shows.
2. Compare it to the SHA-256 fingerprint for the correct region and algorithm in the host key list.
3. If it matches, accept the key and store it as trusted.

How to store trusted host keys depends on the client:

• OpenSSH / most Unix clients: use ~/.ssh/known_hosts.
  • Each line typically looks like:
    • <account>.blob.core.windows.net ecdsa-sha2-nistp256 <host-key>
  • To support rotation seamlessly, add both the current and next host key for the same region and algorithm as separate lines. Example pattern:
    • First line: current key (earlier expiration)
    • Second line: next key (later expiration)
• Windows GUI clients (for example, WinSCP):
  • Trusted host keys are stored in the registry, for example:
    • HKEY_CURRENT_USER\Software\Martin Prikryl\WinSCP 2\SshHostKeys
  • When prompted with a new host key, compare the SHA-256 fingerprint with the published value for the region. If it matches, accept it so the client caches it.
• Library-based clients (for example, SSH.NET, paramiko, etc.):
  • Implement host key verification using the published fingerprints or public keys.
  • Update the verification logic to accept both the current and next host key so rotation is seamless.

4. Avoid disabling strict host key checking

Do not disable strict host key verification. Verifying the host key against the published list protects against man-in-the-middle attacks.

If strict checking remains enabled but only the old key is in the client cache, once rotation happens the client may disconnect with a host key mismatch. In that case, either:

• Add the new key in advance (recommended), or
• Remove the old entry from the client’s cache (for example, from known_hosts), reconnect, verify the new fingerprint against the list, and accept it.

5. Completion criteria

The issue is considered resolved when:

• All storage accounts with SFTP enabled are identified.
• For each region used by those accounts, SFTP clients have both the current and next host keys configured as trusted, or at least the new key is trusted.
• Clients can connect via SFTP without host key mismatch warnings after rotation.

References:

• SSH File Transfer Protocol (SFTP) support for Azure Blob Storage
• Host keys for SSH File Transfer Protocol (SFTP) support for Azure Blob Storage