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
[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.
Yes, that's one of the ones in the FreeBSD ports.
Works very well.
Mark.
We have also used https://www.shrubbery.net/tac_plus/ for some time as well. Great product!
JM
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
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.
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”, and this new document largely says “Now just do that over TLS! kthxbye…”
Hopefully this draft will progress soon…
W
Hi Bryan,
https://tacacsgui.com/ it might be a good fit for you.
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
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.
Christopher Morrow writes:
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).
Christopher Morrow writes:
>>
>> 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 (GitHub - google/hiba: HIBA is a system built on top of regular OpenSSH certificate-based authentication that allows to manage flexible authorization of principals on pools of target hosts without the need to push customized authorized_users files periodically.) 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.
...
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.
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