AAA, TACACS+, and SSH: Which to Use and When

Say you've got a network environment that's all bottled up and secure with AAA running. But now you've got a new router with no security on it — and you need to add it to the network. If you had to configure SSH, get TACACS+ working on it, and lock it down, how long would it take you? Follow along with us and we'll show you how to get a router at Security Level 0 connected to a AAA server in about five minutes.

What Are AAA and AAA Servers?

Quick Definition: In the networking world, AAA stands for Authentication, Authorization, and Accounting – an AAA server is used for access control and security. Usually pronounced "triple-A", a AAA server is a network server that helps keep the wrong people out of your network while getting the right people to the network resources.

AAA's first "A", Authentication, identifies each user. The second, Authorization, is in charge of policies that decide which resources and services each user can have access to. The third "A", Accounting, helps track and monitor what time and data resources are used for billing and analysis.

What is TACACS+?

Quick Definition: TACACS+ is an open standard security protocol used for providing centralized validation of any user trying to access a router or network access server. It was developed by Cisco for authentication, authorization and accounting services. TACACS+ stands for Terminal Access Controller Access-Control System Plus, but it shouldn't be mistaken for TACACS. TACACS was the predecessor to TACACS+, but they're not compatible and TACACS+ has replaced TACACS.

TACACS+ uses Transmission Control Protocol (TCP) and encrypts not only a user's password, but also the username, authorization, and accounting for the session. Designed by Cisco, TACACS+ encrypts the full content of each packet and is often frequently run on AAA servers on Cisco networks.

What is SSH?

Quick Definition: SSH, which stands for Secure Shell, is a protocol for encrypting network interactions over unsecured networks. Realistically, any network service can be secured via SSH, but the most common applications of SSH are accessing the command line, logging in, and executing commands remotely.

An Overview of AAA, TACACS+ and SSH [VIDEO]

In this video, Keith Barker covers how to set up a router to authenticate users and restrict access to the secure shell (SSH). He begins with a router that has no security in place and uses TACACS+ to pair it with an AAA server.

Connecting a New Router to AAA Environment Checklist

Our mission is to prepare a router with no security at all to work with a AAA server using TACACS+. If you're already familiar with the process, this checklist should help orient you for the task at hand. If you're not familiar, these are the steps we'll be following below, and you can follow along with:

• Configuration Checklist

• Enable secret

• Local user (for backup)

• Domain name

• RSA keys

• Enable AAA New-model

• AAA IP and key

• AAA method list

• Permit-only SSH

How to Connect a New Router to AAA Environment with TACACS+ via SSH

To demonstrate the process of connecting our brand new router to our existing network environment, we'll be working in a simulated environment. Our recommendation for you would be to follow along with your own network simulation.

Remember, our plan is to take a router, which we'll call R1, with no security in place whatsoever and authorize it for a AAA server. We'll use TACACS+ to authenticate users and we'll restrict all the access to SSH. In our hypothetical network, we want that traffic to pass through only one place: inbound on the Fa 2/0 interface.

The first step is to enter the command line interface for R1 and start it up:

enable

Then start the process with:

configure terminal

The first step is to create a secret key. The command for that looks like this, but the secret you use should be specific to you and your environment:

enable secret KraZyD1fFiculT!

Next, you want to create a local user with full rights. Make sure you read that sentence carefully, though. You're creating a local user. But, you might ask, if we're working toward a AAA environment, why would we want to create a local user? Because if there's ever an outage during which we can't reach the AAA server, we want a fallback method that uses the local database and local configurations:

username admin privilege 15 secret T0ugh0n3asWha13

After that, we need to set a domain name. This will allow us to create the RSA key-pair for the SSH access. After this, we'll be generating the public/private key pair:

ip domain-name CBTNuggets.com

It's not until we have the public/private key pair in place that SSH is willing to get down to work. But now we can get it initiated:

crypto key generate rsa modulus 1024

Note: This should result in a return that tells you what the name for your keys will be. In our case, "The name for the keys will be: R1.CBTNuggets.com". Additionally, you should see information about the key like, "The key modulus size is 1024 bits" and "Generating 1024 bit RSA keys, keys will be non-exportable".

Enabling AAA On A New Router

Once the key and SSH access is in place, we'll move on to enabling AAA. And once we do that, we'll specify which AAA server to use. At that point, we'll need to instruct it where to find the server using TACACS+ and the key that should be used with that server.

Your next step is to enable AAA. The command for that is simple enough:

aaa

Note: This should return something like, "%SSH-5-ENABLED: SSH 1.99 has been enabled"

Next, type:

aaa new-model

And then tell the router about the IP address to use with the AAA server:

tacacs-server host 192.168.1.252

And the last part of getting AAA in place is to tell it what key to use with the AAA server:

