is it possible to configure SwitchOS using CLI/SSH ?
No, SwOS uses a simple algorithm to ensure TCP/IP communication - it just replies to the same IP and MAC address packet came from.
This would be a very nice feature to have. Even if it was a cli client that could be run locally to interact with a secured api running from the switch. What is the process to request a new feature for SWOS?
This is not a nice to have anymore. It’s a necessity in a world where are moving towards highly automated networks. Need a way for scripts and automation engines to automatically configure/provision SwOS based switches.
Would love to see this implemented as well, even is it’s a basic one.
There’s a version of OS available which has everything you want. It’s called ROS. Yes, ROS device can be configured as a switch, doesn’t have to be router.
That does not help with switch only devices (see my list below). And for managing switches, SwitchOS works very well.
With that said, it would be nice to have at least https…
SwOS-only switches are pretty basic units. The advanced units come in both SwOS and ROS variants (or are actually dual-bootable). The post I was quoting mentioned “highly automated networks”. I don’t see basic (SwOS only) units fit the advanced use implied by that. I can agree that full ROS might be an overkill for switch-only setup. But OTOH it does offer all the advanced configuration possibilities wanted (or needed) for building “highly automated networks”.
I use switches exclusively as switches and I use routers exclusively as routers - the two functions do not cross. In fact, the only reason I have one CRS326 is that I ordered a CSS326 and the vendor incorrectly sent me a CRS326. When I contacted them about it, they said it was not worth the effort and shipping costs to swap it out for me.
As I said above, it would be nice to at least have https in SwitchOS…
I really don’t get the “https on SwOS” fame. I mean: if one doesn’t care about separation of management from other traffic, then http is enough. If one does care about management security, it is possible to move management to separate VLAN and use management station inside that dedicated VLAN. Again no need for https. Managing switches over internet without using some kind of secure VPN is unwise (to put it mildly).
If one really needs all the bells and whistles, then it is possible to have it … by running ROS. And again: it is completely possible (and not too hard) to configure switch-only configuration using ROS. I’m not saying anybody should abandon SwOS, I’m just saying that for advanced configuration stuff (or security stuff for that matter) SwOS might be just too light-weight. And judging from sparse notes by MT team members, SwOS-oly units might even lack HW resources needed for anything more than plain http anyway.
I’d also vote/kindly ask for the cli or API support for the SwOS. It would be nice to be able to control the switch from the command line.
The argument against https support, I support: just keep your config access on a VLAN that is secure, then http is fine.
The argument to upgrade to ROS I do not support: not all devices are capable of that.
As for doing automated advanced management without a CLI, there might be two ways:
a. Through SNMP writes; does SwOS support those?
b. Through uploading generated configuration files.
I don’t think so. Could be wrong however.
b. Through uploading generated configuration files.
I’m doing that this week. I will be making a major shuffle of network arrangement of my data cabinet at home. As part of that I am adding a second CSS326 switch. I configured the new switch as the existing switch will become on Saturday and saved that config file. Then reconfigured the new switch to the way it will configured and saved that config. When I do my changes on Saturday, I plug my laptop into the existing switch and upload the saved config, and it should be ready to go.
As I just figured out, there actually is a third way:
c. Through the Javascript API that the web management console of SwOS already uses.
The lack of basic security concepts is shocking in this statement… a VLAN does not provide any protections against interception and manipulation (eg. the password is clear text over the wire)
A VLAN is good to secure the access path to the device, however it shouldn’t not be used for protecting the data over the wire/air
SSL is good at protecting the data whilst in transit, but does nothing to secure the access
If the cheaper/smaller guys (TP-Link etc) can do a switch with HTTPS then MikroTik sure can, heck pretty sure the TP-Links often have some basic CLI available too (shame they dont do passive PoE though…)
It is quite surprising HTTPS is missing from the devices, this may actually prevent us from using these switches in our deployment for compliance reasons (the CSS610 is a perfect device for small solar repeater locations)
All this worry makes no sense, because (just for cite something, and not all):
only an idiot would reuse the same username and password on a mainframe and a switch,
attractively, apart from disfiguring it, with the SwOS you can do nothing,
if someone have hacked the device on which you write the password, https or not, who cares…
if someone already intercept your traffic, “imagine” if it cares about the switch password…
https on SwOS? all b–s–t…
That seriously is the worst attitude to security, password reuse isn’t the only possible exploit, easily could do code injection etc
Pretty sure you would also change your mind if someone did a factory reset on your switch at an RTS thats 8 hours away, but sure who cares about enabling the most basic feature…
The serious question is what is holding MikroTik back from implementing it? SSL libraries are available for literally every architecture (most of them at no monetary cost)
At the same time, besides your very lacking security attitude, what is YOUR reasons that MikroTik shouldn’t implement it? how does them implementing it cause any issue for you?
I have not written everything, as already warned, but simply if I need to use a managed switch in sensitive points, I certainly do not go to put a switch with SwOS...
Such lack of imagination. 
Given admin access on a SwOS box, I can:
- create a transparent network tap
- permit DHCP poisoning
- fry unsuspecting nodes by applying forced passive PoE
- pierce VLAN barriers
- mangle traffic
…and doubtless more if I put my mind to it.
I’m all for the proposition that RouterOS is the right solution to the OP’s wish for more power, but SwOS is far from powerless.
@tangent, try to understand my point of view: Really impressive that there is really someone who makes all this effort to "annoy" a "home" network ...
Where you mean, inside SwOS or in http connection when you manage the switch?
If someone is already to that level, is too late…
I would be an idiot if I only counted on the correct functioning of a single device in a location so far away…
(and anyway, I would not use something with only SwOS regardless)
If HTTP on a remote, VPN-managed network, becomes a problem, what does that mean?
Has SwOS been configured to answer directly with a Public IP??? On this case the problem is not the HTTP but who manage the network…