Mailing List Archive

>I was wondering what everybody else does to make configs, which RANCID
>pulled from the device, available for TFTP downloads. Symlinks from
><GROUP>/configs? Separate CVS checkouts to /tftpboot? Also,
>does anybody
>have experience with utftpd? I am wondering about using
>utftpd's revision
>control interface to check files out from RANCID.

Alex, I've recently been thinking alot about this, also; and I'm sure the
more experienced ops folks in the list would have come up with some better
solutions than mine :). I presume you want to use your saved configurations
for disaster recovery ("plug in a new one and say ahhh!") -- at the moment I
pull the file over to a temporary in the tftp path that only the "build"
devices have access to (using utftpd ACLs).

To upload to the device i'm just using the expect scripts recently posted to
the list; e.g. clogin -s ./cisco-load.exp blah and then clogin -s
./cisco-reload.exp blah

I manually replace the passwords in the device, usually in the temporary
file before its uploaded. If not, I usually forget to put the BGP md5 auth
passwords in, think "ugh, why doesn't the thing bring up adjacen... doh!"
and then get with the program, so a script to regexp the ! password
<removed> stuff with the users' input would be a useful thing, also (or more
coffee).

Since utftpd uses RCS (or SCCS?) only, how would you plan to do this with
RANCID, which is a CVS tool? I remember Uwe saying adding CVS support would
not be easy..

-amf

On Thu, Oct 18, 2001 at 10:08:04AM +1000, Andrew Fort wrote:
> I manually replace the passwords in the device, usually in the temporary
> file before its uploaded. If not, I usually forget to put the BGP md5 auth
> passwords in, think "ugh, why doesn't the thing bring up adjacen... doh!"
> and then get with the program, so a script to regexp the ! password
> <removed> stuff with the users' input would be a useful thing, also (or more
> coffee).

An option to not strip the passwords would also be useful, although I
admit I wouldn't use it. Given a decent password storage mechanism
(you all have one, right?), it's pretty much a little perl to put the
config file back to 'reality' before shoving it onto the router.

Or more caffeine, as suggested.

-David

Wed, Oct 17, 2001 at 11:59:43PM -0700, David Williamson:
> On Thu, Oct 18, 2001 at 10:08:04AM +1000, Andrew Fort wrote:
> > I manually replace the passwords in the device, usually in the temporary
> > file before its uploaded. If not, I usually forget to put the BGP md5 auth
> > passwords in, think "ugh, why doesn't the thing bring up adjacen... doh!"
> > and then get with the program, so a script to regexp the ! password
> > <removed> stuff with the users' input would be a useful thing, also (or more
> > coffee).
>
> An option to not strip the passwords would also be useful, although I

is this something folks really want?

> admit I wouldn't use it. Given a decent password storage mechanism
> (you all have one, right?), it's pretty much a little perl to put the
> config file back to 'reality' before shoving it onto the router.
>
> Or more caffeine, as suggested.
>
> -David

On Thu, Oct 18, 2001 at 09:09:07AM -0700, john heasley wrote:
> > An option to not strip the passwords would also be useful, although I
>
> is this something folks really want?

Having suggested it, I'd admit that I'm not certain it's what I want.
I have some network gear that's not currently watched by rancid. Some of
that gear is so far out of production that I really don't care about
tracking actual config changes. It would be nice to have a repository
of those configs, however, for disaster recovery. And for that, it
would be nice to have the whole config, intact, including passwords.

This hasn't bitten me with the access or enable passwords, but having
the tacacs+ key stripped out has bitten me a couple of times during a
recovery. It would probably be ideal if there was an option to encrypt
rancid's output, rather than stripping anything our of the config.
Of course, the key would probably have to go into .cloginrc, which defeats
the point. There's probably not a better solution to this problem than
simply stripping the passwords, as is done now.

Sorry to ramble on, but I'm really on the fence on this topic. Sometimes
I think it would be nice to have everything directly in the stored config.
Other times I think it's very very good to not have the passwords exposed.

For those who don't know why it's a good thing to keep the passwords
stripped, here's a perl script to decrypt your console and tty passwords:

perl -ne 'if (/^(.* password )7 ([0-9A-F]*)$/) { print $1; $enc = substr("dsfd;k
foA,.iyewrkldJKDHSUB",substr($2,0,2)); $pw = substr($2,2); foreach $i (0 .. (len
gth($pw)/2)-1) { print pack("c",hex(substr($pw,$i*2,2))^unpack("c",substr($enc,$
i,1))); } print "\n"; } else { print; }'

It's that easy. (Okay, I got that from someone..I don't speak perl that
well. :)

Hmm...what to do...what to do....

-David

Thu, Oct 18, 2001 at 09:19:11AM -0700, David Williamson:
> On Thu, Oct 18, 2001 at 09:09:07AM -0700, john heasley wrote:
> > > An option to not strip the passwords would also be useful, although I
> >
> > is this something folks really want?
>
> Having suggested it, I'd admit that I'm not certain it's what I want.
> I have some network gear that's not currently watched by rancid. Some of
> that gear is so far out of production that I really don't care about
> tracking actual config changes. It would be nice to have a repository
> of those configs, however, for disaster recovery. And for that, it
> would be nice to have the whole config, intact, including passwords.
>
> This hasn't bitten me with the access or enable passwords, but having
> the tacacs+ key stripped out has bitten me a couple of times during a
> recovery. It would probably be ideal if there was an option to encrypt
> rancid's output, rather than stripping anything our of the config.
> Of course, the key would probably have to go into .cloginrc, which defeats
> the point. There's probably not a better solution to this problem than
> simply stripping the passwords, as is done now.

suppose it might be possible to strip them only for the diff mail. think
that might be a pita, needing to be generic.

> Sorry to ramble on, but I'm really on the fence on this topic. Sometimes
> I think it would be nice to have everything directly in the stored config.
> Other times I think it's very very good to not have the passwords exposed.
>
> For those who don't know why it's a good thing to keep the passwords
> stripped, here's a perl script to decrypt your console and tty passwords:
>
> perl -ne 'if (/^(.* password )7 ([0-9A-F]*)$/) { print $1; $enc = substr("dsfd;k
> foA,.iyewrkldJKDHSUB",substr($2,0,2)); $pw = substr($2,2); foreach $i (0 .. (len
> gth($pw)/2)-1) { print pack("c",hex(substr($pw,$i*2,2))^unpack("c",substr($enc,$
> i,1))); } print "\n"; } else { print; }'
>
> It's that easy. (Okay, I got that from someone..I don't speak perl that
> well. :)

cisco has added md5 pwds for local username configs to recent S images and,
of course, enable has had md5 option for quite some time. i dont believe
this was done for ttys.

shaggy(config)#user foo sec ?
0 Specifies an UNENCRYPTED secret will follow
5 Specifies a HIDDEN secret will follow
LINE The UNENCRYPTED (cleartext) user secret

> Hmm...what to do...what to do....
>
> -David

One comment about utftpd and CVS: Since CVS is based on RCS, you can
certainly check out a file from a CVS repository with co, do rlog, etc.
Somewhat rudimentary, but it works.

Alex Bochannek
Senior Unix/Network Engineer
Yipes ... that's fast!
(415) 901-2000
(415) 901-2090 (direct)
www.yipes.com