Enhancing File Transfer Security with SSH Key Authentication

Attackers scan for TCP 22 and 2222 around the clock. When they find an open port, they launch credential-stuffing lists harvested from previous leaks, brute-force scripts, and even malware that hunts for hard-coded passwords in deployment repositories. Verizon’s 2025 Data Breach Investigations Report (DBIR) continues to show stolen credentials as a leading initial access vector because many organizations still rely on simple passwords for SSH and SFTP. Once an outsider lands shell access or write permission to an upload directory, web-facing code and client data follow quickly.

An SFTP service is often left out of the web security conversation. Teams focus on the CMS and the firewall while the file transfer daemon quietly accepts connections using the same local accounts that manage the full server. The following guide walks through practical steps to reduce that exposure by treating SSH keys as the primary authentication factor and by enforcing the principle of least privilege throughout your configuration.

How SSH Shapes Every SFTP Session

SFTP is not a separate protocol, it is a subsystem of SSH. Understanding the handshake sequence helps administrators see where controls belong.

1. Encryption negotiation
   • Client and server exchange supported ciphers and agree on one.
   • Each side performs a key-exchange algorithm to derive a short-lived symmetric session key.
2. Server authentication
   • The server proves identity with its host key, signing session data that only the legitimate private host key can sign.
   • The client checks that signature against the saved host-key fingerprint (host key pinning). Skipping this step invites man-in-the-middle attacks.
3. Client authentication
   • Option 1: Username and password (discouraged).
   • Option 2 (recommended): Public key authentication – The client signs session-specific data with its private key; the server verifies that signature using the public key listed in ~/.ssh/authorized_keys.
4. Channel setup
   • After authentication, SSH spawns subsystems such as an interactive shell, port forwarding, or internal-sftp.

The short-lived symmetric session key protects confidentiality; the long-term public/private key pair proves identity. When passwords replace keys, identity rests on secrets users duplicate, share, or forget to rotate.

Host Keys, User Keys, and Their Homes

Not every SSH key serves the same role.

Host keys

• Location: /etc/ssh/ssh_host_*
• Purpose: Let clients verify they’re talking to the intended server.
• Rotation impact: Triggers a fingerprint change on clients; plan for it.
• Protection level: Root-only; never leave the server.
• Tip: Enable client-side UpdateHostKeys yes to streamline planned rotations.

User keys

• Location: Generated on the client (ssh-keygen) then placed on the server in ~/.ssh/authorized_keys (or served centrally).
• Purpose: Authenticate the human or automated process.
• Rotation impact: Removing a line in authorized_keys instantly revokes access.

Keep these concepts separate. Back them up independently, document fingerprints, and make sure your relevant teams know which host-key prompts are safe to approve.

Why Passwords Fall Short for SFTP

Even complex passwords fall prey to:

• Credential stuffing: Attackers replay billions of leaked passwords.
• Key-logging malware: Endpoint compromise steals secrets immediately.
• Social engineering: One well-timed phishing email can “explain” a login prompt.

Public key authentication resists all three. The private key never travels across the network, and passphrases protect it at rest. Pair with hardware-backed keys (FIDO2, ed25519-sk/ecdsa-sk) for phishing-resistant MFA, without bolting one-time codes onto your automation.

Generating Strong SSH Keys

Run the following on the workstation or CI runner that will initiate the connection:

Preferred (fast, compact, strong):

ssh-keygen -t ed25519 -a 100 -C "deploy@example.com"

If RSA is required by policy:

ssh-keygen -t rsa -b 4096 -a 100 -C "legacy-rsa@example.com"

Why this?

• ed25519 is smaller and faster than RSA with excellent security margins.
• -a 100 increases KDF rounds (default is lower), slowing offline guessing if a private key file leaks.
• The comment labels the key’s owner for audits.
• Always set a passphrase unless the key is dedicated to an automated process in a protected environment.
• Consider security keys (-t ed25519-sk) for high-risk admins.

Key Rotation, Revocation, and Audit

Keys age. Regularly review and update them.

• Quarterly key review: Remove stale authorized_keys entries by comparing them against HR records.
• Passphrases: Change immediately after compromise.
• Generate Fingerprints with:

  ssh-keygen -lf /path/to/key.pub

• Storage: Store in CMDB or encrypted wiki.

Host-key lifecycle:

• After rebuilds/rotations, clients can ssh-keygen -R hostname to remove old entries.
• Encourage UpdateHostKeys yes on clients for auto-learning new host keys post-trust-on-first-use.

Monitoring and Incident Response

SSH provides strong crypto but minimal insight after login. Layer in the following:

1. System logs

• Debian/Ubuntu: /var/log/auth.log
• RHEL/AlmaLinux: /var/log/secure
• On systemd hosts: journalctl -u sshd.

Forward to a SIEM; alert on repeated failures, new key additions, and unexpected chroot errors.

2. Intrusion prevention

• Fail2ban’s sshd jail can block IPs after N failures.
• MaxStartups limits unauthenticated connection floods.
• Network ACLs or firewalls can restrict geographies you don’t serve.

3. File integrity & malware scanning

• New uploads can trigger web shells or backdoors. Integrate the Sucuri Website Security Platform to scan uploads in real time and quarantine suspicious code before users see it.
• Add a vendor-neutral option where needed: inotify-driven pipelines with on-access scanning (e.g., ClamAV) at the ingest point.

4. Offsite backups

• Snapshot the entire chroot directory daily.
• Store copies on immutable object storage so ransomware inside a compromised account can’t erase history.

When an incident occurs:

• Disable the compromised key by commenting/deleting its line; systemctl reload sshd.
• Lock the account and force rotation of any keys used on the affected endpoint.
• If host compromise is suspected, rotate host keys after remediation and update client trust.

Layering SFTP Controls with Broader Web Security

Key-based SFTP is one pillar of website defense. Pair it with:

• A web application firewall so that even if a malicious file makes it to your site, exploitation attempts hit virtual patching.
• Continuous malware scanning to spot backdoors embedded by compromised users.
• Secure backups for rapid restoration if attackers overwrite or encrypt data.
• DDoS protection to prevent attackers from masking file exfiltration behind noisy traffic.

Key Takeaways for Busy Teams

• Exposed SFTP ports invite password attacks; switch to public key authentication by default.
• Generate keys locally, prefer ed25519 (or hardware-backed keys), and protect them with passphrases.
• Harden sshd_config: disable passwords, chroot SFTP users with correct ownership, and disable forwarding for least privilege.
• Audit and rotate keys on a schedule; centralize or certificate-sign at scale; monitor logs and scan uploads to catch post-login abuse.
• Keep OpenSSH current and avoid re-enabling legacy algorithms.
• Combine SFTP hardening with layered website security for full-stack protection.

Need immediate help cleaning a compromised server or tightening configurations? Reach out to our Incident Response team 24 hours a day.