Mailing List Archive

Since we're getting excited about cool software, consider using conserver
(http://www.conserver.com) to manage your serial ports. I agree that
in-band access to network gear isn't ideal, and it would be really cool
if rancid would support connections via an intermediate device.

Given that conserver's interface is pretty simple, I suspect that *login
could be easily modified to utilize something like conserver (or direct
ssh to a serial port, as you suggest), but I haven't looked at it.

Perhaps this is something the user community could request for a future
version?

OH yes...you're completely correct that rancid is a great tool...I don't
know what I'd do without it!

-David

On Sat, Dec 06, 2003 at 08:17:14AM +1000, Andrew Pollock wrote:
> Hi,
>
> I stumbled upon RANCID the other day, and boy is it the bees knees. I've
> written something functionally similar (I haven't looked at RANCID's innards
> yet) but this looks pretty spiffy. We use what I've written to drag configs
> out of Cisco routers, switches and PIXes, and check them into CVS.
>
> One thing that we do is not allow telnet access to our switches. They're all
> connected to Cyclades console access servers, and my script SSHes to the
> Cyclades to get onto the console of the switch. Any thoughts on including
> the ability to connect to a device via an intermediate device?
>
> To my knowledge, you can't setup RSA/DSA key access to a port on a Cyclades,
> which is a bit of a bummer, and to work around the issues with trying to
> authenticate to the Cyclades and then authenticate to the device on the
> Cyclades' port, I've just disabled authentication on the port, so if you SSH
> to the port, you land immediately on the console of the switch, and are
> asked to authenticate to it. In an ideal world, it would be good to have
> port-based authentication switched on...
>
> regards
>
> Andrew


--
David Williamson | "Wine is light, held
Certainty Solutions, Inc. | together by water."
davidw at certaintysolutions.com | -Galileo

David Williamson wrote:

>Given that conserver's interface is pretty simple, I suspect that *login
>could be easily modified to utilize something like conserver (or direct
>ssh to a serial port, as you suggest), but I haven't looked at it.
>
>Perhaps this is something the user community could request for a future
>version?
>
>

I'd definately like to see this also, (not just for lab gear). There
was a little discussion about this a few months back, you might check
the archives to see what came of that.

Greetings Andrew, always nice to see some more folks from Australia
using RANCID :).

On Sat, Dec 06, 2003 at 11:15:05AM +1100, Andrew Fort wrote:
> David Williamson wrote:
>
> >Given that conserver's interface is pretty simple, I suspect that *login
> >could be easily modified to utilize something like conserver (or direct
> >ssh to a serial port, as you suggest), but I haven't looked at it.
> >
> >Perhaps this is something the user community could request for a future
> >version?
> >
> >
>
> I'd definately like to see this also, (not just for lab gear). There
> was a little discussion about this a few months back, you might check
> the archives to see what came of that.

I'll go trawling through the archives...

> Greetings Andrew, always nice to see some more folks from Australia
> using RANCID :).

It was actually your handiwork on Aussie-ISP that alerted me to RANCID's
existence :-) And I'm not using it yet, but if the aforementioned
functionality existed, I could more or less use it as a drop-in replacement
for what I've already written...

Andrew

What if there were a "pre-login" (and perhaps post-disconnect) script (akin
to clogin -s), specified/identified by cloginrc? for example,

add loginscript router* {/usr/local/share/cisco-cons.exp}
add logoutscript router* {/usr/local/share/cisco-cons-disco.exp}

cisco-cons.exp might contain the bits necessary to perform the connection,
after which *login will expect to have a direct connection; thus
"connectscript" may be more apropos (the names are irrelevant). And,
-disco would take care of the disconnect in the same manner.

Those could accompanied by "post-{login,logout}" scripts.

I suspect that both (any) of these would have to meet some expectations of
*login. I'm not sure exactly what those might be, just a nagging thought
in the back of the brain.

I believe what afort referred to in his mail was the idea of having a
"pre-login" command directive in cloginrc. An idea which would be replaced
by this.

