On Wed, Feb 18, 2026 at 2:10 AM Saku Ytti <[email protected]> wrote:
>
> On Wed, 18 Feb 2026 at 08:34, Christopher Morrow via NANOG
> <[email protected]> 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! :)
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/[email protected]/message/2JJX7QCQHFXK6RV7K47BIJGSJMCAYDGC/
