16

I'm setting up a Cisco 2901 router. I have a login password on the console line, and the vty lines are configured to only accept ssh connections with public key authentication. The auxiliary line is shut down. There are only two admins who will be accessing the router and we are both authorized to perform any configuration on the router.

I'm not an expert on Cisco gear, but I consider this adequate to secure access to the router configuration. However, every single guide I've read states I should set an enable secret, regardless of any other user or line passwords.

Is there something more to the enable password that I'm not aware off? Is there any other way to access the router than then console, auxiliary, or vty lines?

EDIT: I've added the actual configuration below to be more clear about my situation. The following works, with requiring an enable password, or a username config aside from the one within ip ssh pubkey-chain.

aaa new-model

ip ssh time-out 60
ip ssh authentication-retries 2
ip ssh version 2
ip ssh pubkey-chain
 username tech
  key-hash ssh-rsa [HASH]
ip scp server enable

line vty 0 4
 transport input ssh
  • 1
    short answer: not required, but very highly recommended -- as it's the first line of defense for full privs – Ricky Beam Jan 8 '15 at 2:51
  • But if I have passwords on the console line and vtys, why would I need another password? Also, the enable secret will have to be shared between admin staff, which is just asking for it to be written down, emailed, etc. Better for each admin to have their own private password/key. – Marwan Jan 8 '15 at 12:38
  • enable elevates priv. Unless you change it (through aaa), it still applies once you have a commandline. – Ricky Beam Jan 9 '15 at 0:24
24

No, you don't -- technically. But whether you can enter enable mode without one depends on how you log in.

Here's the instant gratification version:

You can enter via the console without an enable password, but you will be stuck in user mode if you use a simple vty login password without an enable password set.

Here's the long-winded StackExchange answerer version:

Cisco authentication is kind of a mess for a beginner. There's a lot of legacy baggage there. Let me try to break this down in a real-world sense.

Everyone that has any business logging into a router or switch pretty much goes directly to privileged (enable) mode. The user mode is basically a front lobby, and serves little more purpose than to keep the draft out. In large organizations where you have vast networks and equally vast pools of labor, it may be justifiable to have someone who can knock on the front door and make sure someone is still there. (That is, to log in and run the most trivial commands just to see that the device is, in fact, responding and not on fire.) But in every environment I've ever worked in, tier 1 had at least some ability to break things.

As such, and particularly in a scenario like yours, knowing the enable password is obligatory to get anything done. You could say this is a second level of security -- one password to enter the device, another to escalate to administrative privilege -- but that seems a little bit silly to me.

As already noted, you can (and many people do) use the same password, which doesn't help much if someone has gained unauthorized access via telnet/ssh. Having static, global passwords shared by everyone is arguably more of an issue than having just one token required to enter. Finally, most other systems (services, appliances, etc.) don't require a second layer of authentication, and are not generally considered insecure because of this.

OK, that's my opinion on the topic. You'll have to decide for yourself whether it makes sense in light of your own security stance. Let's get down to business.

Cisco (wisely) requires you to set a remote access password by default. When you get into line configuration mode...

router> enable
router# configure terminal
router(config)# line vty 0 15
router(config-line)#

...you can tell the router to skip authentication:

router(config-line)# no login

