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 -