Unable to Connect to Public SFTP from Azure Synapse – Linked Service HMAC Error and Python Connection Timeout

Question

Unable to Connect to Public SFTP from Azure Synapse – Linked Service HMAC Error and Python Connection Timeout

Shubhangi Nannware 80

Problem Statement

We have a requirement to read and write data to a cloud/on‑prem SFTP server from Azure Synapse.

The SFTP server (sftpssh.example.com) is a public SFTP server.
We are using Azure Synapse with a Self‑Hosted Integration Runtime (SHIR).

Background and Steps Performed

We initially tried to create an SFTP linked service in Synapse.
During the test connection, we received an error (unfortunately, the exact initial error was not captured).
To rule out network restrictions, we requested the SFTP team to whitelist the Azure SHIR IP.
The SFTP team informed us that since the SFTP is public, they require Azure’s outbound public IP.
As Azure does not have fixed outbound public IPs (except via VPN), we shared the VPN public IP used for outbound connectivity.
The SFTP team has now whitelisted:
- SHIR machine IP - Port 22
- VPN public IP - Port 22

Current Issue – Linked Service

After whitelisting, when testing the Synapse SFTP Linked Service, we consistently get the following error:

Failed to connect to Sftp server 'sftpssh.example.com'. Server HMAC algorithm not found

We shared this error with the SFTP team, but they responded that:

This is their production SFTP
They cannot change any server-side configuration
We should try an alternative workaround

Python Workaround Attempt

As a workaround, our developers tried connecting to the SFTP from Synapse notebooks using Python (Paramiko).

Sample Code Used

SFTP_HOST = "sftpssh.example.com"

SFTP_PORT = 22

username = "hardcoded_username"

password = "hardcoded_password"

import paramiko

transport = paramiko.Transport((SFTP_HOST, SFTP_PORT))

transport.connect(username=username, password=password)

sftp = paramiko.SFTPClient.from_transport(transport)

Network Connectivity Test

import socket

sock = socket.socket()

sock.settimeout(10)

try:

sock.connect((SFTP_HOST, SFTP_PORT))

print("Port reachable ✅")

except Exception as e:

print("Connection failed ❌:", e)

Error Observed

Both approaches fail with:

"Connection Timeout error"

Questions

Azure Synapse Linked Service

What causes the “Server HMAC algorithm not found” error when connecting to SFTP from Azure Synapse?

Is this due to unsupported SSH/HMAC algorithms on Azure’s managed integration runtime?
Are there any workarounds on the Azure side if the SFTP server configuration cannot be changed?

Python / Paramiko Approach

- Is it possible to access a public SFTP server from Azure Synapse notebooks using Python?

   - What are the network prerequisites (VNet integration, NAT Gateway, firewall rules, outbound IPs)?

      - Why would a simple socket connection result in a connection timeout even though IPs and port 22 are whitelisted?

Networking & Architecture

Does Azure Synapse require a NAT Gateway or Azure Firewall for consistent outbound SFTP connectivity?
- Is Self‑Hosted Integration Runtime required for Python-based SFTP access, or does Synapse use different outbound paths?
- Are there any supported architectural patterns for securely connecting Azure Synapse to a production SFTP without changing server-side SSH algorithms?

Any guidance, supported configurations, or recommended best practices would be highly appreciated.

0 comments

2 answers

Your answer

Answer 1

SAI JAGADEESH KUDIPUDI 2,625 Microsoft External Staff Moderator

Hi Shubhangi Nannware,

Thank you for sharing the detailed scenario and your proposed approach—this is very well analyzed. I’ve reviewed your findings against Microsoft guidance, and your understanding is largely correct. Let me validate and clarify what will and will not resolve the issue.

SFTP Linked Service – HMAC Error

The error “Server HMAC algorithm not found” occurs due to a mismatch between the SSH/HMAC algorithms supported by Azure Synapse (via ADF connector) and those enabled on the SFTP server.

Azure SFTP connector supports a fixed set of secure algorithms

There is no option to customize or extend these algorithms

If the server only exposes unsupported HMACs, the connection will fail during handshake

This is a platform limitation, not a configuration issue.

Result: Cannot be fixed from Synapse side

Python / Paramiko Timeout from Synapse

Your observation is correct—Synapse notebooks do not use SHIR.

They run on Azure-managed compute

