Hardening SSH/TLS Ciphers to Pass a Pen Test (2026)

Q: What are weak SSH ciphers?

Weak SSH ciphers are encryption, key-exchange, and MAC algorithms with known cryptographic weaknesses or short key sizes. Common examples flagged by scanners include CBC-mode ciphers (aes*-cbc, 3des-cbc), Blowfish-cbc, Arcfour, diffie-hellman-group1-sha1, diffie-hellman-group14-sha1, and HMAC-MD5 or HMAC-SHA1 MACs. They are considered deprecated because they are either breakable or vulnerable to specific attacks.

Q: How do I disable weak ciphers in SSH/SFTP?

On your SFTP server, deselect the weak algorithms from the server's allowed list for ciphers, key exchange methods, and MACs, then restart or apply the change. In CompleteFTP, this is done in the Manager under SFTP Settings > Advanced SFTP/SCP/SSH Settings > Algorithms, or from the command line with completeftp site set default sshCipher, sshKeyExchange, and sshMAC. Re-run your scan afterward to confirm.

Q: What SSH key exchange algorithms are considered strong?

curve25519-sha256, ecdh-sha2-nistp256/384/521, and diffie-hellman-group14-sha256 or higher (group16-sha512) are considered strong. RFC 9142 deprecates diffie-hellman-group1-sha1 and discourages SHA-1 based exchanges. Prefer curve25519-sha256 as the modern default.

Q: Why did my vulnerability scan flag CBC ciphers?

CBC-mode SSH ciphers are flagged because of a known plaintext-recovery weakness in the SSH CBC implementation. Scanners report this as 'SSH Server CBC Mode Ciphers Enabled' or 'SSH Weak Algorithms Supported.' Switch to AEAD ciphers such as aes256-gcm or chacha20-poly1305, or CTR-mode ciphers, and disable the CBC variants.

Q: Does disabling weak ciphers break connections with partners?

It can, if a partner's client only supports the algorithms you removed. Before disabling anything, check which algorithms your partners actually negotiate, remove weak ones incrementally, and keep one widely-supported strong fallback (such as aes256-ctr and diffie-hellman-group14-sha256) during a transition period.

Q: How do I check which ciphers my SFTP server supports?

Use an SSH audit tool such as ssh-audit, or run nmap with the ssh2-enum-algos script, against your server's SFTP port. Both list the key exchange methods, ciphers, MACs, and host key algorithms the server offers, and flag the weak ones.

A vulnerability scan came back with a list of "weak" algorithms on your SFTP server. Something like SSH Server CBC Mode Ciphers Enabled, SSH Weak MAC Algorithms Supported, or Diffie-Hellman-Group1-sha1 deprecated. Now a compliance deadline is attached to fixing it.

The short version is that you need to tell the server to stop offering the old algorithms and to negotiate only strong ones. On CompleteFTP that takes a few minutes in the Manager or a single command from the CLI. The longer version, covering which algorithms to drop, which to keep, and how to avoid breaking partner connections in the process, is below.

This isn't a rare request. Across the real-world usage of 1,621 organizations running MFT in production (EnterpriseDT support archive, 2015–2026), roughly 1 in 11 needed to modernize or harden their SSH/TLS cipher configuration to satisfy a scan, an auditor, or a partner's security team. It shows up steadily across the archive, and disproportionately in finance, banking, healthcare and government, where a scan finding cannot be left open for long.

The quick answer

To pass a cipher scan on an SFTP/SSH server, disable these on the server:

CBC-mode ciphers: aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc, blowfish-cbc
Legacy stream/weak ciphers: arcfour, arcfour128, arcfour256
SHA-1 / weak key exchange: diffie-hellman-group1-sha1, diffie-hellman-group14-sha1
Weak MACs: hmac-md5, hmac-sha1, hmac-sha1-96, umac-64
Deprecated host keys: DSA (ssh-dss)

And keep (or add) these:

Ciphers: chacha20-poly1305, aes256-gcm, aes128-gcm, aes256-ctr, aes128-ctr
Key exchange: curve25519-sha256, ecdh-sha2-nistp256/384/521, diffie-hellman-group14-sha256, diffie-hellman-group16-sha512
MACs: hmac-sha2-256-etm, hmac-sha2-512-etm, hmac-sha2-256, hmac-sha2-512
Host keys: Ed25519, ECDSA (nistp256/384/521), RSA with SHA-2