tacacs-server key cisco123

If you've followed along, you now have AAA in place. We've identified a AAA server. Next, we'll specify a default method list. A method list is the list of instructions we give for how we want the device to go about authenticating users. In this case, it's us instructing it, "When it comes to log-in authentication, I want you to use a AAA server. If a AAA server can't be reached for whatever reason, fallback to the local database." Remember, this is why we created that local user.

The nice thing is that this is mostly a default method list. This one will tell the router to use the AAA server first, and then if the server can't be reached, then the local database should be used:

aaa authentication login default group tacacs+ local

Now the next thing we're going to do is lockdown SSH, so that SSH is only allowed. We do not want TELNET to be allowed through this interface. Additionally, we're going to lock all traffic down to the fast ethernet 2/0 interface. The easiest way to do that is through control plane functionality:

control-plane host

Now that we're working with the control plane host, we'll instruct it that the management interface is Fa 2/0, and only SSH should be allowed. That means TELNET, HTTP and other management protocols will not be allowed.

management-interface FastEthernet 2/0 allow ssh

We can verify we did that right by typing:

Test bas

Note: That should return "%Management-Interface feature enabled on Control plane"

Testing a New Connection to a AAA Environment

Any time you're dealing with new connections and encryption methods, it's usually a good idea to test it and verify that it's working. The test command will let us do a basic test for AAA access. If you've been following along, you should already be in configuration mode, and so the "do" precedes our test command.

In order to do the test, we're going to put in a username that exists on the AAA server, with the password, and the keyword legacy:

do test aaa group tacacs+ testadmin cisco legacy

Note: This should return: "Attempting authentication test to server-group tacacs+ using…"

Hopefully you, like we did, got a successful response. Now, the next thing we'll want to do is actually go to a live client at the PC at R1 itself. But before you do that, if you turn on debugging, you'll be able to watch the play-by-play action — and that's a good way to understand exactly what's happening behind the scenes.

How to Debug AAA Authentication, TACACS+ and Users

In addition to doing a debug of AAA authentication, we'll also want to debug TACACS+. On top of that, it's always a good idea at a point like this to verify that on the local running config there are no users other than the one user we created earlier: Admin.

To debug AAA authentication, type:

do debug aaa authentication

Note: If successful, this should return "AAA Authentication debugging is on"

To debug TACACS+, type:

do debug tacacs

Note: If successful, this should return "TACACS access control debugging is on"

Last, to check what users are running on the local config, type:

do show run | inc user

Note: If successful, this should return "username admin privilege 15 secret 5" followed by a hash

If, like ours, your set-up has gone well, it's time to head out to the client. For us, what that means is going to the admin PC in our network simulation and bringing up its Command Prompt.

First, we want to confirm its IP address:

ipconfig

This will give you a recognizable output. In our sim, this admin PC is 10.20.0.11 which is on the 10.2.0.0 network and the default gateway is 10.2.0.1,  all of which is what we want. Make sure yours is ready to run the AAA test.

To verify connectivity, you can ping the gateway:

ping 10.2.0.1

If you're in a simulated network environment and you have the space available on your monitor, you should try to have the debug window open alongside the admin PC's Command Prompt. That'll make the next steps easier. So, let's authenticate. On the Windows PC, launch PuTTY.

From the PuTTY window, go to R1. The first time you connect, you'll be asked if you want to validate the fingerprint. Because we're sure this is a valid connection and everything is above board, we can say yes.

Our test will involve us logging in as the user that we created. In our case, "testadmin" with the password "cisco".

While you log in, look at what's happening in the background. The debug should have caught important information about that transaction. It should read that a user "testadmin" has had "Authentication start packet created".

As that handshake happens, you can look through the debug and see that a TACACS debug is running. It should have gotten the password via "Received authen response status GET_PASSWORD". And the result of that: "Received authen response status PASS" means that it was passed.

Congratulations: in a simulated live environment, you can probably follow these steps in five minutes and have your router ready to go.

Wrapping Up

Admittedly, a wall of text isn't the ideal way to follow along with a AAA initialization and debug. But hopefully seeing all the commands and expected results gives you a sense of what to look for when you do your own setup. Because if you were able to follow along, you've got the start-to-finish process for how to get a brand new router with Zero Security connected to a AAA server using TACACS+. We saw how to lock down all the interfaces except for one, as well as all management protocols except SSH. We got rid of TELNET and tested it, too.

If remote access technologies is a subject you could use help on, you might consider one of CBT Nuggets' courses on it — 172 videos, 14 hours of training and 19 virtual labs can help you understand everything you need to know about Remote Access Technologies, and get you ready for a certification exam at the same time.

Or if you're in the mood for a quick YouTube video, check out this 8-minute video on how to set up SSH on a Cisco IPv6 router.