Outbound traffic uses dynamic IPs

These IPs are different from SHIR or VPN IPs

This is why:

Port 22 appears open from SHIR/VPN
But socket/Paramiko calls from notebook timeout

Result: Not a code issue, but a network path mismatch
3. SHIR (Self-Hosted Integration Runtime)

Provides controlled outbound connectivity

Works well for IP whitelisting scenarios

However:

It still uses the same SFTP connector

So HMAC limitation remains

Result: Fixes network, not HMAC
4. NAT Gateway / Azure Firewall

Ensures static outbound public IP

Recommended for enterprise connectivity

But:

Does not influence SSH negotiation

Result: Fixes IP whitelisting only
5. Intermediate VM / Jump Host (Recommended)

This is the most effective solution in your scenario:

Use an Azure VM or service with custom SSH client (Paramiko/OpenSSH)
Connect to SFTP using supported algorithms
Transfer data to Azure Storage (Blob/ADLS)
Let Synapse consume data from storage

Result: Resolves both HMAC and networking issues
Conclusion

To summarize, your analysis is accurate:

The HMAC error is a product limitation and cannot be resolved from Azure Synapse
The timeout issue is due to Synapse networking behavior, not SFTP availability
Solutions like SHIR or NAT Gateway help partially, but do not address algorithm mismatch

The only fully reliable and supported approach in this scenario is to use an intermediate compute layer (Azure VM or similar) to handle SFTP communication and then integrate with Synapse via Azure Storage.

Microsoft Reference Links

SFTP connector documentation: https://learn.microsoft.com/azure/data-factory/connector-sftp
Troubleshooting SFTP/FTP connectors: https://learn.microsoft.com/azure/data-factory/connector-troubleshoot-ftp-sftp-http
Integration Runtime overview: https://learn.microsoft.com/azure/data-factory/concepts-integration-runtime
Synapse managed VNet behavior: https://learn.microsoft.com/azure/synapse-analytics/security/synapse-workspace-managed-vnet
NAT Gateway for outbound connectivity: https://learn.microsoft.com/azure/virtual-network/nat-gateway/nat-overview

Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.

Please do not forget to "Accept Answer" and "up-vote" wherever the information provided helps you, as this can be beneficial to other community members.

Shubhangi Nannware 80 Reputation points

2026-04-15T06:36:04.24+00:00

Hi Sai, Thank you for recommendation. so for this I'll have to assign public IP to Azure virtual Machine so that it can reach SFTP? or else create NAT gateway? Additionally, I wanted to confirm will Azure logic app work for this?
SAI JAGADEESH KUDIPUDI 2,625 Reputation points Microsoft External Staff Moderator

2026-04-28T13:59:57.0366667+00:00
Hi Shubhangi,

Thanks for the follow-up—these are exactly the right questions to ask at this stage. Let me clarify the options and what would work best in your scenario.

Do you need a Public IP or NAT Gateway for the Azure VM?

Yes—if you introduce an intermediate Azure VM (recommended approach), it must have a stable outbound IP so the SFTP server team can reliably whitelist it.

You have two supported options:

Public IP on the VM (simplest)

Assign a static public IP directly to the VM

Use this IP for SFTP whitelisting

Suitable for straightforward setups

NAT Gateway (recommended for enterprise setups)

Attach the VM to a subnet configured with a NAT Gateway

Provides a fixed outbound IP for all resources in that subnet

More scalable and secure (no inbound exposure required)

If this is a production workload, prefer NAT Gateway to avoid exposing the VM publicly and to centralize outbound control.
2. Will Azure Logic Apps work for this scenario?

It depends on the root issue:

For networking (IP whitelisting): Yes, Logic Apps can work if you use:

Integration Service Environment (ISE), or

VNet integration + NAT Gateway

For HMAC / SSH algorithm mismatch: Logic Apps will NOT resolve this

This is because:

Logic Apps SFTP connector uses the same underlying platform capabilities as Synapse/Data Factory

You cannot customize SSH/HMAC algorithms

Logic Apps may fix networking, but not the HMAC error
3. Why the Azure VM approach works (and is recommended)

Using an Azure VM (or similar compute like Azure Functions with custom code) gives you full control:

You can use:

Python (Paramiko)

OpenSSH You can negotiate compatible algorithms with the SFTP server You bypass the limitation of managed connectors

