On Wed, Feb 18, 2026 at 2:10 AM Saku Ytti <saku@ytti.fi> wrote:
On Wed, 18 Feb 2026 at 08:34, Christopher Morrow via NANOG <nanog@lists.nanog.org> wrote:
100% yes, I guess my question sort of is, in the year 2026, if you have: * automated updates to devices * ssh key support in your fleet * ability to enumerate the users / devices mapping necessary for your operations
would not using tac+ make more sense now?
We can definitely expand on this. We can also ask, why have >1 account to devices.
You can implement GUI, TUI or CLI access to a proxy code, which implements device specific commands and returns output from a given remote host. You can normalise experience regardless of platform or even enrich output from other systems potentially expediting debugging, but humans never interact directly with devices. You can have normalised logging and authentication on the proxy code. As the actual channel to remove can be SSH, netconf or telnet which can be always on, you can return output much faster using this approach, as you don't have to pay connect/auth tax. You can easily emulate legacy access via this code too, and expose the device under various loopback addresses which map to external devices, so legacy code can interact with it, as if it is a direct connection.
yes, I agree with almost all of the above, but I'd say there MAY still be need of more than 1 account. you MIGHT have something akin to: * RO user for human things that just NEVER need RW access * RW user with restrictions via the proxy system proposed * automaton accounts specific to the needs of those automatons - rancid user - device interface data scraper - provisioning robot * some fallback user/password which you'd already have deployed/etc - because sometimes that device is not actually connected to the network!! Moving the humans back to some proxy-based answer gets you back to a 'single point' to lock people out when the mythical Foo leaves the environment. An actual goal is to remove huamns from network device access
But the problem with the above is that someone needs to write and maintain the code. But at least you control the code, and feature velocity on it. So if you can spare the development hour, adding this middle layer can help immensely.
Yep! this is sort of a problem. There are lots of folks that can/don't have the time to build a thing like this... I don't think it's QUITE an hour's work :) but there's plenty of parts in place already to help you along the journey (perhaps this is Saku's point, though).
Problem with your quoted approach is that while you say thousands of users are fine on some devices, you also gave an example where it is a
I said you CAN do it I don't recommend it...(or that was my intent anyway) Somewhere between 'zero humans have acccess (except in emergency)' and 'we permit all humans unfettered wild-persona status!' is an answer for folks, I bet. The proxy answer you propose above is great (I think), but does bring with it some level of ongoing support by your org. That may be fine if you employ a slew of software types... I think my aim(after some questions) was to point out that: * "there are lots of ansible playbook versions of network management" * you CAN achieve a bunch of of the goal I was getting to with that path * you COULD extend to your answer if you have the skillset in house * a caution about adding a boatload of users to a NOS config (I really didn't mean that off handed comment set to mean that it was 'ok' to go adding a boatload of users, yea don't do that! :) )
problem. Which is an excellent reason not to do this, generally don't do anything strange on NOS, unless you absolutely must. You really don't want to be the customer that pushes the envelope with vendors to support larger numbers of users, or whatever it may be. You assert almost no control on the feature velocity.
agreed, most folk PROBABLY can just go the ansible playbook / ssh-keys route... without a ton of work or headache.
On the opposite end, you know that TACACS is not a strange thing, everyone else is working with the vendor too, when there are issues on it. If you want boring outcomes, do boring things.
yes, it took a while (and not all network vendors actually support tac+ still) for the majority of vendors to support tac+. If you don't get too far astray from the core option.
++ytti
thanks! :)