The rest of this guide covers how to apply that mapping cleanly, how to verify it, and how to avoid the mistake that turns a security fix into an outage.

Why a weak algorithm is a real risk, not just a scan finding

It is easy to treat this as a box to tick, because the trigger is usually a scanner or an auditor rather than an incident. The underlying risk is real. An algorithm on the deprecated list is one an attacker positioned between a client and your server may be able to break: recovering the contents of a transfer, tampering with a file in flight, or forging authentication. A weak key exchange can let that attacker force both sides down onto the vulnerable algorithm even when both support something stronger. The files moving across an SFTP server are usually the files worth protecting, which is why these algorithms are deprecated rather than merely discouraged. Passing the scan is the visible outcome; closing that exposure is the point.

What the scanner is actually complaining about

Vulnerability scanners don't test whether your encryption works. They test whether your server is willing to negotiate an algorithm that's known to be weak. If the algorithm is on the offer list, it gets flagged, even if no real client ever selects it.

Three categories account for almost every finding:

CBC-mode ciphers. SSH's use of CBC has a plaintext-recovery weakness dating back to 2008. Scanners report it as "SSH Server CBC Mode Ciphers Enabled." The fix is to prefer AEAD ciphers such as aes256-gcm and chacha20-poly1305, or CTR mode, and to remove the CBC variants.

SHA-1 and Group1 key exchange. diffie-hellman-group1-sha1 uses a 1024-bit group that's no longer considered safe, and SHA-1 is deprecated across the board. RFC 9142 formally updates the recommended key-exchange set and moves these to "SHOULD NOT." One organization in our archive, a US direct-mail processor, put the requirement in one line to our support team:

"Disable ssh-dss and weak diffie-hellman key exchange algorithms. Restrict to strong algorithms only (Ed25519, curve25519-sha256, etc.)"

a US direct-mail organization (EnterpriseDT support archive)

Those two sentences are the entire hardening brief, taken from a real ticket, and they double as a template for describing the change to your own auditor.

Weak MACs and old host keys. hmac-md5 and hmac-sha1 get flagged as weak message-authentication codes. DSA host keys (ssh-dss) are capped at 1024 bits and are deprecated, so remove them and rely on Ed25519, ECDSA and RSA-with-SHA-2 instead.

Sometimes the finding doesn't even originate with your own scan. It arrives from the other side of the connection:

"One of our suppliers perform security scan of our SFTP environment and send to security recommendation that we should applied in our environment. Its about: SSH Supports Weak Cipher, SSH Supports Weak MAC, TLS Service Supports Weak Cipher Suite."

a US automotive organization (EnterpriseDT support archive)

When a partner's security team runs the scan, "we'll get to it next quarter" stops being an option, which is why these requests usually arrive with a deadline attached.

Recommended vs. deprecated: the reference table

Keep this next to your scan report. Anything in the right column that your server still offers is a finding waiting to happen.

Algorithm type	Use these (strong)	Disable these (deprecated / weak)
Ciphers	chacha20-poly1305, aes256-gcm, aes128-gcm, aes256-ctr, aes128-ctr	aes*-cbc, 3des-cbc, blowfish-cbc, arcfour / arcfour128 / arcfour256, des
Key exchange	curve25519-sha256, ecdh-sha2-nistp256/384/521, diffie-hellman-group14-sha256, diffie-hellman-group16-sha512	diffie-hellman-group1-sha1, diffie-hellman-group14-sha1, gss-group1-sha1
MACs	hmac-sha2-256-etm, hmac-sha2-512-etm, hmac-sha2-256, hmac-sha2-512	hmac-md5, hmac-sha1, hmac-sha1-96, umac-64
Host keys	ssh-ed25519, ecdsa-sha2-nistp256/384/521, rsa-sha2-256, rsa-sha2-512	ssh-dss (DSA), ssh-rsa (SHA-1 signature)

Two notes on the strong column. Modern host keys (Ed25519 and ECDSA) match RSA's strength at a fraction of the size, so dropping the deprecated DSA key costs nothing. And where both ends support them, the "ETM" (encrypt-then-MAC) MAC variants are preferred over their plain counterparts.

How to harden ciphers in CompleteFTP

CompleteFTP exposes every one of these algorithm lists directly, so you are selecting from the supported set rather than editing a config file by hand. SFTP is available from the Standard edition up (the Free edition is FTP/FTPS only), so this applies to any current CompleteFTP server running SFTP.

