0x00. Intro

Logging into a MikroTik router with a password is fine for a one-off, but for anything repeatable — scripts, backups, automation — you want SSH keys. Keys don’t get typed, logged, or brute-forced, and they let an unattended job connect without a secret sitting in a config file.

This is a short, practical walkthrough for RouterOS v7: generate a keypair, import the public half into the router, log in with the private half, and dodge the one gotcha that trips most people up (RSA keys silently failing with modern OpenSSH clients).

A tiny bit of vocabulary first:

  • Keypair — two matching files: a private key (stays on your machine, never leaves it) and a public key (.pub, safe to hand out and to install on the router).
  • ed25519 — a modern, small, fast key type. Preferred over RSA where supported — and RouterOS 7.x supports it.

All examples use generic placeholders: user admin, host 192.168.88.1 (MikroTik’s default LAN address). Substitute your own.

0x01. Generate a keypair

On your workstation (Linux, macOS, or Windows with OpenSSH), create the keypair. ed25519 is the recommended choice:

ssh-keygen -t ed25519 -f ~/.ssh/mikrotik -C "admin@mikrotik"
  • -f ~/.ssh/mikrotik — where to write the keys. This creates two files: ~/.ssh/mikrotik (private) and ~/.ssh/mikrotik.pub (public).
  • -C "admin@mikrotik" — a comment/label, purely for your own bookkeeping.

You’ll be asked for a passphrase. For interactive use, set one; for a fully unattended automation key, you may leave it empty (-N '').

If you must use RSA (e.g. an older client that lacks ed25519), make it at least 4096 bits:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/mikrotik -C "admin@mikrotik"

Either way, the file you install on the router is the .pub one. The private key never leaves your machine.

0x02. Upload and import the public key

This is a two-step process on RouterOS, and the second step is the one people forget: copying the .pub file onto the router does nothing by itself — you must explicitly import it against a user.

Step 1 — upload the .pub file

Copy the public key to the router — either manually via Files → Upload (in WinBox/WebFig), or with scp if you already have SSH access set up. Note the -O flag: RouterOS’s SSH server does not support the modern SFTP-based transfer that current OpenSSH uses by default, so you must force the legacy scp protocol with -O:

scp -O ~/.ssh/mikrotik.pub admin@192.168.88.1:

The trailing : means “the user’s home directory on the router” — the file lands in RouterOS’s file storage as mikrotik.pub. You can confirm it arrived from the router console:

/file print

Step 2 — import it against a user

Now log in to the router (password login still works at this point) and run the import, binding the key to a specific user:

/user ssh-keys import public-key-file=mikrotik.pub user=admin

That’s the step that actually activates the key. Verify it registered:

/user ssh-keys print

You should see an entry for user admin with the key’s type and bits.

0x03. Log in with the key

Back on your workstation, point ssh at the private key with -i:

ssh -i ~/.ssh/mikrotik admin@192.168.88.1

Two RouterOS behaviours worth knowing:

  • Address restriction. A RouterOS user can be locked to a source network with address=. If you set it, connections from anywhere else are refused regardless of the key. To allow a whole management subnet, for example:

    /user set admin address=192.168.88.0/24

  • Key-only by default. Once a user has an SSH key imported, RouterOS defaults to key-only login for that user and refuses the password. That’s usually what you want. If you deliberately need password login to keep working alongside the key, enable it explicitly:

    /ip ssh set always-allow-password-login=yes

0x04. The gotcha: ssh-rsa (SHA-1) is disabled by default

Here’s the one that causes head-scratching. Modern OpenSSH (8.8 and newer) disabled the old ssh-rsa signature algorithm — that name refers specifically to RSA signatures using SHA-1, which is considered weak. The RSA key is fine; it’s the SHA-1 signature that’s blocked.

The symptom: you imported an RSA key correctly, /user ssh-keys print shows it, and yet the client fails with:

Permission denied (publickey).

…and confusingly it may fail from one client (e.g. an older or Windows ssh) while working from another (a current Linux OpenSSH) using the same key. That’s because RouterOS 7.x supports the newer rsa-sha2 signatures, so a modern client negotiates SHA-256 and succeeds, whereas an older client only offers SHA-1 and gets rejected.

Two fixes, best first:

  1. Prefer ed25519 (cleanest). It sidesteps the whole SHA-1 question and is supported on RouterOS 7.x. If you can regenerate the key, do this and move on.

  2. Re-enable ssh-rsa on the client as a workaround, if you’re stuck with an RSA key and an older client:

    ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -i ~/.ssh/mikrotik admin@192.168.88.1

    To make it permanent, add it to ~/.ssh/config for that host:

    Host 192.168.88.1
    User admin
    IdentityFile ~/.ssh/mikrotik
    PubkeyAcceptedAlgorithms +ssh-rsa

0x05. Verify and troubleshoot

When a login won’t work, these three commands cover most cases:

  • Client-side verbose output — shows exactly which key is offered and which algorithm is negotiated:

    ssh -v -i ~/.ssh/mikrotik admin@192.168.88.1

    Look for the Offering public key and send_pubkey_test lines, and any Permission denied right after.

  • On the router — is the key registered?

    /user ssh-keys print

  • On the router — SSH server settings (e.g. whether password login is still allowed):

    /ip ssh print

A quick mental checklist if it still fails: right user in the import? key actually imported (not just uploaded)? address= not blocking your source IP? and for RSA — the SHA-1 issue from 0x04.

0x06. Wrap-up — why keys beat passwords for automation

For a human typing one command, a password is fine. For automation it isn’t: a password has to live somewhere — a script, an env var, a scheduler config — where it can leak, and every unattended run replays it over the wire. A keypair fixes both problems: the private key stays on one machine, the router only ever holds the harmless public half, and there’s no secret to type or store in plaintext. You also get per-user, per-key control on the router (address= restrictions, key-only login) and a clean way to rotate access — just remove the key entry.

Start with ed25519, import the public key against a dedicated user, lock it down with address=, and your backups and scripts connect with no password anywhere in sight.

Refs