> ## Documentation Index
> Fetch the complete documentation index at: https://developers.techwolf.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

Security principles that apply to self-service SFTP connections. For
background on how the keys and host-key pinning work, see
[How SFTP works](/integrations/reference/sftp/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](/integrations/reference/sftp/sftp#behaviour-of-a-customer-hosted-connection).