[rancid] Rancid and cisco 'autocommand' users?

[Phil Stoneman]

Hi folks,

We're currently involved in a deployment of rancid for some cisco
equipment that we manage. We're fairly uncomfortable with storing
full-privilege passwords in plaintext anywhere.

One solution to this might be for us to configure a user with an
autocommand:

username auditor password 0 mypassword
username auditor privilege 15 autocommand show running-config

When the user 'auditor' logs in, the configuration is dumped (with any
--More-- bits in between), and the connection is then closed.

This presents me with a problem, though. It seems that clogin and the
other bits of rancid are written to require a valid login to the cisco
router. A connection that dumps the configuration and then instantly
closes does not seem to work nicely.


My skills with 'expect' and perl aren't strong enough for me to solve
this by myself - can anyone give me any hints as to how I can make
rancid save this type of configuration gracefully?

Alternatively, can anyone suggest another way of achieving the same
goal, i.e. not having full-access passwords saved anywhere?


Thanks

Phil

[Ed Ravin]

On Wed, Apr 25, 2007 at 02:19:04PM +0100, Phil Stoneman wrote:
...>

Post by Phil Stoneman
username auditor password 0 mypassword
username auditor privilege 15 autocommand show running-config
When the user 'auditor' logs in, the configuration is dumped (with any
--More-- bits in between), and the connection is then closed.
This presents me with a problem, though. It seems that clogin and the
other bits of rancid are written to require a valid login to the cisco
router. A connection that dumps the configuration and then instantly
closes does not seem to work nicely.

It's worse than that - if you look more carefully at RANCID, you'll
see that the "rancid" script calls "clogin" with a list of 50
or so commands to run. You would have to hardcode that list (and I
think you could, probably by using that fancy feature where TCL can run
on the router), and maintain the list every now and then when a new command
was added.

Post by Phil Stoneman
My skills with 'expect' and perl aren't strong enough for me to solve
this by myself - can anyone give me any hints as to how I can make
rancid save this type of configuration gracefully?

Define a new device type, like "cisco-autocmd", use the regular
"rancid" script, and a custom "clogin" script that just logs in,
saves whatever happens, and waits for a timeout or other marker
to figure out when the connection has closed.

Post by Phil Stoneman
Alternatively, can anyone suggest another way of achieving the same
goal, i.e. not having full-access passwords saved anywhere?

You could use the rsh.clogin script (you'll have to enable rsh access
from the RANCID host), which I've posted in the past on this list,
which uses the rsh protocol. Catch is, that's not encrypted, and uses
IP address and a low port number only as authentication, so if the router
is not on a secure network or if it's against policy, you'll have to do
something else. Installing rsh.clogin involves a minor bit of patching
to get it recognized as a new device type.

The most recent RANCID has a version of clogin that has better support
for rsh than older ones, but I don't think it handles errors well, and
it can be fooled into truncating the config if an error message (like
"Connection refused") appears anywhere in the config (for example,
in ACL comments). If you're allergic to patching rancid-fe to
install a new device type (as required by rsh.clogin), you should
try that first and see if it works for you.

Also, you can filter your router's access ports by IP address, and
if you have a TACACS or RADIUS server for authentication, you should be
able to limit the login of certain usernames to specific IP addresses.
Doing things like that will limit the usefulness of the RANCID password
should it get disclosed.

[Austin Schutz]

Post by Phil Stoneman
Hi folks,
We're currently involved in a deployment of rancid for some cisco
equipment that we manage. We're fairly uncomfortable with storing
full-privilege passwords in plaintext anywhere.
One solution to this might be for us to configure a user with an
username auditor password 0 mypassword
username auditor privilege 15 autocommand show running-config
When the user 'auditor' logs in, the configuration is dumped (with any
--More-- bits in between), and the connection is then closed.

I fail to see how automatically logging in the users from an ACL of
hosts is more secure than doing that plus requiring a password.

Austin

[Austin Schutz]

Post by Austin Schutz

Post by Phil Stoneman
Hi folks,
We're currently involved in a deployment of rancid for some cisco
equipment that we manage. We're fairly uncomfortable with storing
full-privilege passwords in plaintext anywhere.
One solution to this might be for us to configure a user with an
username auditor password 0 mypassword
username auditor privilege 15 autocommand show running-config
When the user 'auditor' logs in, the configuration is dumped (with any
--More-- bits in between), and the connection is then closed.

I fail to see how automatically logging in the users from an ACL of
hosts is more secure than doing that plus requiring a password.

Nm, I completely misunderestimated that initial comment, sorry.

Austin

[john heasley]

Post by Phil Stoneman
Hi folks,
We're currently involved in a deployment of rancid for some cisco
equipment that we manage. We're fairly uncomfortable with storing
full-privilege passwords in plaintext anywhere.

There are trade-offs to be made/accepted for automation. You can still
limit the exposure, as Ed Ravin has suggested.

[Randy Bush]

Post by john heasley

Post by Phil Stoneman
We're currently involved in a deployment of rancid for some cisco
equipment that we manage. We're fairly uncomfortable with storing
full-privilege passwords in plaintext anywhere.

There are trade-offs to be made/accepted for automation. You can still
limit the exposure, as Ed Ravin has suggested.

ask your router vendor why they do not have the equivalent of
~/.ssh/authorized_keys

randy

[john heasley]

Post by Randy Bush

Post by john heasley

Post by Phil Stoneman
We're currently involved in a deployment of rancid for some cisco
equipment that we manage. We're fairly uncomfortable with storing
full-privilege passwords in plaintext anywhere.

