[rancid] Can clogin prompt for a password?

[Brandon Ewing]

Greetings,

Historically, I've often used clogin to execute command snippets and other
tasks on large amounts of routers. However, now I'm in a position where we
are using central authorization that utilizes our domain credentials.

Since I'd prefer not to keep my domain password in a text file on a box that
other people have root on, is it possible for clogin (or par) to prompt for
a password at initial execution, instead of relying on storing the cleartext
password on disk, or exposing the password in a history file?

[heasley]

Post by Brandon Ewing
Greetings,
Historically, I've often used clogin to execute command snippets and other
tasks on large amounts of routers. However, now I'm in a position where we
are using central authorization that utilizes our domain credentials.
Since I'd prefer not to keep my domain password in a text file on a box that
other people have root on, is it possible for clogin (or par) to prompt for
a password at initial execution, instead of relying on storing the cleartext
password on disk, or exposing the password in a history file?

Not exactly, but you could wrap it in shell that prompts then executes
*login -p $passwd
unfortunately, that will appear in ps(1). you could also use include
in the .cloginrc to include a file that the shell wrapper creates during
runtime.

its not impossible to add such a feature though; it just doesnt exist now.

of course, if you can not trust those with root ....

[Brandon Ewing]

Post by heasley
Not exactly, but you could wrap it in shell that prompts then executes
*login -p $passwd
unfortunately, that will appear in ps(1). you could also use include
in the .cloginrc to include a file that the shell wrapper creates during
runtime.
its not impossible to add such a feature though; it just doesnt exist now.
of course, if you can not trust those with root ....

Hrm, I kind of like this approach -- environment variable passing into
command line. Would it be feasible to reset $0 in *login to mask the passed
in password in a process listing?

[Jean Benoit]

Post by Brandon Ewing
Hrm, I kind of like this approach -- environment variable passing into
command line. Would it be feasible to reset $0 in *login to mask the passed
in password in a process listing?

Following your idea and John Heasley's idea, I suggest this solution,
which leaves no trace in a file:

* create a wrapper that asks for password and keep it in memory
as an env. variable then executes a shell

wrapper.sh

#!/bin/bash
echo -n password:
stty -echo
read p
stty echo
RANCIDPASSWORD="$p" exec bash

* put this in .cloginrc

add password * $env(RANCIDPASSWORD)

[heasley]

Post by Jean Benoit

Post by Brandon Ewing
Hrm, I kind of like this approach -- environment variable passing into
command line. Would it be feasible to reset $0 in *login to mask the passed
in password in a process listing?

Following your idea and John Heasley's idea, I suggest this solution,
* create a wrapper that asks for password and keep it in memory
as an env. variable then executes a shell
wrapper.sh
#!/bin/bash
stty -echo
read p
stty echo
RANCIDPASSWORD="$p" exec bash
* put this in .cloginrc
add password * $env(RANCIDPASSWORD)

note that a process'es enviroment is usually also available from ps; ps -e.

[heasley]

Post by Brandon Ewing

Post by heasley
Not exactly, but you could wrap it in shell that prompts then executes
*login -p $passwd
unfortunately, that will appear in ps(1). you could also use include
in the .cloginrc to include a file that the shell wrapper creates during
runtime.
its not impossible to add such a feature though; it just doesnt exist now.
of course, if you can not trust those with root ....

Hrm, I kind of like this approach -- environment variable passing into
command line. Would it be feasible to reset $0 in *login to mask the passed
in password in a process listing?

it may be; i have not tried it. Note however that even doing that would
leave a race, between start-up and squashing the argv[] index.

[Russell Harrison]

It's a bad idea to have secrets appear in argv[], or even to have them
appear in terminal output (I've worked in several environments where all
terminal output was recorded - obviously this includes echoed input).
ssh-askpass and friends offer a convenient way to prompt for a secret
without having that secret appear in process information or terminal output.

Back when kerberos was still commonly supported on network elements it
offered a better way still...

-RH

Post by heasley

Post by Brandon Ewing

Post by heasley
Not exactly, but you could wrap it in shell that prompts then executes
*login -p $passwd
unfortunately, that will appear in ps(1). you could also use include
in the .cloginrc to include a file that the shell wrapper creates

during

Post by Brandon Ewing

Post by heasley
runtime.
its not impossible to add such a feature though; it just doesnt exist

now.

Post by Brandon Ewing

Post by heasley
of course, if you can not trust those with root ....

Hrm, I kind of like this approach -- environment variable passing into
command line. Would it be feasible to reset $0 in *login to mask the

passed

Post by Brandon Ewing
in password in a process listing?

it may be; i have not tried it. Note however that even doing that would
leave a race, between start-up and squashing the argv[] index.
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[Alan McKinnon]

Post by Brandon Ewing
Greetings,
Historically, I've often used clogin to execute command snippets and other
tasks on large amounts of routers. However, now I'm in a position where we
are using central authorization that utilizes our domain credentials.

are the admins of that central system willing to give you a rancid
system account? That's usually a routine corporate request and can be
locked down in a way that will satisfy the auditors

