Who is using an SSH connection between routers after updating to 7.24, is key-based authentication from scripts still working for you?
Simple setup:
Private/public keys (pair generated on Debian; the issue also happens when exporting the host key from the router)
Private key is added to the "admin" user on the router I'm connecting from (router1)
On the router I'm connecting to (router2, 192.168.1.2), I created a group "group2" with "reboot" and "ssh" policies; created a user "user2" (with "group2"); imported the public key from step 1 above for "user2"
From router1, in the terminal via Winbox (logged in as "admin"), I run command /system ssh-exec address=192.168.1.2 user=user2 command="/system/reboot"; – and router2 (192.168.1.2) reboots
If I put this command in a script (with "test" and "reboot" policies, owner "admin"), running the script gives a "failure: authentication failure (/system/ssh-exec; line 1)" error in the log; if I enable ssh logging, it additionally logs (when running the script) that the key is not found ("no keys found, skipping").
Before the update to 7.24, this same configuration worked fine.
When running ssh-exec from the Winbox terminal, it also works fine, meaning the keys are imported correctly.
The script’s owner is "admin".
Why it can’t find the private key specifically when connecting from the script, and only after updating to 7.24, is unclear.
I can’t request support through the official portal yet, so I’m writing here to see if anyone else has the same error.
(I’ve tried enabling all policies for the script on router1 – it doesn’t help. It just can’t find the key when using "ssh-exec" from the script; but key authentication works fine from the terminal using the same "ssh-exec" command, and the private key is successfully found).
At first, I used RSA generated in Debian via `ssh-keygen -t rsa -m pem`.
Then I thought the problem might be with the keys and used the key obtained in firmware 7.24. I did it like this in RouterOS:
`/ip ssh regenerate-host-key`
`/ip ssh export-host-key key-file-prefix=key1`
After that, RouterOS itself also generated an RSA key (and, by default in firmware 7.24, I still have RSA: in "ip", "ssh", "host key type" - we can choose Ed25519 too, but by default it's RSA).
What confuses me is that if the keys didn’t match, the `/system ssh-exec` command wouldn’t work at all, but it doesn’t work only from a script run through Winbox. Yet, from the terminal window opened in Winbox, the same command works with the same RSA keys
Test by trying to run the script manually on the first machine in Winbox via the menu "System", "Scripts", and "Run Script" on the script "script1" – in the log we get:
executing script script1 from winbox failed, please check it manually
(winbox-3.43/mac-msg(winbox):admin@00:15:5D:02:02:00) failure: authentication failure (/system/ssh-exec; line 1)
Test the same script through Winbox, but in the terminal window:
/system/script/run script1
It worked successfully!
I don’t understand why "it works this way, but not that way."
What’s the difference between running scripts from the terminal window and directly via the Winbox GUI, and how to make it work both ways (in versions before 7.24, it worked both ways!).
if we create a task in the scheduler on router1 with the policies "test" and "reboot" and the command "script1" - we get the same authentication error in the log when trying to run script1, which tries to execute ssh-exec
but if we create a task in the scheduler on router1 with the policies "test" and "reboot" and the command "/system/script/run script1", then there’s no authentication error - script1 successfully executes ssh-exec.
it seems that some different mechanisms are working (when running ssh-exec inside a script) when running just "script1" versus running it as "/system/script/run script1".
but in firmware before 7.24 - it was identical and worked both ways.
The problem is that the error occurs on the side from which the connection is made (where there are no extra groups or users, whereas the connection is made under admin, who already has all the rights/policies)
That is, the problem is that depending on how we run the script (containing the "/system ssh-exec" command) - either directly through Winbox or via terminal/scheduler task (where it's an "indirect" run using "/system/script/run scriptname") - the script can't read the private key assigned to the admin account:
If we just run the script (through the Winbox GUI) - the system can't read the private key
If we call the script "indirectly" (via /system/script/run) - the same admin account successfully reads the assigned key and uses it for SSH authentication to another router.
And the problem started with version 7.24 - in older firmware versions, the admin account could read the private key without problems regardless of how the script was run
I created a ticket on the support website, maybe they'll help (if there are methods where ssh-exec doesn't work, then in my opinion, those methods should either be removed from the firmware or fixed so that key authentication works in them again, like it did before)
It might seem like, "well, just run the scripts through the terminal and /system/script/run, if that works, what's the problem?", but the problem is that if we run the script through the terminal and the terminal connection drops, the script just stops right at that moment.
The only way (considering that running through the Winbox GUI stopped working in version 7.24) for the script to keep running even if you disconnect from Winbox is to create a scheduler task (with the command "/system/script/run/ scriptname"). But having to create a scheduler task every time we need to run a script that contains ssh-exec is really inconvenient
I think unless they have built-in terminal multiplexer like tmux this behavior is correct. We need to have explicit control over script executions, and silently running scripts on the terminal when we disconnect violates the principle of least astonishment. An alternative would be great but it should not be the defaults.
Agreed, this is normal behavior (support confirmed this before): if commands are executed from the terminal, then when the terminal connection is interrupted, everything that was running (like a script) also stops.
But if there are several routers and we run a script that reboots several other routers we’re connecting through to the one where the script is running, the connection can drop.
Earlier, to make sure such a script ran completely (even if the connection dropped after starting the script), I would just run it via the GUI in Winbox (and for that kind of launch, it would run “asynchronously” and work independently of the connection to Winbox).
In the latest firmware version, this kind of launch stopped working if there’s an ssh-exec with key authentication inside the script being run.
This is what my topic is about — how to run it now (doesn’t work through the GUI, runs incorrectly through the terminal).
So far, the only option I see is to manually create a scheduler task, and then the scheduler will run the script 'asynchronously' (no need to stay connected to Winbox until the script finishes).
But that's really inconvenient (having to create a scheduler task every time to run a script that we used to just launch with a click in Winbox).
I'm waiting for the developer's response (I submitted a ticket on the support portal a few days ago).
I was thinking maybe someone else had a similar problem and could share how they worked around it.
Previously, before version 7.24, to reboot a remote router, from the current one (where we're running the script via SSH to reboot the remote), it was enough to have the "test" and "reboot" policies.
In version 7.24, this stopped working, and when running such a script ("script1" on "router1" as per the step-by-step instructions above) via "run script" in Winbox, an error about reading the key (the private key assigned to the admin account on router1 in the example above) appears in the route1 log.
Now I found that if we add the property "Don't require permissions" to the script script1 ("/system/script/set script1 dont-require-permissions=yes"), everything starts working again like before: we can manually run this script (which contains ssh-exec) via "Run script" in Winbox, and it works, and the private key is read successfully.
Checking any other (or all) boxes in the policy list for the script1 script doesn't help, only setting 'Don't require permissions' works.
It’s possible that in 7.24 something changed in security (related to reading SSH private keys linked to the accounts under which scripts are run), but they didn't mention it in the changelog.
I don't know if it's correct (to allow this attribute on the script), but as a workaround – it works.
