Ah, the good old days when I could download the latest tac_plus code from the Cisco FTP site, compile it, and off I go. But I digress. Curious if there are any operators out there that have a good recommendation on a lightweight TACACS+ server for ~200 NEs and access-control for 20-30 folks. Nothing too special, but some sort of simple command-control auth would be nice. Open-source is fine ... we've been looking at commercial options, but they're all pretty pricey and have way more features than we need. Thank you all in advance! - bryan
On 9/20/23 17:09, Bryan Holloway wrote:
Ah, the good old days when I could download the latest tac_plus code from the Cisco FTP site, compile it, and off I go.
But I digress.
Curious if there are any operators out there that have a good recommendation on a lightweight TACACS+ server for ~200 NEs and access-control for 20-30 folks. Nothing too special, but some sort of simple command-control auth would be nice.
Open-source is fine ... we've been looking at commercial options, but they're all pretty pricey and have way more features than we need.
Thank you all in advance!
[root@host /home/tinka]# cd /usr/ports/net/tac tac_plus4/ tacacs/ [root@host /home/tinka]# They work just fine. These are on FreeBSD, but I am sure they will compile on Linux too. Mark.
We have also used https://www.shrubbery.net/tac_plus/ for some time as well. Great product! JM On Wed, Sep 20, 2023 at 8:15 AM Mark Tinka <mark@tinka.africa> wrote:
On 9/20/23 17:09, Bryan Holloway wrote:
Ah, the good old days when I could download the latest tac_plus code from the Cisco FTP site, compile it, and off I go.
But I digress.
Curious if there are any operators out there that have a good recommendation on a lightweight TACACS+ server for ~200 NEs and access-control for 20-30 folks. Nothing too special, but some sort of simple command-control auth would be nice.
Open-source is fine ... we've been looking at commercial options, but they're all pretty pricey and have way more features than we need.
Thank you all in advance!
[root@host /home/tinka]# cd /usr/ports/net/tac tac_plus4/ tacacs/ [root@host /home/tinka]#
They work just fine.
These are on FreeBSD, but I am sure they will compile on Linux too.
Mark.
On 9/20/23 17:39, Jeff Moore wrote:
We have also used https://www.shrubbery.net/tac_plus/ for some time as well. Great product!
Yes, that's one of the ones in the FreeBSD ports. Works very well. Mark.
That tac_plus has python 2 dependencies and so has been removed from Debian packages. That's not surprising given the last update was 2015 and Python 2 was EOL in 2020: https://www.python.org/doc/sunset-python-2/ Currently I favor this one which is still being actively developed: https://www.pro-bono-publico.de/projects/tac_plus.html
On Wed, Sep 20, 2023 at 11:16 AM Mike Lewinski via NANOG <nanog@nanog.org> wrote:
https://www.shrubbery.net/tac_plus/ That tac_plus has python 2 dependencies and so has been removed from Debian packages. That's not surprising given the last update was 2015 and Python 2 was EOL in 2020: https://www.python.org/doc/sunset-python-2/
Currently I favor this one which is still being actively developed:
Yes. Well, on the plus side the TACACS protocol has not really changed in 30 years, Even the 2015 code could work provided you can compile its dependencies from sources, right... On the downside, for the command authorization use: TACACS+ provides little protection for messages between client and server; The protocol's MD5 crypto is so weak that routers using TACACS+ for authentication might as well just be piping over user credentials in the clear: it's barely any better. Router operating systems still typically use only passwords with SSH, then those devices send the passwords over that insecure channel. I have yet to see much in terms of routers capable to Tacacs+ Authorize users based on users' openSSH certificate, Public key id, or ed2559-sk security key id, etc. In short.. unless you got a VPN or a dedicated secure link from every single device to its Tacacs server or an Experimental implementation of TACACS+ over TLS: I would suggest consider Using tools or scripts to distribute users and Authorizing configurations to devices as local authorization through secure protocols as favorable to those network authentication systems that transmit sensitive decisions and user data across the network using Insecure protocols. -- -Jim
On Wed, Sep 20, 2023 at 10:22 AM, Jim <mysidia@gmail.com> wrote:
On Wed, Sep 20, 2023 at 11:16 AM Mike Lewinski via NANOG <nanog@nanog.org> wrote:
https://www.shrubbery.net/tac_plus/ That tac_plus has python 2 dependencies and so has been removed from Debian packages. That's not surprising given the last update was 2015 and Python 2 was EOL in 2020: https://www.python.org/doc/sunset-python-2/
Currently I favor this one which is still being actively developed:
Yes. Well, on the plus side the TACACS protocol has not really changed in 30 years, Even the 2015 code could work provided you can compile its dependencies from sources, right...
On the downside, for the command authorization use: TACACS+ provides little protection for messages between client and server;
The protocol's MD5 crypto is so weak that routers using TACACS+ for authentication might as well just be piping over user credentials in the clear: it's barely any better.
Yes, but there is current work in the IETF OpsAWG WG to help address this: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/ This work was actually started many years ago, but got sidetracked — there was no published standard for TACACS, and so we first published RFC8907 - "The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol" <https://datatracker.ietf.org/doc/rfc8907/>, and this new document largely says "Now just do that over TLS! kthxbye…" Hopefully this draft will progress soon… W
Router operating systems still typically use only passwords with SSH, then those devices send the passwords over that insecure channel. I have yet to see much in terms of routers capable to Tacacs+ Authorize users based on users' openSSH certificate, Public key id, or ed2559-sk security key id, etc.
In short.. unless you got a VPN or a dedicated secure link from every single device to its Tacacs server or an Experimental implementation of TACACS+ over TLS: I would suggest consider Using tools or scripts to distribute users and Authorizing configurations to devices as local authorization through secure protocols as favorable to those network authentication systems that transmit sensitive decisions and user data across the network using Insecure protocols.
-- -Jim
On Wed, Sep 20, 2023 at 1:22 PM Jim <mysidia@gmail.com> wrote:
Router operating systems still typically use only passwords with SSH, then those devices send the passwords over that insecure channel. I have yet to see much in terms of routers capable to Tacacs+ Authorize users based on users' openSSH certificate, Public key id, or ed2559-sk security key id, etc.
There is active work with vendors (3 or 4 of the folk you may even use?) to support ssh with ssh-certificates, I believe this mostly works today, though configuring it and distributing your ssh-ca-cert may be fun... There are also fairly clear paths to get ssh-keys (rsa, ecdsa) working for user-auth on those same 4 vendors. you will, of course, want some method to manage user-owned-key-material and distribution/rotation of that material to the network. You CAN enable 'key authentication' and have tac+ authorization/accounting still on the numbered vendors from above as well. -chris
Christopher Morrow writes:
On Wed, Sep 20, 2023 at 1:22 PM Jim <mysidia@gmail.com> wrote:
Router operating systems still typically use only passwords with SSH, then those devices send the passwords over that insecure channel. I have yet to see much in terms of routers capable to Tacacs+ Authorize users based on users' openSSH certificate, Public key id, or ed2559-sk security key id, etc.
There is active work with vendors (3 or 4 of the folk you may even use?) to support ssh with ssh-certificates, I believe this mostly works today, though configuring it and distributing your ssh-ca-cert may be fun...
Ahem... Cisco supports SSH authentication using *X.509* certificates. Unfortunately this is not compatible with OpenSSH (the dominant SSH client implementation we use), which only supports *OpenSSH* certificates. Not sure about other vendors, but when we found this out we decided that this wasn't a workable solution for us. -- Simon.
On Thu, Sep 21, 2023 at 4:40 AM Simon Leinen <simon.leinen@switch.ch> wrote:
Ahem... Cisco supports SSH authentication using *X.509* certificates. Unfortunately this is not compatible with OpenSSH (the dominant SSH
It's not a great solution, but it is certainly a solution. The feature exists for some routers/switch models running certain licenses/images... an existing 200 NE network is not likely to have the feature 100% available by accident, though. On the other hand: the strategy of using local auth on devices and having a few local users with specific privilege levels, and centralized systems that manage the ones creds for all normal day-to-day usage: Storage and frequent automatic rotation of passwords, and when an operator needs to login: the central system authorize a privileged User to access, Either "check out" a device using AAA to decide who can check out which devices, Or users run their SSH sessions through centralized connection managers (Acting as a man-in-the-middle authenticating to devices using its own credentials. Authorizing user commands proxied through the server) - Allows AAA and command authorization to be performed by the central server. My understanding is a good number of password manager products exists which will handle that, and then the only AAA which network devices need to be concerned about for Authentication and Authorization is Basic password auth, which all equipment supports. And the security problems don't arise so much for using the TACACS+ / Tac_plus service Solely for Accounting (in addition to basic remote syslog). client implementation we use), which only supports *OpenSSH*
certificates.
-- -Jim
On Thu, Sep 21, 2023 at 6:56 AM Jim <mysidia@gmail.com> wrote: ...
My understanding is a good number of password manager products exists which will handle that, and then the only AAA which network devices need to be concerned about for Authentication and Authorization is Basic password auth, which all equipment supports. And the security problems don't arise so much for using the TACACS+ / Tac_plus service Solely for Accounting (in addition to basic remote syslog).
it's important to recognize that there's not really any protection (practical protection) from MITM if you use a passwd with your ssh connection. A key'd authentication has these protections, as a quirk of the ssh protocol... (or a design feature if you wish) A certificate authenticated session has these same protections.
Is anyone using two factor authentication for network devices? Getting ready to re-do our authentication infrastructure and was curious if this is common. We are noticing a lot of Active Directory based two factor solutions as well as some TACACS solutions that have already been mentioned that can use AD as the backend. Also curious if others have tried this and noticed any obvious downsides. Thanks! Kevin Burke 802-540-0979 Burlington Telecom 200 Church St, Burlington, VT
Curious about this as well. We are using Okta's RADIUS service for 2fa to network gear currently, but looking to switch to tacacs+ for many reasons. Would prefer to implement tacacs+ with two-factor if possible. ________________________________ From: NANOG <nanog-bounces+tim=mid.net@nanog.org> on behalf of Kevin Burke via NANOG <nanog@nanog.org> Sent: Friday, September 22, 2023 1:53 PM To: North American Network Operators Group <nanog@nanog.org> Subject: RE: TACACS+ server recommendations? Is anyone using two factor authentication for network devices? Getting ready to re-do our authentication infrastructure and was curious if this is common. We are noticing a lot of Active Directory based two factor solutions as well as some TACACS solutions that have already been mentioned that can use AD as the backend. Also curious if others have tried this and noticed any obvious downsides. Thanks! Kevin Burke 802-540-0979 Burlington Telecom 200 Church St, Burlington, VT
It seems they can do it: https://www.miniorange.com/iam/solutions/tacacs-authentication From: NANOG <nanog-bounces+avargasn=gmail.com@nanog.org> on behalf of Tim Burke <tim@mid.net> Date: Friday, 22 September 2023 17:32 To: North American Network Operators Group <nanog@nanog.org>, Kevin Burke <kburke@burlingtontelecom.com> Subject: Re: TACACS+ server recommendations? Curious about this as well. We are using Okta's RADIUS service for 2fa to network gear currently, but looking to switch to tacacs+ for many reasons. Would prefer to implement tacacs+ with two-factor if possible. ________________________________ From: NANOG <nanog-bounces+tim=mid.net@nanog.org> on behalf of Kevin Burke via NANOG <nanog@nanog.org> Sent: Friday, September 22, 2023 1:53 PM To: North American Network Operators Group <nanog@nanog.org> Subject: RE: TACACS+ server recommendations? Is anyone using two factor authentication for network devices? Getting ready to re-do our authentication infrastructure and was curious if this is common. We are noticing a lot of Active Directory based two factor solutions as well as some TACACS solutions that have already been mentioned that can use AD as the backend. Also curious if others have tried this and noticed any obvious downsides. Thanks! Kevin Burke 802-540-0979 Burlington Telecom 200 Church St, Burlington, VT
We are using Okta's RADIUS service for 2fa to network gear currently, but looking to switch to tacacs+ for many reasons. Would prefer to implement tacacs+ with two-factor if possible.
tac_plus-ng from https://www.pro-bono-publico.de/projects/tac_plus-ng.html has LDAP and PAM backends, among others, so I believe you can implement 2FA through them. I haven't implemented this yet but it's on my to-do list (and I'm also warily watching passkey developments and wondering how much effort I should put into something that likely won't be best practice in another year or two). I see Marc Huber is also promoting/supporting tacacs+ extension for SSH public key auth https://github.com/MarcJHuber/event-driven-servers/wiki/TACACS_PLUS---SSH-Pu...
On Thu, Sep 21, 2023 at 5:40 AM Simon Leinen <simon.leinen@switch.ch> wrote:
Christopher Morrow writes:
On Wed, Sep 20, 2023 at 1:22 PM Jim <mysidia@gmail.com> wrote:
Router operating systems still typically use only passwords with SSH, then those devices send the passwords over that insecure channel. I have yet to see much in terms of routers capable to Tacacs+ Authorize users based on users' openSSH certificate, Public key id, or ed2559-sk security key id, etc.
There is active work with vendors (3 or 4 of the folk you may even use?) to support ssh with ssh-certificates, I believe this mostly works today, though configuring it and distributing your ssh-ca-cert may be fun...
Ahem... Cisco supports SSH authentication using *X.509* certificates.
correct, we pointed this out a few times and ... they now also support ssh-certs. They also support HIBA extensions (https://github.com/google/hiba) and the stock hiba-chk which means you could potentially mint a certificate for your ops user that says: "Simon is authorized to login to DEVICEX only" (and or others, or not have this check... this is optional, but handy for me)
Unfortunately this is not compatible with OpenSSH (the dominant SSH client implementation we use), which only supports *OpenSSH* certificates.
yup, that's what we pointed out to them.. I think their answer was something like: "mumble, we implemented this for a single requesting organization... we THINK they use it?" unsure hwo they use it, but.. ok, sure. now there's openssh cert capability though. (I admit I can't make search on cisco's site work for me to find what version introduced this though, sorry)
Not sure about other vendors, but when we found this out we decided that this wasn't a workable solution for us.
it sure wasn't for a long time :( 3 of 4 vendors we deal with support openssh-certificates and hiba... almost all to the point were we could actually use it, which is nice. we have some pains on our side, they on theirs, but it's getting almost deployable.
In gmane.org.operators.nanog, Mike Lewinski via NANOG wrote:
That tac_plus has python 2 dependencies and so has been removed from Debian packages. That's not surprising given the last update was 2015 and Python 2 was EOL in 2020: https://www.python.org/doc/sunset-python-2/
I have recently looked at this from the Debian side of things because I was also hit by the (not unexpected due to the python2 usage) removal from bookworm. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024129 --- There are multitude of issues with the current codebase and so far I'm not sure whether all of them can be solved. - latest Debian package had 4.0.4.27a from 2013 - latest official release is 4.0.4.28 from January 2015 - there is a 4.0.4.29a from March 2015 in the alpha/ directory of the upstream FTP server There is at least one known fork of 4.0.4.28 from Facebook at https://github.com/facebook/tac_plus . The project started good but looks dead. There are however a few interesting open pull requests that appear to fix errors on RHEL9, that should be sufficiently close to us. The thing that lead to the removal from Debian was python2. Glancing at the code I could not figure out the reason for the build-time dependency. There is a python script installed in the tacacs+ binary package (do_auth.py). Not everyone uses that. We don't, so I cannot fully test it. But at first glance it appears to be able to be run on python3 by just dropping the future imports. And there is an official python3 port by it's original author at https://www.tacacs.org/ So I think using the Facebook fork with a few imported pull-requests and maybe switching to the newer do_auth.py (in a seperate binary package while we are at it) could do the trick. ---
Currently I favor this one which is still being actively developed:
That one really looks good. Harder to package with the repository containing several unrelated things like spawnd, ftpd and tcprelay, but still possible. Bernhard
On Wed, Sep 20, 2023 at 8:09 AM, Bryan Holloway <bryan@shout.net> wrote:
Ah, the good old days when I could download the latest tac_plus code from the Cisco FTP site, compile it, and off I go.
You might be thinking of the Shrubbery one — https://www.shrubbery.net/tac_plus/ There are newer, fancier, etc ones - but this Just Works. W
But I digress.
Curious if there are any operators out there that have a good recommendation on a lightweight TACACS+ server for ~200 NEs and access-control for 20-30 folks. Nothing too special, but some sort of simple command-control auth would be nice.
Open-source is fine ... we've been looking at commercial options, but they're all pretty pricey and have way more features than we need.
Thank you all in advance!
- bryan
Hi Bryan, https://tacacsgui.com/ it might be a good fit for you. Em qua., 20 de set. de 2023 às 12:10, Bryan Holloway <bryan@shout.net> escreveu:
Ah, the good old days when I could download the latest tac_plus code from the Cisco FTP site, compile it, and off I go.
But I digress.
Curious if there are any operators out there that have a good recommendation on a lightweight TACACS+ server for ~200 NEs and access-control for 20-30 folks. Nothing too special, but some sort of simple command-control auth would be nice.
Open-source is fine ... we've been looking at commercial options, but they're all pretty pricey and have way more features than we need.
Thank you all in advance!
- bryan
from a commercial perspective, we've been using Radiator for the last ~7 years....been working really well, super flexible in terms of user group permissions, authorized commands etc + the upside for us was logging auth logs to SQL, both authentication and authorization logs....it's primarily aimed as a radius product but has excellent tacacs daemon capabilities. On Thu, Sep 21, 2023 at 1:12 AM Bryan Holloway <bryan@shout.net> wrote:
Ah, the good old days when I could download the latest tac_plus code from the Cisco FTP site, compile it, and off I go.
But I digress.
Curious if there are any operators out there that have a good recommendation on a lightweight TACACS+ server for ~200 NEs and access-control for 20-30 folks. Nothing too special, but some sort of simple command-control auth would be nice.
Open-source is fine ... we've been looking at commercial options, but they're all pretty pricey and have way more features than we need.
Thank you all in advance!
- bryan
participants (15)
-
Alberto Vargas -
Bernhard Schmidt -
Bryan Holloway -
Christopher Morrow -
Douglas Hirata de Moura -
Drikus Brits -
J. Hellenthal -
Jeff Moore -
Jim -
Kevin Burke -
Mark Tinka -
Mike Lewinski -
Simon Leinen -
Tim Burke -
Warren Kumari