That is very rough, completely ignoring how this affects detection of the
disconnect/exit from the device CLI. But, the idea is to allow it to be
adapted however _you_, the user, need.

Thoughts?

Sat, Dec 06, 2003 at 08:17:14AM +1000, Andrew Pollock:
> Hi,
>
> I stumbled upon RANCID the other day, and boy is it the bees knees. I've
> written something functionally similar (I haven't looked at RANCID's innards
> yet) but this looks pretty spiffy. We use what I've written to drag configs
> out of Cisco routers, switches and PIXes, and check them into CVS.
>
> One thing that we do is not allow telnet access to our switches. They're all
> connected to Cyclades console access servers, and my script SSHes to the
> Cyclades to get onto the console of the switch. Any thoughts on including
> the ability to connect to a device via an intermediate device?
>
> To my knowledge, you can't setup RSA/DSA key access to a port on a Cyclades,
> which is a bit of a bummer, and to work around the issues with trying to
> authenticate to the Cyclades and then authenticate to the device on the
> Cyclades' port, I've just disabled authentication on the port, so if you SSH
> to the port, you land immediately on the console of the switch, and are
> asked to authenticate to it. In an ideal world, it would be good to have
> port-based authentication switched on...
>
> regards
>
> Andrew

On Sat, Dec 06, 2003 at 11:15:05AM +1100, Andrew Fort wrote:
>
> I'd definately like to see this also, (not just for lab gear). There
> was a little discussion about this a few months back, you might check
> the archives to see what came of that.

