I have seen / heard good things about https://github.com/christian-becker/tac_plus-ng but of course no personal experience. Alpine linux with Docker. From: Drew Weaver via NANOG <nanog@lists.nanog.org> Date: Tuesday, 10 February 2026 at 8:38 PM To: 'North American Network Operators Group' <nanog@lists.nanog.org> Cc: Drew Weaver <drew.weaver@thenap.com> Subject: What are you guys doing for tacacs+ in 2026? Howdy. I imagine that this is an issue that has come up before but I am having an issue finding how anyone else handled it. (Unless everyone is still running tac_plus on RHEL7) I'm trying to migrate some tac plus instances to a new Linux distro that apparently doesn't support tcp_wrappers and I'm having trouble both compiling it and making an RPM for it. I've tried both the original https://www.shrubbery.net/tac_plus/ and the now sadly abandoned Facebook version https://github.com/facebook/tac_plus If there is another tacacs+ solution everyone has moved to that I am unaware of please enlighten me. Thank you, -Drew _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/REGURCJX...

no idea what people use. But FreeRADIUS supports tacacs+ in v4: https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/sites-avai... Bjørn

I’m not using tcp_wrappers I was just trying to build something that needed it but I think I already figured it out by looking through the rpm spec. Thanks, -Drew From: Jonathan Lassoff <jof@thejof.com> Sent: Tuesday, February 10, 2026 10:19 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Drew Weaver <drew.weaver@thenap.com> Subject: Re: What are you guys doing for tacacs+ in 2026? tcp_ wrappers is pretty dated. Maybe move to using iptables/netfilter? In terms of newer software for TACACS+, Tacquito is decent: https://github.com/facebookincubator/tacquito<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_facebookincubator_tacquito&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=90gkWo7kVvejNfQmbLf_nFPFontgjwZKPouPX5uiacioaXD-_bMHfdM33Lcqw__U&s=ybBxdKkTMKSgZ2NISFsLGJr0XjF6IDw8GhDlqAKs-TE&e=> Cheers, jof On Tue, Feb 10, 2026 at 07:08 Drew Weaver via NANOG <nanog@lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Howdy. I imagine that this is an issue that has come up before but I am having an issue finding how anyone else handled it. (Unless everyone is still running tac_plus on RHEL7) I'm trying to migrate some tac plus instances to a new Linux distro that apparently doesn't support tcp_wrappers and I'm having trouble both compiling it and making an RPM for it. I've tried both the original https://www.shrubbery.net/tac_plus/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.shrubbery.net_tac-5Fplus_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=90gkWo7kVvejNfQmbLf_nFPFontgjwZKPouPX5uiacioaXD-_bMHfdM33Lcqw__U&s=CUPi5Wn7hd7zYDhi1qioan7i57kWReHINdlM0ucfY88&e=> and the now sadly abandoned Facebook version https://github.com/facebook/tac_plus<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_facebook_tac-5Fplus&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=90gkWo7kVvejNfQmbLf_nFPFontgjwZKPouPX5uiacioaXD-_bMHfdM33Lcqw__U&s=WJ8j1UZ8sWNBISASDX1LY9ARye35p7KTb2R6taHMQPg&e=> If there is another tacacs+ solution everyone has moved to that I am unaware of please enlighten me. Thank you, -Drew _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/REGURCJX4QAEZOEORGRO7TLFKTY36QPW/<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.nanog.org_archives_list_nanog-40lists.nanog.org_message_REGURCJX4QAEZOEORGRO7TLFKTY36QPW_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=90gkWo7kVvejNfQmbLf_nFPFontgjwZKPouPX5uiacioaXD-_bMHfdM33Lcqw__U&s=fL7ogmT5d3L0djXXI3eqTQn9o83WqARlxY3wkq4iEi0&e=>

hey,

https://radiatorsoftware.com/products/radiator/

+1 for radiator, happily using this (the perl version) for both tacacs and radius for many-many years. -- tarko

