Gateway Connection Details

Updated Jul 26, 2026

Hosted File Gateway

Gateway Connection Details

Everything a partner needs is on one panel at the top of Extensions > File Gateway. Hand them this, not a description of it.

The endpoint panel showing host, ports, passive range and fingerprints, with callouts on which values to pin — Read from the running server, not from configuration — a published fingerprint that does not match the live endpoint is worse than none.

What to send a partner

Value	Notes
Host	A dedicated, permanent IPv4 address. It is what they put in their firewall rules, and it is not released or reallocated.
SFTP port 22	The standard port, so `sftp user@host` works with nothing to explain.
SSH host key fingerprint	They should pin this.
FTPS port 21	Explicit TLS (`AUTH TLS`) only.
Passive data ports	A declared range that must be open outbound in the partner's firewall.
CA fingerprint	They should pin this for FTPS — see Trust & Certificates.
Server certificate fingerprint	Informational. Do not pin it — it changes on rotation.

The passive port range is the most common FTPS mistake. FTP opens a fresh connection per transfer on a port the server nominates. If that whole range is not open, the control channel connects, the partner logs in successfully, and then the first directory listing or transfer hangs with no diagnosable error. If a partner reports "it connects and then just sits there", this is why.

First connection — SFTP

sftp -P 22 <username>@<host>

On the first connection the client prints the host key fingerprint and asks whether to trust it. Compare it against the panel before typing yes.

Then:

sftp> cd /inbound/edi
sftp> put purchase_order.edi
sftp> ls
sftp> bye

To check the fingerprint without logging in at all:

ssh-keyscan -p 22 <host> | ssh-keygen -lf -

For a scripted client, pin the key in known_hosts rather than disabling host checking:

ssh-keyscan -p 22 <host> >> ~/.ssh/known_hosts
sftp -o StrictHostKeyChecking=yes -P 22 <username>@<host>

First connection — FTPS

Explicit TLS on port 21. With curl:

curl --ftp-ssl-reqd --ftp-pasv \
     -u '<username>:<password>' \
     -T purchase_order.edi \
     ftp://<host>:21/inbound/edi/

With lftp:

lftp -u '<username>,<password>' -e '
  set ftp:ssl-force true;
  set ftp:ssl-protect-data true;
  set ftp:passive-mode true;
  cd /inbound/edi; put purchase_order.edi; bye
' <host>

Both TLS settings are required. The server refuses PROT C — a protected control channel with a plaintext data channel would send the file itself in the open, which is precisely what FTPS exists to prevent. Before AUTH TLS the server accepts nothing but AUTH, FEAT, NOOP and QUIT; even USER is refused, because accepting a password on a plaintext channel is the same mistake.

What a working connection looks like

The FTPS greeting is 220 DataMagik File Gateway ready. AUTH TLS required. and the SFTP banner identifies the gateway. After a successful upload, the file appears within seconds in Transfers — see the transfers console.

What is deliberately not supported

Plain FTP — never. FTPS with explicit TLS only.
Shell access, exec, port forwarding — the SSH server offers the sftp subsystem and nothing else.
Renaming files (RNFR/RNTO) — refused rather than half-implemented, because it would break the link between a transfer receipt and its stored object.

Troubleshooting

Symptom	Usually
Connects then hangs on `ls` or `put` (FTPS)	The passive port range is not open in the partner's firewall.
Host key changed warning	A rotation is in progress. See Trust & Certificates — do not just delete the known_hosts line.
Login refused, nothing in Transfers	Check Recent connection attempts on the Security tab; the reason is recorded there.
Login refused after many attempts	The source address is throttled — see Limits.
Upload succeeds, nothing happens	The file is stored but unrouted. Add a route and replay.