There are trade-offs to be made/accepted for automation. You can still
limit the exposure, as Ed Ravin has suggested.

ask your router vendor why they do not have the equivalent of
~/.ssh/authorized_keys

Indeed, but the pass phrase still needs to be located somewhere or be empty.

and, s/router/device/

[Randy Bush]

Post by john heasley

Post by Randy Bush
ask your router vendor why they do not have the equivalent of
~/.ssh/authorized_keys

Indeed, but the pass phrase still needs to be located somewhere or be empty.

yes, but the private key on the client is crypted

randy

[Austin Schutz]

Post by Randy Bush

Post by john heasley

Post by Randy Bush
ask your router vendor why they do not have the equivalent of
~/.ssh/authorized_keys

Indeed, but the pass phrase still needs to be located somewhere or be empty.

yes, but the private key on the client is crypted

wrt the other email I just submitted to this thread: why is this
advantageous? Over the wire a passphrase is also encrypted, and locally
it's just as easy to copy a file containing a private key as it is to copy
a file containing a passphrase.
I feel like I'm missing something really obvious here. Well, other
than the fact that some vendor(s) older equipment still doesn't support ssh
properly. Count yourself lucky if you don't have any of that still around.

Austin

[Russell Jackson]

Post by Austin Schutz

Post by Randy Bush

Post by john heasley

Post by Randy Bush
ask your router vendor why they do not have the equivalent of
~/.ssh/authorized_keys

Indeed, but the pass phrase still needs to be located somewhere or be empty.

yes, but the private key on the client is crypted

wrt the other email I just submitted to this thread: why is this
advantageous? Over the wire a passphrase is also encrypted, and locally
it's just as easy to copy a file containing a private key as it is to copy
a file containing a passphrase.
I feel like I'm missing something really obvious here. Well, other
than the fact that some vendor(s) older equipment still doesn't support ssh
properly. Count yourself lucky if you don't have any of that still around.

Only the public key is stored on the remote end. Stealing it would gain an attacker
nothing; in fact, you could store the public key on a web site or broadcast it over email
safely. With public key authentication, the passphrase nor private key is ever transmitted
across the wire.

[Austin Schutz]

Post by Russell Jackson
Only the public key is stored on the remote end. Stealing it would gain an attacker
nothing; in fact, you could store the public key on a web site or broadcast it over email
safely. With public key authentication, the passphrase nor private key is ever transmitted
across the wire.

Ok, so if an attacker breaks into your router they won't be able to
glean the key to break in with. Ah, well that's something I suppose. :-)
Anyway, I can see where that would be useful in some instances,
if not here. Thanks for the explanation.

Austin

[Jeffrey C. Ollie]

Post by Russell Jackson
Only the public key is stored on the remote end. Stealing it would gain an attacker
nothing; in fact, you could store the public key on a web site or broadcast it over email
safely. With public key authentication, the passphrase nor private key is ever transmitted
across the wire.

But the private key must be stored unencrypted on the host running
rancid, or rancid needs to know the passphrase to decrypt the private
key. Not that much better than storing the unencrypted password on the
host running rancid. As John Heasley said above, there are tradeoffs to
be made if you want things automated.

Jeff

[Russell Jackson]

Post by Jeffrey C. Ollie

Post by Russell Jackson
Only the public key is stored on the remote end. Stealing it would gain an attacker
nothing; in fact, you could store the public key on a web site or broadcast it over email
safely. With public key authentication, the passphrase nor private key is ever transmitted
across the wire.

But the private key must be stored unencrypted on the host running
rancid, or rancid needs to know the passphrase to decrypt the private
key. Not that much better than storing the unencrypted password on the
host running rancid. As John Heasley said above, there are tradeoffs to
be made if you want things automated.

Not entirely true. You could use the key agent to hold the decrypted key in memory but
leave the file encrypted. The downside to that is that you'd have to input the passphrase
when/if the key agent died (reboot, etc...).

[john heasley]

Post by Russell Jackson

Post by Jeffrey C. Ollie

Post by Russell Jackson
Only the public key is stored on the remote end. Stealing it would gain an attacker
nothing; in fact, you could store the public key on a web site or broadcast it over email
safely. With public key authentication, the passphrase nor private key is ever transmitted
across the wire.

But the private key must be stored unencrypted on the host running
rancid, or rancid needs to know the passphrase to decrypt the private
key. Not that much better than storing the unencrypted password on the
host running rancid. As John Heasley said above, there are tradeoffs to
be made if you want things automated.

Not entirely true. You could use the key agent to hold the decrypted key in memory but
leave the file encrypted. The downside to that is that you'd have to input the passphrase
when/if the key agent died (reboot, etc...).

Doesn't seem like that much extra effort to get the key from core if you're
clever.

[Austin Schutz]

Post by john heasley

Post by Randy Bush

Post by john heasley

Post by Phil Stoneman
We're currently involved in a deployment of rancid for some cisco
equipment that we manage. We're fairly uncomfortable with storing
full-privilege passwords in plaintext anywhere.

There are trade-offs to be made/accepted for automation. You can still
limit the exposure, as Ed Ravin has suggested.

ask your router vendor why they do not have the equivalent of
~/.ssh/authorized_keys

Indeed, but the pass phrase still needs to be located somewhere or be empty.
and, s/router/device/

I've never really understood the big advantage with empty keys-
if you copy the key somewhere else, and the new host is in the ACL, you will
still be able to log in without authentication, unless there's some further
configuration (that I'm not aware of) to force the key to match the original
host to help keep this from happening.

Austin