[rancid] Scripting clogin with bash and username/password

[Andrew Ohnstad]

Thanks for the response.  The full command line I am using is (I
automatically am enabled via TACACS+):

sudo -u rancid /usr/libexec/rancid/clogin -u<my-username> -p<my-password>
-c where <router>

If I add the -d argument to see the expect debugging, I can see that it
launches the ssh spawn with the correct username, but it is blatantly
disregarding the password supplied on the command line...

spawn ssh -c 3des -x -l <myusername> <router>
....
....
....
expect: set expect_out(buffer) "User Access Verification\r\nPassword:"
send: sending <password-in-cloginrc> to { exp4 }
expect: continuing expect

So it really looks to me like clogin is just ignoring the password on the
command line.  I tried -p -r and -v.  None of them have any effect.

I am doing it this way because this server and the routers being managed
all authenticate from the same Active Directory server.  Rancid is
installed on a shared administrator server and the rancid user is the only
one with a .cloginrc.  The rancid user's .cloginrc file is configured with
the username and password of an account defined in AD which only gets
access (through TACACS) to the few commands that rancid needs in order to
complete its runs.

The administrators who share this box all have sudo access and can
theoretically see each other's home directories if they want.  So having
individual admin's passwords stored in a text file is not going to happen,
even if they are chmod 600.  So in order for the admins to use
clogin/rancid to push configs, they need to be able to interactively
authenticate their own account.

I agree that having the password on the command line is also bad, but in my
opinion, it's better than having it in a text file, as it's exposed for
less time (assuming the shared sudo access which exists here).  I do ask
for it interactively as part of the script, so it doesn't show up in
anyone's command history or on their screen. Yes, it would be visible
through a 'ps' while clogin is running, but it's the best I could come up
with.

If anyone has any suggestions on the technical problem I'm facing with
clogin, or a better method altogether to get what I need done, then I'd
appreciate any assistance or advice you can give!


On Thu, Feb 13, 2014 at 7:49 AM, Alan McKinnon <alan.mckinnon at gmail.com>wrote:

> On 13/02/2014 14:03, Andrew Ohnstad wrote:
> > I'm not sure if I'm asking more of the tool than what's possible, or if
> > I'm just missing the secret sauce.
> >
> > I've got rancid set up and working for archiving configs. I'm now trying
> > to use clogin as part of a bash shell script to push configuration
> > changes to a bunch of devices. The catch is that the devices are a) only
> > reachable through ssh, and b) clogin must use a username and password
> > provided as command line arguments and NOT any credentials stored in a
> > .cloginrc file. This is a requirement so that the user pushing the
> > updates can be logged.
> >
> > Is there a set of arguments to clogin that will tell it to ignore the
> > username and password? I can get it to pass the specified username with
> > the -u command, but by running with debugging turned on, I saw that it
> > was still using the password in the .cloginrc file for all the logins.
> > It seems to ignore every password related command line argument.
> >
> > Thanks in advance for any advice you can provide.
>
>
> Did you use this syntax:
>
> clogin -u <username> -p <userpass> -e <enablepass> -c
> <command1;command2...> routername
>
> a) is not a problem. if you have method in .cloginrc as "telnet ssh" and
> telnet fails, it tries ssh.
>
> b) Personally I wouldn't use -p or -e, I'd let .cloginrc deal with that.
> When a password is on the command line and visible to ps, or logged in a
> log file, I consider that to be situation=game_over, but your needs may
> be different
>
>
>
> --
> Alan McKinnon
> alan.mckinnon at gmail.com
>
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-discuss at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/rancid-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/rancid-discuss/attachments/20140213/a6324b5d/attachment.html>