[j-nsp] Juniper as a route-server

[Mike Benjamin]

It's Unix, you have the FreeBSD telnetd code available to you.  Hack it
up to allow login w/ no username/password and default to user guest.
Manage the box via a getty login on ttyd0 or via sshd with your
"enabled" account.  You're already using an olive, no worries about
support contracts with the box =).

--mikeb

On Thu, Dec 05, 2002 at 05:36:55PM -0000, Guy Davies wrote:
:  
: > -----Original Message-----
: > From: Richard A Steenbergen [mailto:ras@e-gerbil.net]
: > Sent: Thursday, December 05, 2002 5:26 PM
: > To: Guy Davies
: > Cc: juniper-nsp@puck.nether.net
: > Subject: Re: [j-nsp] Juniper as a route-server
: > 
: > 
: > On Thu, Dec 05, 2002 at 05:00:53PM -0000, Guy Davies wrote:
: > > 
: > > 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.
: > 
: > Sorry if I was unclear, I meant a route-server as in a diagnostic box
: > which has a full iBGP mesh, where anyone can connect to look at your
: > routing policies and test connectivity (e.g. route-server.exodus.net,
: > route-server.ip.att.net, route-server.cerf.net, route-server.gblx.net,
: > etc etc etc).
: 
: Ah, you mean like a collector.  That function can be performed.  However,
: the statement regarding passwords for accounts still remains.  In general,
: it's a good thing to have individual accounts for those wishing to access
: the box but it's perfectly feasible to create a group account to which lots
: of people know the password.
: 
: > However, you are right that it is indeed a server and not a 
: > router. Yet 
: > another function which could be better served if Juniper 
: > would legitimize 
: > that little fruit you put in your martini. :)
: > 
: > > 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.
: > 
: > Nonsense, there is nothing wrong with intelligent operators 
: > having the 
: > power to elect a direct login to a specific account without a user or 
: > password. Crisco can do it, why Juniper would choose to 
: > under-power their 
: > authentication policies is beyond me.
: 
: That's fine, if you give them enough rope to hang themselves....  IMHO, that
: is a gross security risk.  As I say, that's just my opinion.  I think
: describing it as nonsense is unfair.  You just hold a different opinion
: which I think exposes you to unacceptable risk.  We clearly have a different
: opinion of what is an acceptable risk so let's leave it at that :-)
: 
: > > 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.
: > 
: > Precisely, this creates a lack-of-feature, in that since you 
: > can't change 
: > users or privileges while connected to the CLI (short of 
: > going to a shell 
: > and su'ing, which isn't something I'm prepared to let the world have 
: > access to), it is much more difficult to run public services box.
: 
: Why would you want to change a users privileges while they're connected to
: the CLI?  You either want the user to have access to particular functions or
: you don't!  You have a great deal of flexibility in setting classes to which
: you can assign users, each of those classes having different subsets of the
: total functionality.  It's certainly more flexible than the fixed number of
: "levels" available with other vendors' software ;-)
: 
: > > 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 ;-)
: > 
: > Well, apparently you can turn it off at any rate. It's there 
: > if I don't 
: > deny anything. The documentation covers permissions for 
: > "quit" from config 
: > mode and "quit" from the shell, but not "quit" from the box. 
: > I'm guessing 
: > its an oversight in that noone ever ran it with an explicit 
: > allow, deny 
: > the rest configuration, but if there is something I'm doing 
: > wrong feel 
: > free to point it out. :)
: 
: Not sure...
: 
: 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