Using the Manager (GUI)

In the CompleteFTP Manager:

Go to SFTP Settings → Advanced SFTP/SCP/SSH Settings → Algorithms.
Under Available key exchange methods, deselect the weak entries, for example diffie-hellman-group1-sha1.
Under Available ciphers, deselect the CBC and legacy ciphers, for example blowfish-cbc and the *-cbc set.
Under MAC algorithms, deselect hmac-md5 and hmac-sha1.
Under Public key algorithms, disable DSA so the server stops offering ssh-dss.
Click Apply Changes. (Settings aren't saved until you do, and this is the step most often missed.)

Each list controls exactly what the server advertises during the SSH handshake. Deselect an algorithm and it disappears from the offer, so the scanner no longer sees it.

Using the command line

If you're scripting a hardened baseline across several servers, the CLI sets the same values in one shot:

# Strong ciphers only
completeftp site set default sshCipher="AES_GCM_256,AES_GCM_128,AES_CTR_256,AES_CTR_128"

# Strong key exchange only
completeftp site set default sshKeyExchange="ECDHsha2Nistp256,ECDHsha2Nistp384,ECDHsha2Nistp521,DiffieHellmanGroup14Sha256,DiffieHellmanGroup16Sha512"

# Strong MACs only (encrypt-then-MAC preferred)
completeftp site set default sshMAC="HMAC_SHA2_256_ETM,HMAC_SHA2_512_ETM,HMAC_SHA2_256,HMAC_SHA2_512"

# Modern host key algorithms
completeftp site set default sshKeyAlgorithm="Ed25519,ECDSAsha2Nistp521,ECDSAsha2Nistp384,ECDSAsha2Nistp256,RSA_sha2_512,RSA_sha2_256"

# Remove the deprecated DSA host key entirely
completeftp site key remove default dsa

The result is the same as the GUI, in a form that can be version-controlled and applied identically across several servers.

Don't forget the TLS side (FTPS and HTTPS)

If your server also runs FTPS or the HTTPS web interface, those use TLS cipher suites, which are a separate list from the SSH algorithms. Scanners flag those too, usually as "TLS Service Supports Weak Cipher Suite" or by calling out an old suite by name. One customer's own words show the shape of it:

"Selected cipher suite: TLS_AES_128_GCM_SHA256"

a French connectivity organization (EnterpriseDT support archive)

The suite quoted there is a TLS 1.3 AEAD suite and a strong one. The suites you want to remove are the RSA-key-exchange and CBC-SHA suites (TLS_RSA_WITH_AES_128_CBC_SHA and similar). CompleteFTP lets you disable SSLv3 and select TLS cipher suites the same way it handles SSH algorithms. Harden both surfaces before you re-scan, or the FTPS finding will survive the SSH fix.

Verify it by re-scanning before you close the ticket

Never mark a hardening task done on the strength of the config change alone. Confirm the server's actual offer changed.

Two tools do this well:

ssh-audit: an open-source auditor that lists every key exchange, cipher, MAC, and host key your server offers, and grades each one. It maps closely to what commercial scanners report.
nmap: nmap --script ssh2-enum-algos -p 22 your.server.com enumerates the same lists.

Run one against your SFTP port. If a *-cbc cipher or diffie-hellman-group1-sha1 still appears, the change didn't take, most often because Apply Changes wasn't clicked, or a TLS/FTPS listener is offering the weak suite instead of SSH. Fix, re-scan, then attach the clean output to your audit evidence.

The one mistake that turns a fix into an outage

Hardening goes wrong in a predictable way. You strip the server down to a short list of modern algorithms, feel good about the clean scan, and then a partner's overnight batch job stops connecting. Their client is old and only speaks the algorithms you just removed.

We've watched this exact failure mode in support tickets, where a handshake dies because the two sides no longer share a single algorithm:

"We're getting a key exchange error and it looks like it is because the remote side is only offering curve25519-sha256."

a US healthcare IT organization (EnterpriseDT support archive)

The same collision happens from the opposite direction, with one side offering only a modern algorithm that the other cannot support.

Three rules keep it clean:

Inventory before you cut. Check which algorithms your partners actually negotiate. The server records the negotiated cipher per session, which in CompleteFTP is most easily read from the audit log, so check it before deciding what is safe to drop.
Keep one strong fallback during transition. aes256-ctr and diffie-hellman-group14-sha256 are strong and widely supported. Leaving them enabled clears virtually every scanner while giving older-but-not-ancient clients a landing spot.
Cut in stages. Remove the obviously-dead algorithms (arcfour, MD5, Group1, DSA) first, since nothing modern uses them. Then tighten CBC and SHA-1 MACs once you've confirmed no partner depends on them.

Sequencing the change this way keeps the hardening from causing an outage.

Why this keeps coming up

Cipher requirements move. An algorithm that passed last year's scan fails this year's because a standard got updated or a scanner tightened its rules. A configuration that needs revisiting periodically is normal for a maintained security posture.

What matters is that the server lets you keep pace without a forklift upgrade: select the algorithms, apply, re-scan, done. CompleteFTP has exposed these lists since the protocols themselves matured, and the same engineering team has maintained the SFTP, FTPS and SCP stack since 1999, so when a standard such as RFC 9142 shifts the recommended set, the controls needed to comply are already present.

Choosing a server that exposes these controls is worth weighing before a scan forces the question. Our guide to choosing an SFTP server for Windows covers the criteria that separate these products in production, hardening control among them.

Frequently asked questions

What are weak SSH ciphers?

Encryption, key-exchange, and MAC algorithms with known cryptographic weaknesses or short key sizes. The usual suspects scanners flag: CBC-mode ciphers (aes*-cbc, 3des-cbc), blowfish-cbc, the arcfour family, diffie-hellman-group1-sha1, and hmac-md5 / hmac-sha1 MACs. They're deprecated because they're either breakable or vulnerable to a specific known attack.

How do I disable weak ciphers in SSH/SFTP?

On the server, remove the weak algorithms from the allowed lists for ciphers, key exchange, and MACs, then apply the change. In CompleteFTP: SFTP Settings → Advanced SFTP/SCP/SSH Settings → Algorithms, deselect the weak entries, and click Apply Changes. The same values can be set with completeftp site set default sshCipher / sshKeyExchange / sshMAC from the CLI. Re-run your scan to confirm.

What SSH key exchange algorithms are considered strong?

curve25519-sha256, ecdh-sha2-nistp256/384/521, and diffie-hellman-group14-sha256 or higher. RFC 9142 deprecates diffie-hellman-group1-sha1 and discourages SHA-1-based exchanges. Use curve25519-sha256 as your modern default.

Why did my vulnerability scan flag CBC ciphers?

Because SSH's CBC mode has a known plaintext-recovery weakness. Scanners report it as "SSH Server CBC Mode Ciphers Enabled." Switch to AEAD ciphers (aes256-gcm, chacha20-poly1305) or CTR mode and disable the *-cbc variants.

Does disabling weak ciphers break connections with partners?

It can, if a partner's client only supports an algorithm you removed. Check which algorithms your partners actually negotiate first, remove weak ones in stages, and keep one widely-supported strong fallback (aes256-ctr, diffie-hellman-group14-sha256) enabled during the transition.

Is CompleteFTP FIPS compliant?

CompleteFTP is not itself FIPS 140-2 validated, but it can be configured to offer only FIPS-approved algorithms by restricting ciphers, key exchange, and MACs to the approved set (AES-GCM/CTR, ECDH and Diffie-Hellman group-14+ key exchange, SHA-2 MACs) and removing deprecated methods. Whether that satisfies your requirement depends on your compliance framework, so download the free trial, run your own compliance scan, and contact us to discuss FIPS specifically.

How do I check which ciphers my SFTP server supports?

Run ssh-audit or nmap --script ssh2-enum-algos -p 22 your.server.com against the SFTP port. Both enumerate the key exchange methods, ciphers, MACs, and host key algorithms the server offers and flag the weak ones.

See for yourself

The fastest way to know your configuration passes is to run the scan against it. Download the CompleteFTP free trial, apply the algorithm baseline above on Windows or Linux, and point your vulnerability scanner at it. Per server, perpetual license, unlimited users, with the cipher lists presented in the Manager rather than buried in a config file.

Download the 30-day free trial (no credit card required), or read the SFTP/SCP/SSH settings documentation for the full algorithm reference.

Methodology note: the "roughly 1 in 11" figure reflects organizations in the EnterpriseDT support archive (2015–2026) who raised a ticket related to SSH/TLS cipher configuration. It is a support-visible sample of organizations running our MFT products rather than a market-wide measurement, so it undercounts anyone who hardened their server without needing help. Customer quotes are verbatim from support tickets, anonymized to role and geography.