SSH accepts sessions with no encryption (allow-none-crypto)

What the audit found

The SSH service on the router has Allow None Crypto switched on under IP → SSH. With this setting the server accepts an SSH session in which the client requests the none cipher — a session that is authenticated but not encrypted.

The audit rates this medium when SSH is reachable from the internet and low when it is limited to the internal network. It is not an open door on its own: a normal SSH client never asks for the none cipher, and an attacker cannot force one to. The risk is a misconfigured script or tool on your side quietly sending its login and commands in the clear.

Why it matters

SSH exists to replace Telnet precisely because everything in the session is encrypted. The none cipher undoes that. If a client negotiates it, the password (or key exchange, but then everything after it), every command and every response cross the network as readable text — exactly like Telnet, but on port 22 where nobody expects it.

Who would ask for that? Not OpenSSH, PuTTY or any modern client; they refuse the none cipher even if you try. But the automation around routers is full of old and odd software: a monitoring script written years ago, a backup tool built on a minimal SSH library, a vendor appliance that "supports SSH" in the loosest sense. Some of these can be configured to use none for speed or by accident, and the router will oblige. The person running the script has no idea that their admin password now travels in plain text every night.

The setting exists for compatibility with very old RouterOS releases and offers no benefit today. Since the router accepts encrypted sessions from every client anyway, refusing the none cipher cannot break anything that was set up sensibly. Turning it off is pure hygiene — the audit rates it medium rather than high because the exposure requires a cooperating client, not because the cleartext outcome is minor.

What it looks like in Winbox

Open IP → SSH. The dialog has a small number of checkboxes: Allow None Crypto will be ticked. The neighbouring options Strong Crypto and Forwarding Enabled are worth a look while you are there; the audit reports on those separately.

How to fix it

The fix is a single checkbox: untick Allow None Crypto under IP → SSH. This tells the SSH server to reject any session that proposes the none cipher. Existing encrypted sessions, including the one you may be typing this into, are unaffected, and every mainstream client continues to connect as before. Safe Mode is not needed, but there is no harm in using it.

While you are in the same dialog, two neighbouring settings deserve a look. Strong Crypto restricts the server to modern algorithms and drops legacy ones such as SHA-1 and small Diffie-Hellman groups; it is safe for any client from the last decade. Forwarding Enabled, when switched off, stops logged-in users from tunnelling arbitrary traffic through the router. The three together turn SSH on the router into what it should have been from the start: encrypted, modern, and used only for management.

If some automation stops working after the change, you have found the tool that was using an unencrypted session. Reconfigure it to use a real cipher (any AES option) — do not re-enable none.

Afterwards, connect with your usual SSH client to make sure nothing changed for you; if you want to see the rejection explicitly, an OpenSSH client can be asked to propose the none cipher and should now fail to negotiate. Then re-run the audit: the finding should disappear.

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

Could an attacker exploit this without a cooperating client?

No. The cipher is chosen by the client during negotiation, and the server cannot downgrade an unwilling client. The danger is entirely on the client side: a tool of yours configured, deliberately or accidentally, to use no encryption. That is why the severity is moderate rather than critical.

Why was this on in the first place?

The option dates from older RouterOS versions where the none cipher was allowed for compatibility with certain tools and for lower CPU use on small devices. Many configurations were carried forward through upgrades with the setting intact. Current RouterOS defaults it to off.

Will strong-crypto break my old SSH client?

Possibly, if the client is very old (a library that only speaks SHA-1 and 1024-bit DH). In that case update the client rather than weakening the router. Switching off Allow None Crypto on its own never breaks a working client, so at minimum apply that.