sorry, i did not find any better place to put this. technically it is not a bug report, it is a request for enhancement.
is it just me, or there's someone else out there who'd like to see improvements to the output of the "export" command?

Hello

Can you tell us what you have in mind?

My needs may be different from yours but export suits my needs.

Regards,

Sent from my cell phone. Sorry for the errors.

Can you tell us what you have in mind?

we have these 2 half-solutions for saving the configuration, but together they don't add up to a solid one.
backup cannot be transferred among different device families, and it is not editable. more or less that's just a file archive of the ROS internal filesystem - or this is what it looks like.
export is great cause it is textual, it will not grow significantly bigger - opposed to the backup files - and is editable.

but it doesn't contain several things:
- router user credentials - which was understandable until ROS finally dropped the old password scheme and switched to password hashes.
- user public and private ssh-keys - no way to save them unless you do the 'backup'
- certificates - i always tell my students that export is just a collection of commands that can be used to re-create a specific part of the configuration. certificate generation is a bit different, because if you execute the generation command, it will (obviously) produce a different certificate each time. so you can't just include the cert generation command in the export file.
- ssh keys - you can - similarly to certificate export and import host keys, but they're not part of the configuration which makes things difficult. and if anyone want's to play safe, a semi-static hostkey is one of the building blocks to it.

i know, system reset-configuration keep-users "helps" a bit, but basically you cannot use /export to recreate the configuration properly.
just take for example any subsystem that relies on certificates. it is contained in the /export output, but importing it fails, as the referenced certificates don't exist. even if you manually export / re-import the certs, they are created under an auto-generated name, so without manual intervention, importing the config will still fail.

i'd like to have a configuration file that is editable and has all the bells and whistles as the 'binary backup file'. i usually parse the export files and break them down into config objects in my repository. for this thing to work properly, all config data is needed, and the output of the current /export is lacking of quite some.

the other points, like the symmetric encryption of non-management user password entries is just there so an external audit cannot brag about storing cleartext passwords.
the mac address thing is just annoying: you do a verbose export just to see the default settings, and if you copy it over as is to another device, you'll start having multiple routers with the same mac address, and this ain't no fun. doing it manually is certainly possible, i wrote some code to handle this, but wouldn't be easier to export the data in a more senseful way? like only including the mac address field if it is different from the 'orig-mac-address' value?

Now I feel silly because I hadn't seen the poll on my cell phone. Nice job!!!!

I think private keys should never be exportable, neither cert or ssh.

For public keys it would be nice to be able to have in exportable configuration. This would speed up deployment quite a while for us.
User with hashes would be welcomed as well for the same reason.

I think private keys should never be exportable, neither cert or ssh.

not quite sure how much secure is the same private key or cert if it's stored on a random server or your laptop.
and as you know, certificates and ssh hostkeys can be exported with a specific routerOS command and stored on the flash/filesystem.
i suppose if this thing is paired with the sensitive=yes/no policy, your data is safe - or better put: as safe as on your server with "chmod 0600 /path/to/mysecret/stuff"

and similarly to backup, a user defined passphrase might be used to symmetrically encrypt sensitive information, but the same passphrase will be required upon import. and you still have the possibility to specify no passphrase as with the existing routeros mechanisms (backup, export-certificate)
on the other hand, if you have physical access to a device, you'll find your way into it

All I want is readable backup, i.e. it must contain everything and I need to be able to see what's inside. We now have two ways how to get config from RouterOS (export and backup) and neither can satisfy these simple requirements at the same time.

