Mailing List Archive

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.

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
>

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

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:
> https://www.pro-bono-publico.de/projects/tac_plus.html


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

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
>

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:
>> https://www.pro-bono-publico.de/projects/tac_plus.html
>>
>
> 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
>

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

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 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.

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-Public-Key-Authentication

Just going to drop this in here ...https://fudosecurity.com/"]https://fudosecurity.com/"]Privileged Access Management Solutions for Enhanced Cybersecurity | PAM Systems | Fudo Securityhttps://fudosecurity.com/"]fudosecurity.comhttps://fudosecurity.com/"]
If you are looking for something a little more upbeat
-- J. Hellenthal
The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.

On Sep 22, 2023, at 16:00, Mike Lewinski via NANOG <nanog@nanog.org> wrote:

?

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-Public-Key-Authentication

In gmane.org.operators.nanog, Mike Lewinski via NANOG 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/

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:
>
> https://www.pro-bono-publico.de/projects/tac_plus.html

That one really looks good. Harder to package with the repository
containing several unrelated things like spawnd, ftpd and tcprelay, but
still possible.

Bernhard