SSH strong-crypto is not enabled

What the audit found

The SSH service on your router is enabled, and the strong-crypto option under IP → SSH is left at its default of no. In that state RouterOS offers a broad, backwards-compatible set of algorithms to connecting clients: key exchange using SHA-1 and small Diffie-Hellman groups, ciphers in CBC mode, and HMAC based on SHA-1 or MD5. With strong-crypto switched on the server offers only the modern subset.

The audit reports this as medium when SSH is reachable from the internet and low when it is limited to your internal network.

Why it matters

SSH negotiates its algorithms at the start of every session: the client proposes, the server picks from what it allows. If the server allows weak options, a client — or someone sitting between the client and the server who can influence the negotiation — can end up with a session that uses them.

The weak options are not broken in the sense of "decrypt it in an afternoon", but each has known problems. SHA-1 has practical collision attacks. 1024-bit Diffie-Hellman groups are within reach of well-funded attackers, as the Logjam research showed. CBC-mode ciphers in SSH have had plaintext-recovery attacks. None of these is likely to be used against a small business router today, and that is why the finding is medium rather than high. But SSH on a router is the door that leads to full configuration access, and there is no benefit in leaving weak options enabled: every current SSH client supports the strong set.

This is a one-line hardening step with a small chance of side effects, which the FAQ below covers. It becomes more important the more exposed the SSH port is, which is why the audit weights it by reachability.

What it looks like in Winbox

Open IP → SSH. The window shows a handful of options: Forwarding Enabled, Always Allow Password Login, Strong Crypto, Allow None Crypto and Host Key Size. If the Strong Crypto box is unticked, this is the finding. Whether SSH is enabled at all, and on which port and from which addresses, is under IP → Services in the ssh row.

How to fix it

The fix is to tick Strong Crypto under IP → SSH. That single option tells the server to offer only modern algorithms — AES in CTR and GCM modes rather than CBC, SHA-2 based MACs, and larger Diffie-Hellman groups or elliptic-curve key exchange. Existing sessions are not affected; new ones negotiate under the stricter policy.

If the router still uses an old, small host key, it is worth raising the Host Key Size to 4096 bits and regenerating the host key at the same time, in the same window. Regenerating means every client that has connected before will warn that the key changed on its next login. That is expected; accept the new key after confirming you are talking to the right device.

Before you change anything, make sure you have a second way in — Winbox from the LAN, or a console cable — in case a client you rely on turns out not to support the modern set. Safe Mode does not help here, because an SSH negotiation failure is not a lost Winbox session; instead keep a Winbox session open in parallel until you have confirmed SSH still works. Also confirm that SSH itself is restricted to your management network in the Available From field under IP → Services: strong crypto protects the session, while the address restriction and the firewall decide who gets to start one.

Afterwards, open a new SSH session from your usual client; it should connect normally, and a verbose connection log should show a modern key exchange and an AES-CTR or GCM cipher, with no SHA-1 or CBC. Then re-run the audit.

The full MKRouterKit report gives the exact commands for your configuration — with your interface names and subnets filled in, in the order that will not lock you out.

FAQ

Will this break my monitoring or backup scripts that connect over SSH?

Only if the script's SSH library is very old. Anything from the last several years — OpenSSH, PuTTY, Paramiko, libssh, the Ansible RouterOS modules — supports the modern algorithms. Test from each system that connects automatically before relying on the change. If one fails, update that client rather than reverting the router.

Is strong-crypto enough to make SSH safe on the internet?

No. It only decides which algorithms are used once a connection is made. Brute-force attempts and future server bugs are unaffected. Keep SSH restricted to your management addresses or a VPN, drop WAN traffic in the input chain, and use key-based authentication where you can.

Why doesn't RouterOS enable this by default?

Compatibility. MikroTik ships the permissive default so that very old clients and embedded management systems keep working. On a router you administer with current tools there is no reason to keep the old options available.