Re: What are you guys doing for tacacs+ in 2026?

[Christopher Morrow via NANOG <nanog () lists nanog org>]

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! :)
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/2JJX7QCQHFXK6RV7K47BIJGSJMCAYDGC/