Hi,
on ROS 5.20 I have an issue when using '/system ssh 1.1.1.1 user=myremoteuser'

I am trying to ssh to a remote server 1.1.1.1 using certificate authentication. I have created on this server a user myremoteuser with proper keys.

I have created the same myremoteuser on the routerboard and imported the keys.
When I log to ROS as myremoteuser, the command '/system ssh 1.1.1.1' works ok. No problem to log and access the server.
However, when I log to ROS as admin, the command '/system ssh 1.1.1.1 user=myremoteuser' does not work.


Is it a bug or I'm doing something wrong?

Actually what you describe sounds exactly right from a security perspective unless you also imported the SAME keys for the admin user?

Realise that if you are trying to ssh to a remote machine you are utilising your private key on the local mikrotik box even if you specify a 'user' to connect as.

As such:
when you login as the remoteuser on the Mikrotik and then ssh to the server it uses the private keys of remoteuser to authenticate as remoteuser@1.1.1.1
when you login as the admin on the Mikrotik and then ssh to the server it uses the private keys of the admin to authenticate as remoteuser@1.1.1.1

Unless I'm missing something

Hope this helps

You're maybe right, but then how to make a script send an ssh command with authentication?
Would the script have the right to use the remoteuser certificate?
Or are you stuck to use the same cert for ssh as admin to the mikrotik and then to install the same cert in all the server you want to ssh to?

when you create script as some user this script is owned and executed as user that added the script (at least by scheduler, netwatch uses different user and cannot be made to work with private keys).

So, for example you can create script that will be executed by sheduler. then add private key usable by admin (or whatever user you like)

just note that same user should be used as holder of private key, owner of scheduler entry and owner of script created.

Thanks, that make sense.

I'll give it a try.

To overcome the netwatch limitation, try the following which I have used as a work around in several other scripts.

Create the desired script as a scheduler event (in this example it will be named "netwatchsch1".
In your netwatch action, update the scheduled start-time to 1 second in the future using the following:This will allow a Netwatch action to execute under the user that created the scheduled event and thus, should overcome the certificate issues.

I have a very similar problem. I am trying to control a Ubiquiti mPower device via SSH. I have already setup and tested my DSA keys to bypass the password. The following code turns off one of the power outlets:This is saved in a script named OFF. It works fine if I run the code directly from the Terminal. It also works fine if I runfrom the terminal. It doesn't work if either command is ran from the scheduler. I am currently testing on an RB2011 with RouterOS 6.18. I wonder if this is a limitation of the software or if I am missing something.