It works here. I wrote the steps above after testing it.
I’ve just repeated the steps. They still work. (I’d previously undone the changes.) Here’s the sanitized transcript:
% ssh centos
$ ssh-keygen -m pem -t rsa -f ~/.ssh/id_myswitch
Generating public/private rsa key pair
Enter passphrase (empty for no passphrase): <ENTER>
Enter same passphrase again: <ENTER>
Your identification has been saved in ~/.ssh/id_myswitch
Your public key has been saved in ~/.ssh/id_myswitch.pub
The key fingerprint is:…
$ scp .ssh/id_myswitch* imac:Desktop
$ cat .ssh/id_myswitch.pub >> .ssh/authorized_keys
$ exit
logout
Connection to centos closed.
% scp ~/Desktop/id_my* me@myswitch:
% ssh me@myswitch
> /user ssh-keys private import private-key-file=id_myswitch user=me
passphrase: <ENTER>
> /system/ssh centos
$ echo 'Et voila!'
Et voila!
$ exit
Welcome back!
> quit
%
The prompt characters are “%” for Zsh on the iMac, “$” for Bash on CentOS Stream 9, and “>” for a CRS328 running RouterOS 7.4.
Check that against what you’re doing. You must’ve skipped some step, or free-styled something, or fat-fingered something, or…
Did you use a passphrase? I do.
did exactly the same but get an error during import on the MT.
I even did a sftp key download directly to the MT (using pw auth).
what version of v7 are you running?
Its starting to seem like its the ssh-keygen
I’m going to run a package update on the server and regenerate the key files.
well, package updates and regenerating keys did no good.
fyi, all this works fine in v6.49.6
Quoting step 1 in my procedure above: “Don’t apply a passphrase; that will break the purpose behind ssh-exec.”
I think you’re confusing two very different uses of PEM.
With X.509 certificates, you need a passphrase with RouterOS if you want it to export a private key — e.g. when using it as a CA to mint a TLS cert for another box — since that adds an encryption layer to protect the key in transit. (e.g. A subsequent insecure FTP upload.) On import, you then need to give that passphrase to decrypt the key, which is then stored in decrypted form in a secure location on the router, since the service that needs that key can’t keep prompting you for your passphrase. To reuse the TLS example, if the private key weren’t decrypted on import, the web server couldn’t auto-start on boot, since it would have to wait until you provided your TLS key’s passphrase again.
The fact that RouterOS demands SSH private keys in PEM form doesn’t transitively require any of the above to be true. With SSH, passphrases are for protecting the private key at rest. While SSH is both an interactive protocol and one meant to be driven by scripts, passphrases serve only the interactive side. The passphrase you’re giving on ssh-keygen is a second form of authentication, to be given again each time the key is subsequently used. Importing the key into RouterOS doesn’t decrypt the key and store it in plaintext as with X.509 certs.
I will grant that there does seem to be something broken here: RouterOS shouldn’t ask for your passphrase on import at all, only on actual use of the key. If it gives an option to treat the passphrase as protection in flight only, as with X.509 certs, that should be optional, because 2FA is a good thing, and that strips the second factor. I’ve reported it to MikroTik as SUP-87935.
In any case, you do not want a passphrase on the key if you’re using ssh-exec from scripts. You can’t reasonably provide the passphrase each time the script runs.
what version of v7 are you running?
Two of my prior posts say “RouterOS 7.4”. Thrice I say it now and done: RouterOS 7.4.
If you aren’t going to heed what I wrote, I’m going to stop responding to your questions.
When I tested with RB760iGS it was without any ssh key, since the OP said nothing about that.
But the 7.4 release notes do have this:
*) ssh - disable ssh-rsa when strong-crypto=yes and use rsa-sha2-sha256;
*) ssh - fixed host key generation (introduced in v7.3);
) ssh - implemented “server-sig-algs” extension in order to improve rsa-sha2-sha256 support;)
I didn’t try, but it appears they have made changes in v7.4 to resolve a problem introduced in v7.3
An SSH client uses the host key to authenticate that it’s talking to the same host as last time, at a given address. An OpenSSH client stores the public half in ~/.ssh/known_hosts, and it rechecks it on reconnection by host name/IP. A mismatch causes OpenSSH to complain that “someone’s doing something nasty,” because it suggests a MITM attack, a replaced host, etc.
This item in the changelog is referring to the “/ip/ssh/regenerate-host-key” feature. Nothing to do with this topic, as it affects only RouterOS’s SSH server, not its SSH client.
Thanks for the info, I learned something new.
Sorry about the v7.4 thing.
the passphrase I’m referring to is the one used to create the key on the server.
couldn’t tell if you did implement that or just redacted it in your instructions. Did go reread an earlier response and do see it now.
I figured the passphrase when generating the key files was just a layer of security to make the key more secure as it sits on the server or wherever.
And that passphrase is totally different than the one use to SSH to server with user/password method.
I regenerated without a passphrase and it WORKS on both the V6 and V7 boxes!!
Its interesting the differences between V6 and V7
- in V6 both public and private keys required, V7 only the private key
- in V6 you can use a passphrase for the keys and import just fine, in V7 the import will fail even though the passphrase field is still there.
Thanks for the help!!!