(htdig seems busted, the archive files aren't particularly friendly)

Okay, I'm now having a serious play with RANCID, and I'd like to see it do
the out of band stuff I mentioned a while ago (i.e. we have switches,
they're not telnetable, but the console is accessible via SSH to a Cyclades
console access server).

Can someone point me in the right direction as to what I'd have to modify to
implement this?

regards

Andrew

On 22/01/2004 10:33 AM, Andrew Pollock wrote:

>Okay, I'm now having a serious play with RANCID, and I'd like to see it do
>the out of band stuff I mentioned a while ago (i.e. we have switches,
>they're not telnetable, but the console is accessible via SSH to a Cyclades
>console access server).
>
>Can someone point me in the right direction as to what I'd have to modify to
>implement this?
>

Referring to Heas' previous reply to your post to the list, to add the
'loginscript' or 'connectscript' type of functionality, one would need
to hack the *login scripts.

You could start by hacking clogin (if cisco switches are your targets,
obviously), modifying the procedure 'login'. At first glance, you're
probably wanting to source another expect script before the line

# try each of the connection methods in $cmethod until one is successful
set progs [llength $cmethod]

e.g.

source $filename

With all the necessary expect business occuring in $filename to login to
the cyclades up to such a point that you'd be typing "telnet hostname
port" or similar to connect to the cisco. In theory you could use
autoexpect to generate this script. In addition, you'd need to flag to
clogin that you're running a prelogin script, otherwise it would expect
to be running 'spawn telnet hostname [args]' (or ssh, etc depending on
your method flag), which obviously doesn't grok since you're already
SSH'd in), and send the command instead of spawning the command. Then,
you'd need to catch the prompt of the cyclades again to indicate to
expect that you want to bail out of that loop.

. The 'hostname' and 'port' values would come from your router.db and
cloginrc values for those entries.

In regards to the port values, you specify these in the cloginrc file as
follows:

add method sw1.popname {telnet:2001}

However if this doesn't work for you, try

add method sw1.popname {telnet:-2001}

I'm happy to help in getting this working, or testing this (I have some
terminal servers in my lab I'd like to get configs through, too), so
feel free to contact me offline if you like.

-afort

On Thu, Jan 22, 2004 at 11:06:52AM +1100, Andrew Fort wrote:
> add method sw1.popname {telnet:2001}

With a small amount of hacking, rancid could support
add method sw1.popname {ssh:2001}
as well, so you would be a step closer to sshing to some port on
your terminal server to connect to some device's console.

[.I recently turned telnet off in my console servers & started using
ssh instead. Works nicely & one less use of telnet around here.]

Anyone want to try these changes to clogin to support sshing to a
port?
--asp

--- clogin.in.orig Mon Jan 19 20:52:47 2004
+++ clogin.in Wed Jan 21 19:46:42 2004
@@ -306,8 +306,14 @@
send_user "\nError: telnet failed: $reason\n"
exit 1
}
- } elseif ![string compare $prog "ssh"] {
- if [. catch {spawn $sshcmd -c $cyphertype -x -l $user $router} reason ] {
+ } elseif [string match "ssh*" $prog] {
+ regexp {ssh(:([^[:space:]]+))*} $prog command suffix port
+ if {"$port" == ""} {
+ set retval [. catch {spawn $sshcmd -c $cyphertype -x -l $user $router} reason ]
+ } else {
+ set retval [. catch {spawn $sshcmd -c $cyphertype -x -l $user -p $port $router} reason ]
+ }
+ if { $retval } {
send_user "\nError: $sshcmd failed: $reason\n"
exit 1
}

On Thu, Jan 22, 2004 at 11:06:52AM +1100, Andrew Fort wrote:
> On 22/01/2004 10:33 AM, Andrew Pollock wrote:
>
> >Okay, I'm now having a serious play with RANCID, and I'd like to see it do
> >the out of band stuff I mentioned a while ago (i.e. we have switches,
> >they're not telnetable, but the console is accessible via SSH to a Cyclades
> >console access server).
> >
> >Can someone point me in the right direction as to what I'd have to modify
> >to
> >implement this?
> >
>
> Referring to Heas' previous reply to your post to the list, to add the
> 'loginscript' or 'connectscript' type of functionality, one would need
> to hack the *login scripts.
>
> You could start by hacking clogin (if cisco switches are your targets,
> obviously), modifying the procedure 'login'. At first glance, you're
> probably wanting to source another expect script before the line

[snip]

Thanks for the very detailed pointer. That helps get me started.

The way I have our Cyclades setup is you can SSH to it thusly:

ssh andrew:switch1 at mycyclades
or
ssh -l andrew:switch1 mycyclades

and you'll land straight onto the console port in question. Obviously you
need to send a ~. to get off again. So you don't spend any time on the
console server itself.

Is it best to hack in a new method along the lines of "cas" and a have a cas
user and password in cloginrc? Then the foreach loop of the login procedure
would just do nothing if the method was cas, and I'd be conditionally
sourcing another script prior to the foreach that handles connecting to the
port if the method was cas. Then the rest of the login procedure should be
able to cope from there. I guess I'd just have to handle disconnecting from
the port then somewhere as well.

regards

Andrew

* Andrew Pollock <rancid-andrew at andrew.net.au> [2004-01-22 11:10:40 +1000]:

> [snip]
>
> Thanks for the very detailed pointer. That helps get me started.
>
> The way I have our Cyclades setup is you can SSH to it thusly:
>
> ssh andrew:switch1 at mycyclades
> or
> ssh -l andrew:switch1 mycyclades
>
> and you'll land straight onto the console port in question. Obviously you
> need to send a ~. to get off again. So you don't spend any time on the
> console server itself.

So this works now? (or perhaps with asp's patch he posted)?

add username mycyclades {andrew:switch1}
add userpasswd mycyclades {blah}

just that you have the overloaded 'mycyclades' issue to resolve?

> Is it best to hack in a new method along the lines of "cas" and a have a cas
> user and password in cloginrc? Then the foreach loop of the login procedure
> would just do nothing if the method was cas, and I'd be conditionally
> sourcing another script prior to the foreach that handles connecting to the
> port if the method was cas. Then the rest of the login procedure should be
> able to cope from there. I guess I'd just have to handle disconnecting from
> the port then somewhere as well.

changing rancid minimally would suggest (if i'm right above) that you have multiple host aliases (for the switches' names) all pointing to the same IP address of mycyclades, and you treat them differently in .cloginrc (different username password pairs per 'switch'); and then just ssh to the 'switch' (really the cyclades with the extended username).

> regards
> Andrew

-afort (away for a week to have surgery.. wish me luck :)