DHCP lease script cannot use ssh-exec with public/private key for automated login

ingestre · August 10, 2020, 12:26pm

I have set imported a keypair into my Mikrotik router (6.47.1) on the admin user

[admin@MikroTik] > /user ssh-keys private print detail
Flags: R - RSA, D - DSA
 0 D user=admin bits=1024 key-owner="jon@study2"

This allows me to run a script on my linux server (raspberry pi) without passwords being asked for.

[admin@MikroTik] > /system ssh-exec 192.168.0.4 user=pi command="sudo /usr/local/bin/zoneupdate"
  exit-code: 0
     output:

(The script runs without issue.)

However…When I specify this command in the DHCP Lease script, it silently fails

[admin@MikroTik] > /ip dhcp-server print detail where name=default
Flags: D - dynamic, X - disabled, I - invalid
 0    name="default" interface=bridge-local lease-time=3d address-pool=internal-ip-pool authoritative=after-2sec-delay use-radius=no
      lease-script=/system ssh-exec  192.168.0.4 user=pi command="sudo /usr/local/bin/zoneupdate"

Analysis of my linux server yields the following entries from the auth log.

Aug 10 12:54:53 mailwebdns sshd[22855]: Failed password for pi from 192.168.0.1 port 59637 ssh2
Aug 10 12:54:53 mailwebdns sshd[22855]: Failed password for pi from 192.168.0.1 port 59637 ssh2
Aug 10 12:54:53 mailwebdns sshd[22855]: Failed password for pi from 192.168.0.1 port 59637 ssh2
Aug 10 12:54:53 mailwebdns sshd[22855]: Failed password for pi from 192.168.0.1 port 59637 ssh2
Aug 10 12:54:53 mailwebdns sshd[22855]: Failed password for pi from 192.168.0.1 port 59637 ssh2
Aug 10 12:54:53 mailwebdns sshd[22855]: error: maximum authentication attempts exceeded for pi from 192.168.0.1 port 59637 ssh2 [preauth]
Aug 10 12:54:53 mailwebdns sshd[22855]: Disconnecting authenticating user pi 192.168.0.1 port 59637: Too many authentication failures [preauth]

It appears that DHCP lease script cannot use ssh-exec with public/private key for automated login.

Is this a bug? Any assistance welcomed

Sob · August 10, 2020, 5:41pm

Simplest and quite logical explanation would be that lease script doesn’t run under that specific user account, so it doesn’t have access to its private key. I’m just guessing, but why should it, there could be many different user accounts on router, how would it even know which one to choose.

I haven’t tried it, I generally don’t do much with scripts in RouterOS, but scripts in System->Scripts do have user account as owner, so I’d try to explore that. If you add your script there as admin, I’d guess it’s possible to start it from lease script and hopefully it will use correct user account.

ingestre · August 10, 2020, 6:45pm

You are quite right! (Well diagnosed!) , but I’m still stuck…

I got the DHCP lease script to create a scheduled job, and the owner of this job was “*sys” (without the quotes). RouterOS doesnt allow me to add public/private key pairs to this user, or varients thereof. Error as follows

Couldn’t perform action - local user not found (6)

Unfortunately this leaves me scratching my head and unsure of how to proceed. No matter what I do the script lease script that I write will be running under the *sys user, and RouterOS doesn’t allow this user to have a keypair.

Any suggestions will be welcomed warmly, and with thanks!

Update: I tried putting the ssh-exec into a system script owned by admin, and running it from the DHCP lease script. Despite being owned by admin the script still runs as the dhcp lease script user which means keypairs dont get used…sigh!

Sob · August 10, 2020, 7:53pm

It’s possible that it could be limitation of current RouterOS. Because other than this, I can’t think of any example where user account would matter. Permissions do, if you are doing something in RouterOS, but those are set for groups, not user accounts.

In theory (I don’t have time to play with it now), you could ssh to router itself and run the script under selected account. The problem is, you couldn’t use keys (same problem as you have now) and ssh-exec doesn’t seem to support passwords. But log from your server say “failed password”, so maybe it’s doing something with it. My guess is that maybe user with empty password could work. Which of course is horrible approach from security perspective, but it could be not that bad if you don’t need router’s ssh server exposed and it would be available only from localhost, i.e. router itself.

You can also ask support, if there’s any good official way how to handle this, or if it’s something they didn’t think of.

ingestre · August 10, 2020, 9:10pm

Thank you for your advice - Its been very helpful!

I have a workaraound, but Oh God - It’s a kludge, and hardly elegant

I set up an admin schedule for an admin owned script. The schedule runs every 2 secs, but is set to be disabled normally.
The script does just two things. Disable the schedule, and run the ssh-exec. As its being run by admin the ssh-exec uses the keypair.
The DHCP lease script just enables the schedule,
which runs the script,
which disables the schedule (so it doesnt continue to run the script again)
and then does the ssh-exec.

Like I said - A kludge.

I’m going to ask Mikrotik for their official guidance as you suggested - There gots to be a better way!

Is the recommended channel still an email to support@mikrotik.com ?

Thanks again!

J.

Sob · August 10, 2020, 10:22pm

Actually, it’s not too bad. Better than my idea with ssh to router.

I assume that email still works. They also have this new thing: https://help.mikrotik.com/servicedesk

ingestre · August 10, 2020, 10:44pm

Support call raised (SUP-24457) as follows - I will post back here with any response…

