Multiple SSH Authorised Keys NVRAM Delimiter different in Merlin to Stock?

[JDB]

So I've just updated my 86U to 384.13 and rebuilt my AiMesh using it as my master (previously had an RT-AC5300 running stock Asus in AP mode for AiMesh master).

I noted that the nodes were no longer allowing me to log in via SSH (key auth).

Upon further investigation, I noted that the 3 keys I have added via the GUI on the router are being sync'd to the nvram variable sshd_authkeys on the nodes just fine (I enabled password login to gain access).

So then I checked the /root/.ssh/authorised_keys file and found that the '>' delimiter used in the nvram variable is not being translated to '\n' (i.e. new line) in the file - hence key auth SSH login fails.

So then I discover that the JFFS partition has x attributes stripped and the .asusrouter script is thus disabled (whole other stupidity from Asus in the latest f/w), so I can't even run this automatically on boot of the node;

nvram get sshd_authkeys | sed 's/>/\n/g' > /root/.ssh/authorized_keys

So I'm assuming the '>' delimiter is new/different in Merlin compared to Stock? @RMerlin ?
Previously the stock AP was syncing multiple keys to nodes OK so guessing there is a difference or very recent change I've not noticed until just now.

Any suggestions how to get around this other than plug a USB in and use the script_usbumount nvram variable trick? I really don't want to need USB's in all my nodes just for that!

I found this very recent post of someone having a similar issue and I wonder if Asus broke this, in which case, would migrating all my nodes to Merlin fix it?
https://github.com/RMerl/asuswrt-merlin.ng/issues/156#issuecomment-508906406

 

[JDB]

So I went ahead and switched a note to 384.13 and it now works perfectly.

So word of warning, if you are using stock Asus f/w for your nodes, nvram variable sync doesn't work for ssh keys!

 

[RMerlin]

I replaced CRLF with > a few years ago because Asuswrt's nvram backup will generate corrupted config files when making a backup of settings that contain CRLFs. It's also problematic with OpenVPN custom settings (except in that case, I encoded everything in base64 to also take care of other character limitations).

If I revert back to using CRLF, then backups will fail to restore properly when saving a backup of your settings.

The jffs removal of the executable attribute should be gone from future Asus firmwares.

 

[JDB]

Thanks for the explanation. At least I’m not going mad.

I think this is likely to trip a few people up using AiMesh in a mixed Merlin/Stock environment. Simple fix at least.


Sent from my iPhone using Tapatalk

 

[RMerlin]

Thanks for the explanation. At least I’m not going mad.

I think this is likely to trip a few people up using AiMesh in a mixed Merlin/Stock environment. Simple fix at least.

There's more to it tho. In my case here, the sshd_authkeys content isn't even propagated to my Lyra Trio node after I edited it on my primary.

Config sync is handled by the closed source cfg_sync, so not much I can do to look any further...

For most people it shouldn't be an issue (assuming the keys can propagate properly, unlike in my own test setup), since most people using SSH keys to access their router only use a single key.

 

[JDB]

That’s true, stick to a single key and it’ll be fine.

Worth noting mine only update the nvram variable on the nodes if it reboot them, it’s not real-time.


Sent from my iPhone using Tapatalk

 

[RMerlin]

Worth noting mine only update the nvram variable on the nodes if it reboot them, it’s not real-time.

Odd. I would expect config synchronisation to occur whenever a change is made to the primary settings. Sounds like a bug to me.

Again, can't really check/debug that for Asus, it's closed source. <shrug>

 

[JDB]

Yea I know it’s closed source so not a lot you can do.
Shame as you’d no doubt improve it!


Sent from my iPhone using Tapatalk