[j-nsp] Juniper as a route-server

[dave o'leary]

Richard,
Outside of working through the details of the router functionality
as contrasted to route server functionality as described by Guy below,
perhaps a way to implement the changes/change control is to
use another separate system (unix box) with scripts to change the
config of the router via JUNOScript.  This might allow you to disentangle
the authentication/authorization issues from those of generating
valid configs, etc. and not allowing unauthorized users to screw up
the route service for others.

                                                 dave

At 05:00 PM 12/5/2002 +0000, Guy Davies wrote:
>Hi Richard,
>
>Answers inline...
>
> > -----Original Message-----
> > From: Richard A Steenbergen [mailto:ras@e-gerbil.net]
> > Sent: Thursday, December 05, 2002 4:14 PM
> > To: juniper-nsp@puck.nether.net
> > Subject: [j-nsp] Juniper as a route-server
> >
> >
> > I'm not sure if anyone has tried to do this, but I would like
> > to use a
> > Juniper as a route-server. Unfortunately, I'm hitting a few snags, so
> > perhaps someone else has more experience trying to do this.
>
>This is kind of using the Juniper as a server rather than a router.  That's
>not really what it was designed for.  It certainly doesn't do BGP the way
>Route servers do (e.g. hiding its AS, setting next-hop to someone else,
>creating views of the routing table based on routing policy).  Route servers
>are a somewhat specialised function which isn't really appropriate for a
>router.
>
> > First problem, is there any way to make a telnet connection
> > log directly
> > into the box without having to enter an account? A suppose a
> > "guest/guest"
> > system could work (since I can't seem to find a way to have an account
> > with no password either), but I'd REALLY prefer not.
>
>How can I put this?  No, no, no, no, no!  There is no way to log into the
>box without an account and this is, without any doubt, a *very* good thing.
>Even if you have an account, if it has no password, then you can't get in
>(unless you've configured an SSH key in which case, the relevant user can
>login with no prompt using ssh).  If you're using a script, then you just
>need to make sure that you force the script to use the required user in SSH.
>
> > Second problem, even if you could make a telnet connection go
> > directly
> > into a guest account, how would you get administrative access
> > to the box
> > with no "enable"?
>
>There's no concept of "enable" in JUNOS.  An account either has
>administrative privileges, or it doesn't.  It's a feature of each account
>based on the class.  If you create an account with class superuser and
>configure it so that it uses a SSH public key for authentication, then
>you'll get in to the box, with no password prompt and have full access to
>everything (assuming you have access to the relevant SSH private key ;-)
>
> > And a third problem, I'm trying to restrict unnecessary commands for
> > security reasons, using the following config:
> >
> >         class guest {
> >             idle-timeout 5;
> >             permissions view;
> >             allow-commands "(show route.*|show bgp
> > summary|set cli.*|ping|traceroute|quit)";
> >             deny-commands .*;
> >         }
> >
> > Unfortunately, the "quit" part doesn't want to work. I've
> > tried "quit.*"
> > and a few other variants, but quit never shows up as an
> > available command
> > like it should (5.5R2.3). Any ideas?
>
>I suspect that quit or exit are default commands that cannot be turned on or
>off.  Since you're kind of screwed if you can logon but can't disconnect or
>can go down the config tree but can't get back up it to the root ;-)
>
>Regards,
>
>Guy
>
>
>This e-mail is private and may be confidential and is for the intended
>recipient only.  If misdirected, please notify us by telephone and confirm
>that it has been deleted from your system and any copies destroyed.  If you
>are not the intended recipient you are strictly prohibited from using,
>printing, copying, distributing or disseminating this e-mail or any
>information contained in it.  We use reasonable endeavors to virus scan all
>e-mails leaving the Company but no warranty is given that this e-mail and
>any attachments are virus free.  You should undertake your own virus
>checking.  The right to monitor e-mail communications through our network is
>reserved by us.
>
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>http://puck.nether.net/mailman/listinfo/juniper-nsp