Hi Drew, I'll answer in private to not reincinerate the OS wars. We're running tac_plus, and have been since... forever. We have not painted ourselves into a corner by using Linux, though. FreeBSD has a still-maintained package which works well; it needs a restart every two months or so, but is happy otherwise. I know this won't help you much, except maybe to think a bit outside the Linux box. Cheers, Elmar. nanog@lists.nanog.org (Drew Weaver via NANOG) wrote:

Howdy.

I imagine that this is an issue that has come up before but I am having an issue finding how anyone else handled it. (Unless everyone is still running tac_plus on RHEL7)

I'm trying to migrate some tac plus instances to a new Linux distro that apparently doesn't support tcp_wrappers and I'm having trouble both compiling it and making an RPM for it.

I've tried both the original https://www.shrubbery.net/tac_plus/ and the now sadly abandoned Facebook version https://github.com/facebook/tac_plus

If there is another tacacs+ solution everyone has moved to that I am unaware of please enlighten me.

Thank you, -Drew

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/REGURCJX...

You are making a big ask Elmar, by your absolutely wild rationale, hope it'll pay out :) On Wed, 11 Feb 2026 at 10:08, Elmar K. Bins via NANOG <nanog@lists.nanog.org> wrote:

Yeah, well, turns out I'm too stupid to check recipients before sending. Please let's not start an OS war...

Elmar.

nanog@lists.nanog.org (Elmar K. Bins via NANOG) wrote:

...

Hi Drew, I'll answer in private to not reincinerate the OS wars. We're running tac_plus, and have been since... forever. We have not painted ourselves into a corner by using Linux, though. FreeBSD has a still-maintained package which works well; it needs a restart every two months or so, but is happy otherwise.

I know this won't help you much, except maybe to think a bit outside the Linux box.

Cheers, Elmar.

nanog@lists.nanog.org (Drew Weaver via NANOG) wrote:

...

Howdy.

I imagine that this is an issue that has come up before but I am having an issue finding how anyone else handled it. (Unless everyone is still running tac_plus on RHEL7)

I'm trying to migrate some tac plus instances to a new Linux distro that apparently doesn't support tcp_wrappers and I'm having trouble both compiling it and making an RPM for it.

I've tried both the original https://www.shrubbery.net/tac_plus/ and the now sadly abandoned Facebook version https://github.com/facebook/tac_plus

If there is another tacacs+ solution everyone has moved to that I am unaware of please enlighten me.

Thank you, -Drew

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/H4EIWLBD...

-- ++ytti

As far as I can see FreeBSD ports ship two tacacs a) shrubbery - in no different state to any other OS - which specifically OP signalled problem against b) tacplus by christian becker - in no different state to any other OS - upstream is specifically asking you not to use it, and to move to tacplus-ng, which they support, which I don't see in ports Elmar framed their argument in a very inflammatory way, claiming that somehow one OS boxes in your selection of applications while another OS does not, supported by no actual arguments. It was further claimed that the package is somehow more maintained than in other OS, offering no arguments why it would be so. As far as I looked at both FreeBSD ports, they make no changes of relevance to upstream or contribute to upstream so they offer no solution that upstream doesn't. Therefore no meaningful delta to any other OS running the same software. I'm assuming most people in this list will not consider the choice of OS important, and accept that people use OS that their organisation is comfortable with. If you run TACACS on your Windows AD server, that may be a very good choice for the set of problems you're solving with the organisation you have. Other companies may do something entirely different and be no more or less correct in doing so. There are certainly long tail use cases where kernel becomes an important differentiator, for running TACACS it's not. It is hard to see this as anything else, but as an explicit attempt to inject OS discussion somewhere where it didn't belong and didn't help OP in any way, but to add confusion. On Wed, 11 Feb 2026 at 18:16, Chris via NANOG <nanog@lists.nanog.org> wrote:

...

Hi Drew, I'll answer in private to not reincinerate the OS wars. We're running tac_plus, and have been since... forever. We have not painted ourselves into a corner by using Linux, though. FreeBSD has a still-maintained package which works well; it needs a restart every two months or so, but is happy otherwise. I was going to suggest the same. We've been on FBSD for *decades* and have zero