I don't even care if it can be directly imported back as whole. I guess it would be nice, but it's not critical for me. I need to be able to take two backups, easily compare them and see what changed (that works well with current export). As for restoring backups, I don't really need it that often, mostly only when original device dies, and it will probably be replaced by some other model, because it will be good opportunity to upgrade. And while I can recreate most other config (firewall, ...), I can't recreate things like certificates and keys. I can use current backups for that (I think, but I didn't test it lately), even though they are not officially made for transfering config between different models, but I really don't like them, they are these impractical binary blobs.

I've voted for exporting certificates and SSH keys since, as Sob already pointed out, they are a significant part of the configuration, and I'd like them to be available when comparing different configuration revisions.

However I'm completely with mada3k here in that only the public keys should be exportable. I would even prefer that there were no way to export any private keys at all (not even using a separate command).

I also voted for full user export with md5-hashed passwords.
+1 for exporting certificates as they are a essential part of the config.
And I´m totally with mada3k to have public keys exportable.

Now for the import process, I´d love to see an option for error-handling, ideally per config section. Like log-and-proceed: Log the error occured but go ahead with subsequent config import.
stop-import: stop the whole config import
skip-section-import: log the error, stop importing more lines from this section and continue import from the next section with a leading /
replace-section: wipe the current config of this section and completely replace it with the import.

-Chris

Now for the import process, I´d love to see an option for error-handling, ideally per config section. Like

Code: Select all

on-error=log-and-proceed, stop-import, skip-section-import, replace-section

log-and-proceed: Log the error occured but go ahead with subsequent config import.
stop-import: stop the whole config import
skip-section-import: log the error, stop importing more lines from this section and continue import from the next section with a leading /
replace-section: wipe the current config of this section and completely replace it with the import.

Yes, I would also like to see an error-handling option, especially with something like TR069 where you don't necessarily want it to stop loading everything when it hits an error.

I often see backup being used in the wrong cases because it includes users and certs. Then after restore they reset mac addresses on all interfaces, but sometimes things get missed like RoMON ID is duplicated between two devices when .backup is used. I would prefer to see the entire thing simpler, some merger of the export and backup function. Ideally the router should not start processing the rsc script until after the ethernet interfaces become active, preventing the need to include a delay loop at the top of an .rsc.

I'd like to point out that exporting only public part of certificate is not very useful. It can be if it's some CA certificate used for verification, where I have only public part anyway. But it probably falls in the "easily replaceable" category. My own client or server certificates on the other hand, those are useless without keys.

The idea is that not everyone would be able to export private stuff. Now if you're full admin user and you export e.g. PPP secrets, you get them with password:
But try the same as user who's group doesn't have sensitive policy and you won't see password:
So it would be the same with certificates and others. And then there's not much difference if you have permissions to export them individually, as part or backup (these two are already possible) or as part of export.

Interestingly, as it is now, all I need to get certificate's private key is to have account with only winbox (to get in), read, write (to export it) and ftp (to download it) policies.

But try the same as user who's group doesn't have sensitive policy and you won't see password:

Code: Select all

/ppp secret
add local-address=192.168.99.1 name=tester password=***** remote-address=192.168.99.10

So it would be the same with certificates and others. And then there's not much difference if you have permissions to export them individually, as part or backup (these two are already possible) or as part of export.

yes, this is true. on the other hand pretty much translates into in the cisco world. a regular auditor will classify this as 'the access credentials are stored in cleartext'. so my point here with the lame reversible symmetric encryption merely was to overcome this issue. so even for a demigod with group=full it shouldn't be displayed in cleartext. maybe a 'decode-symmetric-passwords=yes' option in could help the cause. of course with default setting=no.

I was really after my case, explaining why ability to export private keys would be good thing (doesn't need to happen by default, it could be hidden after additional option), and how it doesn't have to be completely unsecure, at least not more than current way of exporting passwords is.

If even full admin shouldn't be able to see this stuff, it's a different matter. It would have to be encrypted by some key that would never be exported from device. It would have to apply to everything, including current backup, which would make the data unusable for anything else than restoring to same device. Quite the opposite of what I'd like to see, and even less flexible than what we have now, but it would be reasonably secure, because not many people are able to read data from flash directly. Encrypting it in a way, that allows it to be decrypted elsewhere, means that we just need to wait for someone who will write independent decryptor, and when (not if) it happens, the encryption will be useless.

wait for someone who will write independent decryptor, and when (not if) it happens, the encryption will be useless.

i agree. the best solution for local ppp / hotspot accounts would be to use password hashes instead of cleartext passwords. but this is a huge change, albeit not as difficult as the one with the user accounts.

I don't know if it's the case here, but some authentication schemes need plaintext passwords. There's also difference between client and server, e.g. with simple verification where client sends password to server, there can be only hash stored on server, but client needs original password.

but client needs original password.

hence there's no cure for every issue. again, the lame uniform symmetric encoding on the client can be seemingly effective against idiots, proving this is a bit better than nothing.
on the server, where the impact is more significant, we need hashes.

There's a few things I would like to see

- Definitely add options to specify terminal width and not export with any color or other terminal options using the /export command. Right now this only works if adding options to the username when logging in i.e. instead of "admin" you have to use username "admin+ct240w". If just using 'admin' then programs like Solarwinds NCM, RANCID etc can totally screw up. And adding parameters to the username screws up other things i.e. specifying credentials for all devices in a group at the same time, but not all of them are MikroTik so having to put "+ct240w" on the username will fail to login
MikroTik is the only company I know of that requires these options to be parsed through the username login, and not part of the export command (or issuing some other command first to override terminal defaults). Bad design IMO
- By default, MAC addresses should NOT be part of an export but with an option to include them with i.e. export /includemac
- Change the order of some exported commands so that it actually works when simply pasting this config into another router without having to edit it
- Definitely want user accounts and passwords in there in hash form. Mostly so I can audit and change 'baseline' or old passwords on managed routers

For importing:
- A change to the import of config, both with 'run after reset' when wiping config, and the /import command. Should send a message to the system log when encountering an error and on which line, rather than just silently aborting. Right now I never use either option because its so unreliable with no way to know for sure if the entire config was imported correctly, or where it stopped
- Add a default delay of at least a couple seconds to the 'run after reset' option as right now it can fail due to some drivers not loading quickly enough i.e. wireless
- * Optionally: Have extra command line options for /import so you could specify

• 1) Import line-by-line until error occurs (how it currently is)
  2) Only import if entire config is valid with no errors, otherwise make no changes and push error to syslog (my preferred default behavior)
  3) Import line-by-line, don't stop on error keep on going but log all failed commands/errors to syslog

- Definitely add options to specify terminal width and not export with any color or other terminal options using the /export command. Right now this only works if adding options to the username when logging in i.e. instead of "admin" you have to use username "admin+ct240w". If just using 'admin' then programs like Solarwinds NCM, RANCID etc can totally screw up. And adding parameters to the username screws up other things i.e. specifying credentials for all devices in a group at the same time, but not all of them are MikroTik so having to put "+ct240w" on the username will fail to login
MikroTik is the only company I know of that requires these options to be parsed through the username login, and not part of the export command (or issuing some other command first to override terminal defaults). Bad design IMO

You may want to have a look at