<div dir="ltr"><div><div><div>Thanks for the response. The full command line I am using is (I automatically am enabled via TACACS+):<br><br></div>sudo -u rancid /usr/libexec/rancid/clogin -u<my-username> -p<my-password> -c where <router><br>
<br></div><div>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...<br><br>
</div><div>spawn ssh -c 3des -x -l <myusername> <router><br>....<br>....<br>....<br></div><div>expect: set expect_out(buffer) "User Access Verification\r\nPassword:"<br></div><div>send: sending <password-in-cloginrc> to { exp4 }<br>
</div><div>expect: continuing expect<br><br></div><div>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.<br></div><div><br></div>
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. <br>
<br>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.<br>
<br></div>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.<br>
<br>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!</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 7:49 AM, Alan McKinnon <span dir="ltr"><<a href="mailto:alan.mckinnon@gmail.com" target="_blank">alan.mckinnon@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 13/02/2014 14:03, Andrew Ohnstad wrote:<br>
> I'm not sure if I'm asking more of the tool than what's possible, or if<br>
> I'm just missing the secret sauce.<br>
><br>
> I've got rancid set up and working for archiving configs. I'm now trying<br>
> to use clogin as part of a bash shell script to push configuration<br>
> changes to a bunch of devices. The catch is that the devices are a) only<br>
> reachable through ssh, and b) clogin must use a username and password<br>
> provided as command line arguments and NOT any credentials stored in a<br>
> .cloginrc file. This is a requirement so that the user pushing the<br>
> updates can be logged.<br>
><br>
> Is there a set of arguments to clogin that will tell it to ignore the<br>
> username and password? I can get it to pass the specified username with<br>
> the -u command, but by running with debugging turned on, I saw that it<br>
> was still using the password in the .cloginrc file for all the logins.<br>
> It seems to ignore every password related command line argument.<br>
><br>
> Thanks in advance for any advice you can provide.<br>
<br>
<br>
</div></div>Did you use this syntax:<br>
<br>
clogin -u <username> -p <userpass> -e <enablepass> -c<br>
<command1;command2...> routername<br>
<br>
a) is not a problem. if you have method in .cloginrc as "telnet ssh" and<br>
telnet fails, it tries ssh.<br>
<br>
b) Personally I wouldn't use -p or -e, I'd let .cloginrc deal with that.<br>
When a password is on the command line and visible to ps, or logged in a<br>
log file, I consider that to be situation=game_over, but your needs may<br>
be different<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Alan McKinnon<br>
<a href="mailto:alan.mckinnon@gmail.com">alan.mckinnon@gmail.com</a><br>
<br>
_______________________________________________<br>
Rancid-discuss mailing list<br>
<a href="mailto:Rancid-discuss@shrubbery.net">Rancid-discuss@shrubbery.net</a><br>
<a href="http://www.shrubbery.net/mailman/listinfo/rancid-discuss" target="_blank">http://www.shrubbery.net/mailman/listinfo/rancid-discuss</a><br>
</font></span></blockquote></div><br></div>