On Tue, Feb 17, 2026 at 6:27 PM Andrew Latham <[email protected]> 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 > <[email protected]> wrote: > > > > On Tue, Feb 17, 2026 at 3:55 PM Andrew Latham <[email protected]> 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 > > > <[email protected]> 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 > > > > <[email protected]> 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 > > > > > <[email protected]> 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/[email protected]/message/REGURCJX4QAEZOEORGRO7TLFKTY36QPW/ > > > > > > > > > > > > > > > > > > > > -- > > > > > - Andrew "lathama" Latham - > > > > > _______________________________________________ > > > > > NANOG mailing list > > > > > https://lists.nanog.org/archives/list/[email protected]/message/MJTTEZIHC7EN66A4QQUB7QGFPNCJPX7A/ > > > > _______________________________________________ > > > > NANOG mailing list > > > > https://lists.nanog.org/archives/list/[email protected]/message/EVU26ZR5Q6B6NFIQCPMDNGG7FWPDPI7E/ > > > > > > > > > > > > -- > > > - Andrew "lathama" Latham - > > > > -- > - Andrew "lathama" Latham - _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/BBYESO35MTHFOZCPTJG5IVOW5QBQS43N/