On 2026-02-11 00:05, Elmar K. Bins via NANOG wrote: problems. As an added bonus, it'll run most linux apps either directly, or a complete (linux) system in a VM or jail.

HTH

--Chris

...

I know this won't help you much, except maybe to think a bit outside the Linux box.

Cheers, Elmar.

nanog@lists.nanog.org (Drew Weaver via NANOG) wrote:

...

Howdy.

I imagine that this is an issue that has come up before but I am having an issue finding how anyone else handled it. (Unless everyone is still running tac_plus on RHEL7)

I'm trying to migrate some tac plus instances to a new Linux distro that apparently doesn't support tcp_wrappers and I'm having trouble both compiling it and making an RPM for it.

I've tried both the original https://www.shrubbery.net/tac_plus/ and the now sadly abandoned Facebook version https://github.com/facebook/tac_plus

If there is another tacacs+ solution everyone has moved to that I am unaware of please enlighten me.

Thank you, -Drew

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/REGURCJX...

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KPFGMHQ4...

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BTL5MFFL...

-- ++ytti

b) tacplus by christian becker by Marc Huber

apologies for my confusion -- ++ytti

Untested but I also see: A. https://github.com/salesforce/tacrust B. https://github.com/SaschaSchwarzK/tacacs_server I think B looks interesting On Tue, Feb 10, 2026 at 8:08 AM Drew Weaver via NANOG <nanog@lists.nanog.org> wrote:

Howdy.

I imagine that this is an issue that has come up before but I am having an issue finding how anyone else handled it. (Unless everyone is still running tac_plus on RHEL7)

I'm trying to migrate some tac plus instances to a new Linux distro that apparently doesn't support tcp_wrappers and I'm having trouble both compiling it and making an RPM for it.

I've tried both the original https://www.shrubbery.net/tac_plus/ and the now sadly abandoned Facebook version https://github.com/facebook/tac_plus

If there is another tacacs+ solution everyone has moved to that I am unaware of please enlighten me.

Thank you, -Drew

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/REGURCJX...

-- - Andrew "lathama" Latham -

Can I ask a possibly leading question: "Why do you want to use tacacs in the first place?" Possible answers are: 1) we have always been at war with elbonia, so we continue to be at war with elbonia 2) we like 1 central place to manage access / authorization and we desire the collection of accounting type data so we know when Foo did Bar to Baz. 3) we like that when Foo leaves our orbit we can disable Foo's access 'instantly', in one place. 4) we don't have a method to manage config updates to every single relevant device in a timeperiod which our mgmt/security-folks believe is ok for when Foo leaves our orbit. You can enable tacacs-accounting only on most network OSs (not junos, darn!), and you can do ssh-key authentication (or cert auth, on most now?), you'd be having to sacrifice the timeline between: 'Foo leaves' and 'all devices updated to remove Foo's account'. Also, you'd want to be in a situation where you weren't trying to manage O(1000) users on any of these platforms. (I know you can shovel ~7k users on an arista of current flavor, and a juniper of same flavor... the initial commit time is 'stupendous' though :) - do not try this on a ciscoXR device was my recollection) You can also set some relatively clear authorization config on devices for read-only-ish or read-write account priveleges, on cisco/arista/juniper... anyway, why do you want to use tacacs? (for authorization and authentication) On Wed, Feb 11, 2026 at 12:37 PM Andrew Latham via NANOG <nanog@lists.nanog.org> wrote:

Untested but I also see:

A. https://github.com/salesforce/tacrust B. https://github.com/SaschaSchwarzK/tacacs_server

I think B looks interesting

On Tue, Feb 10, 2026 at 8:08 AM Drew Weaver via NANOG <nanog@lists.nanog.org> wrote:

...

Howdy.

I imagine that this is an issue that has come up before but I am having an issue finding how anyone else handled it. (Unless everyone is still running tac_plus on RHEL7)

I'm trying to migrate some tac plus instances to a new Linux distro that apparently doesn't support tcp_wrappers and I'm having trouble both compiling it and making an RPM for it.