Typical pattern:

Azure VM connects to SFTP using custom client

Transfers files to:

Azure Blob Storage

Azure Data Lake Storage Synapse reads from storage (native + fully supported)

This approach:

Solves HMAC incompatibility

Solves network/IP whitelisting

Aligns with common enterprise integration patterns

Why your Python test timed out from Synapse

Your observation is correct:

Synapse notebooks run on managed compute

They use dynamic outbound IPs (not SHIR, not VPN IP)

These IPs were not whitelisted

So even though:

SHIR → works at network level

Synapse notebook → fails

This is expected due to different outbound paths

Given the constraints (no changes allowed on SFTP server):

Do not rely on Synapse SFTP connector or Logic Apps for this case

Implement an intermediate compute layer (Azure VM preferred)

Use NAT Gateway (preferred) or static Public IP for outbound control

Transfer data into Azure Storage, then process via Synapse

This is the only reliable and fully supported workaround when SSH algorithm negotiation is the blocker.
Microsoft Documentation References

SFTP connector in Azure Data Factory / Synapse https://learn.microsoft.com/azure/data-factory/connector-sftp

Troubleshoot SFTP/FTP connectors https://learn.microsoft.com/azure/data-factory/connector-troubleshoot-ftp-sftp-http

Integration Runtime overview https://learn.microsoft.com/azure/data-factory/concepts-integration-runtime

Synapse managed virtual network and outbound behavior https://learn.microsoft.com/azure/synapse-analytics/security/synapse-workspace-managed-vnet

NAT Gateway overview https://learn.microsoft.com/azure/virtual-network/nat-gateway/nat-overview

Logic Apps SFTP connector https://learn.microsoft.com/azure/logic-apps/connectors/built-in/reference/sftp/

Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.

Please do not forget to "Accept Answer" and "up-vote" wherever the information provided helps you, as this can be beneficial to other community members.
SAI JAGADEESH KUDIPUDI 2,625 Reputation points Microsoft External Staff Moderator

2026-05-03T09:20:10.86+00:00

Hi Shubhangi Nannware,
Following up to see if the below answer was helpful. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.
Shubhangi Nannware 80 Reputation points

2026-05-03T12:56:40.89+00:00

Hi @SAI JAGADEESH KUDIPUDI , Thank you so much for recommended solution- Virtual Machine, It worked.
SAI JAGADEESH KUDIPUDI 2,625 Reputation points Microsoft External Staff Moderator

2026-05-04T11:20:33.89+00:00

Hi Shubhangi Nannware,
Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.Please do not forget to "Accept Answer" and "up-vote" wherever the information provided helps you, as this can be beneficial to other community members.

Answer 2

The error and behavior are caused by protocol/algorithm incompatibilities on the SFTP side plus incomplete network reachability from the Synapse environment.

1. Cause of “Server HMAC algorithm not found” in Synapse linked service

For Synapse / Azure Data Factory SFTP connectors, the SSH stack only supports a specific set of key‑exchange and related algorithms. When the SFTP server offers only algorithms outside this supported set, the connection fails during SSH negotiation with errors like:

Server HMAC algorithm not found
Failed to negotiate key exchange algorithm

From the documented behavior:

Data Factory / Synapse support a defined list of key‑exchange algorithms such as:
- curve25519-sha256
- ******@libssh.org
- ecdh-sha2-nistp256/384/521
- diffie-hellman-group-exchange-sha256/sha1
- diffie-hellman-group16-sha512
- diffie-hellman-group14-sha256/sha1
- diffie-hellman-group1-sha1

If the SFTP server is hardened to use only algorithms outside this set (or only newer/legacy variants), the Synapse SFTP connector cannot complete the handshake and surfaces an algorithm‑negotiation error.

Because the SFTP team will not change server‑side configuration, there is no Azure‑side switch in the SFTP linked service to override or extend the supported algorithms. The connector’s crypto stack is fixed to the documented set.

2. Workarounds on the Azure side for the linked service

Within the SFTP linked service itself, there is no supported way to:

Add custom SSH/HMAC/KEX algorithms, or
Downgrade/upgrade the connector’s crypto behavior.

The only supported mitigations in the SFTP connector are around:

Correct authentication type (Basic, SshPublicKey, MultiFactor) and credentials.
Correct key format (traditional -----BEGIN RSA PRIVATE KEY-----, not PKCS#8 -----BEGIN ENCRYPTED PRIVATE KEY-----).
Correct host key fingerprint / host key validation.
Throttling / concurrency settings and connection type (SFTP vs FTP) for SftpFailedToConnectToSftpServer scenarios.

For algorithm‑mismatch errors, the supported resolution is to align the SFTP server’s algorithms with the supported list. If that cannot be changed, the built‑in SFTP linked service cannot be made to work against that endpoint.

3. Python / Paramiko from Synapse notebooks

The platform does not document Paramiko‑specific behavior, but the same underlying constraints apply:

If outbound network connectivity from the Synapse compute to sftpssh.example.com:22 is blocked or mis‑routed, even a raw socket.connect will time out.
Whitelisting the SHIR IP and VPN IP only affects traffic that actually egresses via SHIR or that VPN. Synapse Spark / notebook compute has its own outbound path; it does not automatically use SHIR.

Therefore, a timeout from socket.connect((SFTP_HOST, 22)) indicates:

The Synapse notebook’s outbound IPs are not whitelisted on the SFTP side, or
There is an intermediate firewall/NVA blocking the traffic, or
The SFTP server is not reachable from the Synapse subnet/VNet being used.

There is no indication in the provided documentation that Python‑based SFTP from Synapse can bypass the algorithm limitations of the managed SFTP connector. Even if Paramiko supports more algorithms, the fundamental requirement is:

The Synapse compute subnet’s outbound IPs must be allowed on the SFTP server.

4. Network prerequisites and architecture

From the SFTP connector and troubleshooting guidance:

For public SFTP endpoints, either:
- Use Azure Integration Runtime and allow the documented Azure IR IP ranges on the SFTP server, or
- Use Self‑Hosted IR and allow the SHIR machine’s public IP.
If the SFTP server throttles or limits connections, reduce concurrent connections to 1 in the SFTP dataset and retry.
Ensure the correct connection type is used (SFTP connector, not FTP) and that port 22 is open.

For Fabric Data Factory / Data Factory, the guidance is analogous:

If using On‑Premises Data Gateway (or SHIR), its IP must be allow‑listed.
Only Basic authentication is supported in some Fabric SFTP scenarios.

Regarding NAT Gateway / Azure Firewall:

The documentation does not require a NAT Gateway or Azure Firewall for SFTP; they are optional tools to provide stable outbound IPs.
What matters is that the outbound IPs actually used by the runtime (Azure IR, SHIR, or Synapse compute) are allowed on the SFTP server.

5. Self‑Hosted IR vs notebooks for SFTP

The SFTP linked service uses the configured Integration Runtime:
- Azure IR by default, or
- Self‑Hosted IR if connectVia is set to that IR.
Synapse notebooks (Spark pools) do not route traffic through SHIR; they use the network path of the Synapse workspace / managed VNet.

Therefore:

SHIR is required only for SFTP copy activities that explicitly use it.
SHIR does not affect Python/Paramiko traffic from notebooks unless a separate proxy or tunnel is configured at the OS/network level.

6. Supported patterns for production SFTP connectivity

From the available documentation, the supported patterns are:

Use the SFTP connector with a compatible SFTP server
- Ensure the SFTP server supports the documented key‑exchange algorithms.
- Ensure the correct authentication type and key format.
- Allow the Azure IR IP ranges or SHIR IP on port 22.
Use Self‑Hosted IR for tighter IP control
- Place SHIR on a controlled host with a static public IP.
- Allow that IP on the SFTP server.

If the SFTP server’s SSH algorithms cannot be aligned with the supported list, there is no documented, supported way to make the Synapse / Data Factory SFTP connector work against it.

References:

Share via

Unable to Connect to Public SFTP from Azure Synapse – Linked Service HMAC Error and Python Connection Timeout

Problem Statement

Background and Steps Performed

Current Issue – Linked Service

Python Workaround Attempt

Sample Code Used

Error Observed

Questions

2 answers

1. Cause of “Server HMAC algorithm not found” in Synapse linked service

2. Workarounds on the Azure side for the linked service

3. Python / Paramiko from Synapse notebooks

4. Network prerequisites and architecture

5. Self‑Hosted IR vs notebooks for SFTP

6. Supported patterns for production SFTP connectivity

Your answer