...and promptly get hacked, but your attacker will end up in user mode. So if you have an enable password set, at least you have somewhat limited the damage that can be done. (Technically, you can't go any further without an enable password either. More on that in a moment...)

Naturally, no one would do this in real life. Your minimum requirement, by default and by common sense, is to set a simple password:

router(config-line)# login
router(config-line)# password cisco

Now, you will be asked for a password, and you will again end up in user mode. If you're coming in via the console, you can just type enable to get access without having to enter another password. But things are different via telnet, where you will probably get this instead:

$ telnet 10.1.1.1
Trying 10.1.1.1...
Connected to 10.1.1.1.
Escape character is '^]'.


User Access Verification

Password: *****
router> enable
% No password set
router> 

Moving on... You probably already know that, by default, all your configured passwords show up as plain text:

router# show run | inc password
no service password-encryption
 password cisco

This is one of those things that tightens the sphincter of the security-conscious. Whether it's justified anxiety is again something you have to decide for yourself. On one hand, if you have sufficient access to see the configuration, you probably have sufficient access to change the configuration. On the other hand, if you happen to have carelessly revealed your configuration to someone who doesn't have the means themselves, then ... well, now they do have the means.

Luckily, that first line in the snippet above, no service password-encryption, is the key to changing that:

router(config)# service password-encryption
router(config)# line vty 0 15
router(config-line)# password cisco

Now, when you look at the configuration, you see this:

router(config-line)# do show run | begin line vty
line vty 0 4
 password 7 01100F175804
 login
line vty 5 15
 password 7 01100F175804
 login
!
!
end

This is marginally better than plain-text passwords, because the displayed string isn't memorable enough to shoulder-surf. However, it's trivial to decrypt -- and I use that term loosely here. You can literally paste that string above into one of a dozen JavaScript password crackers on the first Google results page, and get the original text back immediately.

These so-called "7" passwords are commonly considered "obfuscated" rather than "encrypted" to highlight the fact that it is just barely better than nothing.

As it turns out, however, all those password commands are deprecated. (Or if they're not, they should be.) That's why you have the following two options:

router(config)# enable password PlainText
router(config)# enable secret Encrypted
router(config)# do show run | inc enable
enable secret 5 $1$sIwN$Vl980eEefD4mCyH7NLAHcl
enable password PlainText

The secret version is hashed with a one-way algorithm, meaning the only way to get the original text back is by brute-force -- that is, trying every possible input string until you happen to generate the known hash.

When you enter the password at the prompt, it goes through the same hashing algorithm, and should therefore end up generating the same hash, which is then compared to the one in the configuration file. If they match, your password is accepted. That way, the plain text isn't known to the router except during the brief moment when you are creating or entering the password. Note: There's always the chance some other input can generate the same hash, but statistically it's a very low (read: negligible) probability.

If you were to use the above configuration yourself, the router will allow both the enable password and enable secret lines to exist, but the secret wins from the password prompt. This is one of those Cisco-isms that doesn't make much sense, but it's the way it is. Furthermore, there's no secret equivalent command from line configuration mode, so you're stuck with obfuscated passwords there.

Alright, so we now have a password that can't be recovered (easily) from the config file -- but there's still one problem. It's being transmitted in plain text when you log in via telnet. No good. We want SSH.

SSH, being designed with more robust security in mind, requires a little extra work -- and an IOS image with a certain feature set. One big difference is that a simple password is no longer good enough. You need to graduate to user-based authentication. And while you're at it, set up an encryption key pair:

router(config)# username admin privilege 15 secret EncryptedPassword
router(config)# line vty 0 15
router(config-line)# transport input ssh
router(config-line)# no password
router(config-line)# login local
router(config-line)# exit
router(config)# ip ssh version 2
router(config)# crypto key generate rsa modulus 1024

Now you're cooking with gas! Notice this command uses secret passwords. (Yes, you can, but shouldn't, use password). The privilege 15 part allows you to bypass user mode entirely. When you log in, you go straight to privileged mode:

$ ssh admin@10.1.1.1
Password: *****

router#

In this scenario, there's no need to use an enable password (or secret.)

If you're not yet thinking, "wow... what a clusterfudge that was", bear in mind there's a whole other long-winded post still lurking behind the command aaa new-model, where you get to dive into things like external authentication servers (RADIUS, TACACS+, LDAP, etc.), authentication lists (which define the sources to use, and in which order), authorization levels, and user activity accounting.

Save all that for a time when you feel like getting locked out of your router for a while.

Hope that helps!

  • 1
    Welcome! Great first answer! – Digital Trauma Jan 8 '15 at 0:34
  • Thanks, it is a very insightful answer. I am aware of the various password encryption devices, and I am using aaa new-model (I've edited my question to reflect that). – Marwan Jan 8 '15 at 12:31
  • Not having an enable secret does not seem to be an issue for me. Whether I telnet/ssh with a username/password or a public key, I can simply type enable and it works. Also, having a username with privilege 15 still requires me to type enable. Is this due to aaa new-model? – Marwan Jan 8 '15 at 12:34
  • 1
    Have you tried defining authentication lists? Use "aaa authentication login default local", and "aaa authorization exec default local". Alternatively, use "if-authenticated" instead of "local" on the latter. – SirNickity Jan 8 '15 at 19:23
  • I tried duplicating your config on a 2811 running IOS 15.1(4)M and found some interesting results. If I have NOT defined aaa authen/author lines, I can log in with a public key and no global username statement. If I define the authen/author lines per my previous comment, I'm not able to SSH with just a public key -- the global username command is required (authorization failure otherwise.) If I do something stupid and enter a global username withOUT a secret/password, SSH works with a key, but telnet works w/o a password -- so don't do that. – SirNickity Jan 8 '15 at 19:56
4

Yes, you need to set it to something. That's just the way the IOS works. You can make it the same as your login password, if you want.

For multiple users, I recommend you set up AAA authentication, which will allow you to go directly into enable mode without having to enter another password. It will also allow you to track individual admins' activity. (But you still need to set the enable secret password to something.)

aaa new model
aaa authentication login default local
aaa authorization enable default local

username chen-li password foo privilege 15
username safar password bar privilege 15
  • 2
    TO back up Ron's answer, it must be enabled if you want to enter privileged exec mode unless you configure you VTYs to enter level 15 directly. – jwbensley Jan 7 '15 at 16:07
  • @jwbensley. Good idea. I had forgotten about that. – Ron Trunk Jan 7 '15 at 20:09
  • I am using aaa new-model, but setting privilege 15 still requires me to use the enable command. I don't need an enable secret/password either (I've just tested all this). – Marwan Jan 8 '15 at 12:35
  • Go it to work. Apparently I needed to specify aaa authorization exec default local to enter privileged exec automatically. – Marwan Jan 8 '15 at 14:51
0

It is basically an extra layer of security. If you do not have a version of IOS that supports service password-encryption, then only enable passwords are encrypted while the console and VTY passwords are plaintext. If someone were able to get a copy of your config (say from a backup, or an unattended computer that was telnetted in), the encrypted enable password would make it more difficult getting control of your router, even if they can telnet in.

Even with encrypted VTY and console passwords, you should still have a different enable password to be on the safe side and provide an extra barrier.

0

Shut down 1 of the 2 admin users.cisco's are very watcthful of any,any,any kind of possible hack entry points via connect. With two admins. Connected the cisco will believe that an intruder is also connected and block further progress without proper login.once control is reastablished,you should be able to add admin's

1

To add to the existing information here.

enable

The first option for setting the enable password is enable password.

Switch(config)#enable password passfoo
Switch#show running-config | include enable
enable password passfoo

As you can see, the password is stored in plain text. This is bad.

The second is enable secret.

Switch(config)#enable secret ?
  0      Specifies an UNENCRYPTED password will follow
  5      Specifies a MD5 HASHED secret will follow
  8      Specifies a PBKDF2 HASHED secret will follow
  9      Specifies a SCRYPT HASHED secret will follow
  LINE   The UNENCRYPTED (cleartext) 'enable' secret
  level  Set exec level password
Switch(config)#enable secret passfoo
Switch#show running-config | include enable
enable secret 5 $1$cSF4$uydOsfi3J2vGT.77tuYWh1

This is better. At least we have a hash of the password now. However this still only uses salted MD5 so its probably reasonably easy to crack with a big word list and openssl.

The third option (and the purpose of this answer) is enable algorithm-type which allows us to use PBKDF2 or SCRYPT.

Switch(config)#enable algorithm-type ?
  md5     Encode the password using the MD5 algorithm
  scrypt  Encode the password using the SCRYPT hashing algorithm
  sha256  Encode the password using the PBKDF2 hashing algorithm
Switch(config)#enable algorithm-type scrypt secret ?
  LINE   The UNENCRYPTED (cleartext) 'enable' secret
  level  Set exec level password
Switch(config)#enable algorithm-type scrypt secret passfoo
Switch#show running-config | include enable
enable secret 9 $9$dXjOMeJPYKOFbl$0D4.ItXi8yrjp.A9dt7Ew6tTgr3LYmMlzD672d.LjFk

This is definitely best.

Philip D'Ath has written a nice summary on why to chose type 9. Thomas Pornin and Ilmari Karonen provide more in depth information.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.