I've tried both the original https://www.shrubbery.net/tac_plus/ and the now sadly abandoned Facebook version https://github.com/facebook/tac_plus

If there is another tacacs+ solution everyone has moved to that I am unaware of please enlighten me.

Thank you, -Drew

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/REGURCJX...

-- - Andrew "lathama" Latham - _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MJTTEZIH...

On Tue, Feb 17, 2026 at 3:55 PM Andrew Latham <lathama@gmail.com> wrote:

Christopher

chris is fine :) (sorry, a long long long time ago someone picked my username for me... oops!)

I will not speak for OP but I have in my career dealt with contractual requirements, government mandates, and other silly-ness. I once worked on an emergency where a sales person had sold a 25 year contract on a tech stack and we had to show that updating the cryptography was an allowable change with 19 years left on the contract.

Oh sure I've seen this form of problem. that's a fair thing, my list was mostly a way to get the conversation going and to suss out 'why exactly?' :) Thanks for the other optional reason. I do suspect that MOST regulators / compliance regimes provide the flexibility to change these sorts of things if requested and if enough proper reasoning is provided, that's been my experience at any rate. Now, do you want to do that? maybe? or "still works, got other problems to slay".

TL;DR;

5) we have a requirement carved in marble in the lobby

On Tue, Feb 17, 2026 at 1:12 PM Christopher Morrow via NANOG <nanog@lists.nanog.org> wrote:

...

Can I ask a possibly leading question: "Why do you want to use tacacs in the first place?"

Possible answers are: 1) we have always been at war with elbonia, so we continue to be at war with elbonia 2) we like 1 central place to manage access / authorization and we desire the collection of accounting type data so we know when Foo did Bar to Baz. 3) we like that when Foo leaves our orbit we can disable Foo's access 'instantly', in one place. 4) we don't have a method to manage config updates to every single relevant device in a timeperiod which our mgmt/security-folks believe is ok for when Foo leaves our orbit.

You can enable tacacs-accounting only on most network OSs (not junos, darn!), and you can do ssh-key authentication (or cert auth, on most now?), you'd be having to sacrifice the timeline between: 'Foo leaves' and 'all devices updated to remove Foo's account'. Also, you'd want to be in a situation where you weren't trying to manage O(1000) users on any of these platforms. (I know you can shovel ~7k users on an arista of current flavor, and a juniper of same flavor... the initial commit time is 'stupendous' though :) - do not try this on a ciscoXR device was my recollection)

You can also set some relatively clear authorization config on devices for read-only-ish or read-write account priveleges, on cisco/arista/juniper...

anyway, why do you want to use tacacs? (for authorization and authentication)

On Wed, Feb 11, 2026 at 12:37 PM Andrew Latham via NANOG <nanog@lists.nanog.org> wrote:

...

Untested but I also see:

A. https://github.com/salesforce/tacrust B. https://github.com/SaschaSchwarzK/tacacs_server

I think B looks interesting

On Tue, Feb 10, 2026 at 8:08 AM Drew Weaver via NANOG <nanog@lists.nanog.org> wrote:

...

Howdy.

I imagine that this is an issue that has come up before but I am having an issue finding how anyone else handled it. (Unless everyone is still running tac_plus on RHEL7)

I'm trying to migrate some tac plus instances to a new Linux distro that apparently doesn't support tcp_wrappers and I'm having trouble both compiling it and making an RPM for it.

I've tried both the original https://www.shrubbery.net/tac_plus/ and the now sadly abandoned Facebook version https://github.com/facebook/tac_plus

If there is another tacacs+ solution everyone has moved to that I am unaware of please enlighten me.

Thank you, -Drew

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/REGURCJX...

-- - Andrew "lathama" Latham - _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MJTTEZIH...

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EVU26ZR5...

-- - Andrew "lathama" Latham -

On Tue, Feb 17, 2026 at 6:27 PM Andrew Latham <lathama@gmail.com> wrote:

Chris

To answer your question:

A. There needs to be some current supported options for people to move legacy setups forward. (Then they can decide to change.)

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?

B. The youth need a chance to setup labs with legacy things so they can understand grumpy old person rambling rants.

