Security principles that apply to self-service SFTP connections. For background on how the keys and host-key pinning work, see How SFTP works.

​

Host-key pinning

The first successful connection to a customer SFTP server captures the SHA256 fingerprint of the server’s host key. The fingerprint is then locked on the connection. Every later connection compares the server’s presented host key against the pinned fingerprint. A mismatch aborts the connection before any credentials are sent. A legitimate host-key change (a server reinstall, a planned key rotation) requires an operator to re-test the connection and re-lock the new fingerprint from the Setup tab of the server.

​

SSH key preferred over password

SSH-key authentication uses a cryptographic signature. The private key never leaves the system that owns it, and the public key on the server reveals nothing exploitable. Password authentication transmits the secret on every connection, even over the encrypted SSH channel. It is more vulnerable to credential reuse, weak passwords, and slow leaks. TechWolf strongly recommends SSH-key authentication for all production servers. Password authentication is provided only for legacy SFTP servers that cannot accept public keys.

​

Key rotation without downtime

Multiple active SSH keys per server are supported. A safe rotation flow:

1. Generate a new keypair from the Keys tab of the server. Install the new public key on the SFTP server alongside the existing one.
2. Wait one scheduler tick and confirm the server is Healthy on the overview.
3. Revoke the old key from the Keys tab.

The connection keeps working throughout the rotation.

​

Path safety

Folder mappings reject any path segment equal to ... Mappings cannot escape the declared remote path on the SFTP server.

​

Audit trail

Every successful file pull is logged with its filename and timestamp. The log is visible on the History tab of each server, and is the source of the read-once guarantee described in Behaviour.