Post by Brandon Ewing
Since I'd prefer not to keep my domain password in a text file on a box that
other people have root on, is it possible for clogin (or par) to prompt for
a password at initial execution, instead of relying on storing the cleartext
password on disk, or exposing the password in a history file?

A system account makes all these problems go away, or makes them irrelevant

[Brandon Ewing]

Post by Alan McKinnon
are the admins of that central system willing to give you a rancid
system account? That's usually a routine corporate request and can be
locked down in a way that will satisfy the auditors

We do have a system account for making configuration backups. However, we
also use centralized syslogging to fire off per-router rancid runs with a
custom change author to allow coarse attribution of changes to individual
users/git blame log. Utilizing a shared account would defeat that purpose.

[Alan McKinnon]

Post by Brandon Ewing

Post by Alan McKinnon
are the admins of that central system willing to give you a rancid
system account? That's usually a routine corporate request and can be
locked down in a way that will satisfy the auditors

We do have a system account for making configuration backups. However, we
also use centralized syslogging to fire off per-router rancid runs with a
custom change author to allow coarse attribution of changes to individual
users/git blame log. Utilizing a shared account would defeat that purpose.

Ah, OK. I never had that problem myself. For us it was always the team
as a whole took the glory and blame for root-level actions. We refused
to let the company single out individuals for blame (a mistake usually
meant I hadn't done enough mentoring).

Internally, we'd expect individuals to fess up to mistakes but it was
very much ring-fenced.

[Brandon Ewing]

Your requirement, typing the password only once at the start of rancid
work session, means the password has to be saved somewhere on the box.
It seems you need to trust those people having root on the box anyway...

Aware that some trust has to be there -- no matter what, my password will
probably be somewhere in /proc or kmem, just trying to raise the bar past
casual snooping.

I'll probably just resort to a cronjob that wipes my .cloginrc every 15
minutes, and I can re-add it when I need to execute a maintenance.

[Brandon Ewing]

Your requirement, typing the password only once at the start of rancid
work session, means the password has to be saved somewhere on the box.
It seems you need to trust those people having root on the box anyway...

Aware that some trust has to be there -- no matter what, my password will
probably be somewhere in /proc or kmem, just trying to raise the bar past
casual snooping.

I'll probably just resort to a cronjob that wipes my .cloginrc every 15
minutes, and I can re-add it when I need to execute a maintenance.

[heasley]

Post by Brandon Ewing
I'll probably just resort to a cronjob that wipes my .cloginrc every 15
minutes, and I can re-add it when I need to execute a maintenance.

you can have a .cloginrc like:

add user glob foo
add user method foo
add user other bar
.... and so on, but without 'add password'
include {/home/you/.clpasswds}

where /home/you/.clpasswds has:
add password glob a b
... and so on.

then in your scenario you just create the latter.

[ it would be nice if vendors would store ssh keys like junos, so you could
use ssh-agent ]

[Patrick Okui]

Post by heasley
[ it would be nice if vendors would store ssh keys like junos, so you
could use ssh-agent ]

Cisco quietly added support for this some time back. Not sure which
vendors support/not support this these days.

--
patrick

[Aaron Dudek]

huawei allows you to store keys.

Post by heasley
[ it would be nice if vendors would store ssh keys like junos, so you
could use ssh-agent ]

Cisco quietly added support for this some time back. Not sure which vendors
support/not support this these days.
--
patrick
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[Brandon Ewing]

Post by Patrick Okui

Post by heasley
[ it would be nice if vendors would store ssh keys like junos, so you
could use ssh-agent ]

Cisco quietly added support for this some time back. Not sure which
vendors support/not support this these days.
--
patrick

But now again you have the issue of key management. It's easy today to
handle user/pass management with centralized TACACS/RADIUS, but if you
don't have the existing structure to automate adding/deleting trusted
keys from each router you are managing, it loses some luster.

Would be nice if they supported LDAP queries of public keys.

[heasley]

Post by Patrick Okui

Post by heasley
[ it would be nice if vendors would store ssh keys like junos, so you
could use ssh-agent ]

Cisco quietly added support for this some time back. Not sure which
vendors support/not support this these days.

isnt this XR only? I rather expected this to ubiquitous across the industry
by now.

[Patrick Okui]

Post by heasley

Post by Patrick Okui

Post by heasley
[ it would be nice if vendors would store ssh keys like junos, so you
could use ssh-agent ]

Cisco quietly added support for this some time back. Not sure which
vendors support/not support this these days.

isnt this XR only? I rather expected this to ubiquitous across the
industry by now.

Late comment but no. IOS 15 added support for RSA based keys. All you
have to do is check for the availability of the `ip ssh pubkey-chain`
command, or select “SSHv2 Enhancements for RSA keys” under the
[cisco feature
navigator](http://tools.cisco.com/ITDIT/CFN/jsp/by-feature-technology.jsp)

To get round the 255 character limit some IOS devices will impose you
can just look at the hash of the key with `ssh-keygen -l -f
~/.ssh/id_rsa.pub | awk '{gsub(/:/,"",$2); print $2}'` and use key-hash
ssh-rsa <HASH> instead of asking the router to do that for you.

--
patrick