Synopsis
It is not possible to assign a private/public key pair to the DHCP lease script in RouterOS. This means that the DHCP lease script cannot run ssh-exec to seamlessly inform other servers about DHCP leases

In detail
RouterOS allows you to assign a keypair to a user so that user can ssh into other servers without manually typing passwords
I wish to use this facility within the DHCP lease script so that an external DNS servers can be informed about DHCP leases assignments/de-assignments
The DHCP lease script is run as a special internal user (*sys prob.) This user cannot be assigned a keypair so ssh-exec from DHCP lease script fails authentication. I believe it reverts to password auth , and it’s not possible to set a password either

Support Requirement
Please provide advice and support on the official Mikrotik method of passing DHCP lease information to external servers via the DHCP lease script.

ingestre · August 11, 2020, 7:53am

A prompt response from the support portal

Hello,
Thank you for contacting MikroTik Support.
Unfortunately, there is no straight implemented functionality for this, you can use fetch for this.
https://wiki.mikrotik.com/wiki/Manual:Tools/Fetch
Please contact consultants, if you want someone to configure your device, > www.mikrotik.com/consultants
Best regards,

This would probably work, but would mean I need to put a dedicated web vhost on my name server. I’m going to stick with my current kludge workaround and ask that this functionality be implemented in future releases of RouterOS. We shall see…

I’d like to thank all those on this forum who viewed and thought about my issue - and especially Sob who gave such insightful help and assistance.

ingestre · August 11, 2020, 9:14am

Asked for a change request - Got this response

Hello,
Thank you for contacting MikroTik Support.
I have forwarded this information to our team, if the similar requests will be from users, we will think about how to implement this in the future.
Best regards,

It’s now in the hands of the users - If you feel this functionality is needed then raise a call with the sevice desk - https://help.mikrotik.com/servicedesk

Lelik200 · September 3, 2020, 8:30am

Hello!
I have not tested how my version works with DHCP, but for ppp-on-up script it works. I think it’s the same thing.

So. We have two routers: “A” - on which the event occurs, “B” - on which the command must be executed.

Create public and private keys pair - pub.ssh, priv.ssh.
Settings for “A”:

There is only one user on this router - admin; no other users need to be created!

Copy both keys to the router.

Import keys for user “admin”:
/user ssh-keys private import user=admin private-key-file=priv.ssh public-key-file=pub.ssh passphrase=“****”

Create a script that connects to Router B and runs command on Router B (192.168.0.2):
/system script add name=RemoteCtrl dont-require-permissions=yes policy=test source="
:local RemoteIP 192.168.0.2\r\n
:local RemoteUsr "ssh-adm"\r\n
:local RemoteCmd "/system script run ScriptOnRouterB"\r\n
/system ssh-exec address=$RemoteIP user=$RemoteUsr command=$RemoteCmd"

Add on-up script to our PPP profile (or add lease script to DHCP):
/ppp profile set profile1 on-up=“/system script run RemoteCtrl”

Settings for “B”:

Copy the public key to the router.

Create user group:
/user group add name=ssh policy=ssh,read,write

Add user for remote control via ssh:
/user add name=ssh-adm group=ssh

Import public key for user:
/user ssh-keys import user=ssh-adm public-key-file=pub.ssh

Create a script that will be run by an event on router A:
/system script add name=ScriptOnRouterB policy=read,write source="
:log info "Event occured on router A!""

Of course, router B must have ssh enabled and both routers must not have rules blocking ssh connections between routers.

You can also increase ssh encryption, but this must be done on both routers:
/ ip ssh set strong-crypto = yes

norteng · December 12, 2020, 12:58am

I have the same problem of the topic on my mikrotik router v6.46.7, sorry for my english, could you shared your alternative solution/scripts?

ingestre · January 14, 2022, 3:11pm

Sharing details of workaround - sorry for extended delay

The “zoneupdate” schedule is as follows. All it does is run a script (also called zoneupdate)

[admin@MikroTik] > /system scheduler print detail where name="zoneupdate"
Flags: X - disabled
 0 X ;;; This schedule fires the zoneupdate script, which immediatly disables it.
 It is only enabled by the DHCP lease script. This allows the DHCP lease script
 to trigger a script under a different user, which is allowed to use ssh-exec
     name="zoneupdate" start-date=aug/10/2020 start-time=19:51:46 interval=2s
     on-event=/system script run zoneupdate owner="admin"
     policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon
     run-count=63

The zoneupdate script is as follows :-

[admin@MikroTik] > /system script print detail where name="zoneupdate"
Flags: I - invalid
 0   name="zoneupdate" owner="admin"
     policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon
     dont-require-permissions=no last-started=jan/14/2022 08:48:40
     run-count=70 source=
       /system scheduler set disabled=yes zoneupdate
       /system ssh-exec 192.168.0.4 user=redacted command="/usr/local/bin/updatedns"

The lease script on the dhcp server is as follows :-

[admin@MikroTik] > /ip dhcp-server print detail
Flags: D - dynamic, X - disabled, I - invalid
 0    name="default" interface=bridge-local lease-time=3d
      address-pool=internal-ip-pool authoritative=after-2sec-delay
      use-radius=no
      lease-script=/system scheduler set disabled=no zoneupdate\r\n

As long as

you have imported a valid SSH key against the admin user
SSH is properly set up on the remote server,

… then whenever a dhcp lease is assigned the specified script is run on the remote server (in this case

/usr/local/bin/updatedns

script is run on server

192.168.0.4

by user

redacted

).

Hope this helps.