meh? really? I mean ssh is ssh with or withoout tac+. I suppose the mechanics of setting up the ssh-keys in configs for N vendors might be a bit to get settled with.

C. Golf course management discussions rarely mention TACACS let alone the +

ha :) I've said this about IP numbers :( "What's your phone number again??" is all the 'numbers' that get time.

PS We worked together several years ago and I only thought of your username. :P

:) haha

On Tue, Feb 17, 2026 at 3:06 PM Christopher Morrow <morrowc.lists@gmail.com> wrote:

...

On Tue, Feb 17, 2026 at 3:55 PM Andrew Latham <lathama@gmail.com> wrote:

...

Christopher

chris is fine :) (sorry, a long long long time ago someone picked my username for me... oops!)

...

I will not speak for OP but I have in my career dealt with contractual requirements, government mandates, and other silly-ness. I once worked on an emergency where a sales person had sold a 25 year contract on a tech stack and we had to show that updating the cryptography was an allowable change with 19 years left on the contract.

Oh sure I've seen this form of problem. that's a fair thing, my list was mostly a way to get the conversation going and to suss out 'why exactly?' :)

Thanks for the other optional reason. I do suspect that MOST regulators / compliance regimes provide the flexibility to change these sorts of things if requested and if enough proper reasoning is provided, that's been my experience at any rate. Now, do you want to do that? maybe? or "still works, got other problems to slay".

...

TL;DR;

5) we have a requirement carved in marble in the lobby

On Tue, Feb 17, 2026 at 1:12 PM Christopher Morrow via NANOG <nanog@lists.nanog.org> wrote:

...

Can I ask a possibly leading question: "Why do you want to use tacacs in the first place?"

Possible answers are: 1) we have always been at war with elbonia, so we continue to be at war with elbonia 2) we like 1 central place to manage access / authorization and we desire the collection of accounting type data so we know when Foo did Bar to Baz. 3) we like that when Foo leaves our orbit we can disable Foo's access 'instantly', in one place. 4) we don't have a method to manage config updates to every single relevant device in a timeperiod which our mgmt/security-folks believe is ok for when Foo leaves our orbit.

You can enable tacacs-accounting only on most network OSs (not junos, darn!), and you can do ssh-key authentication (or cert auth, on most now?), you'd be having to sacrifice the timeline between: 'Foo leaves' and 'all devices updated to remove Foo's account'. Also, you'd want to be in a situation where you weren't trying to manage O(1000) users on any of these platforms. (I know you can shovel ~7k users on an arista of current flavor, and a juniper of same flavor... the initial commit time is 'stupendous' though :) - do not try this on a ciscoXR device was my recollection)

You can also set some relatively clear authorization config on devices for read-only-ish or read-write account priveleges, on cisco/arista/juniper...

anyway, why do you want to use tacacs? (for authorization and authentication)

On Wed, Feb 11, 2026 at 12:37 PM Andrew Latham via NANOG <nanog@lists.nanog.org> wrote:

...

Untested but I also see:

A. https://github.com/salesforce/tacrust B. https://github.com/SaschaSchwarzK/tacacs_server

I think B looks interesting

On Tue, Feb 10, 2026 at 8:08 AM Drew Weaver via NANOG <nanog@lists.nanog.org> wrote:

...

Howdy.

I imagine that this is an issue that has come up before but I am having an issue finding how anyone else handled it. (Unless everyone is still running tac_plus on RHEL7)

I'm trying to migrate some tac plus instances to a new Linux distro that apparently doesn't support tcp_wrappers and I'm having trouble both compiling it and making an RPM for it.

I've tried both the original https://www.shrubbery.net/tac_plus/ and the now sadly abandoned Facebook version https://github.com/facebook/tac_plus

If there is another tacacs+ solution everyone has moved to that I am unaware of please enlighten me.

Thank you, -Drew

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/REGURCJX...

-- - Andrew "lathama" Latham - _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MJTTEZIH...

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EVU26ZR5...

-- - Andrew "lathama" Latham -

-- - Andrew "lathama" Latham -

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! :)