Mailing List Archive

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.

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).

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.

> 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.

> 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. :)

--
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> -----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

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0 (Build 349) Beta

iQA/AwUBPe+OqY3dwu/Ss2PCEQJDBgCeKyTa9loa2mLnr74fVJ64yUuo2qMAoLFX
EqwTfFarpVTJCYs1jgEMCzRo
=bhby
-----END PGP SIGNATURE-----


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.

On Thu, Dec 05, 2002 at 05:36:55PM -0000, Guy Davies wrote:
> 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 :-)

If I didn't want enough rope to hang myself I'd go buy a Linksys.

It shouldn't be that hard, you'd just need telnetd (that being the only
service without an explicit user and pass in the protocol) to check if a
login: prompt is necessary or if it can be handed off to a specific
preconfigured account. Actually I think that functionality is already
there, passed w/setenv USER, depending on what telnetd code Juniper is
using.

> 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 ;-)

Why not? Why would you want su(1) on a unix system when you could just log
out and back in with a different user? You've got the functionality for su
in the shell, why not put it in the cli?

At any rate, just fixing telnetd would temporarily solve the public access
problem (though not very elegantly) while still providing access to
another user via ssh. Unfortunately it doesn't look like the telnetd
they're currently rolling will take the necessary USER via a commandline
arg, or you could just set it in inetd.conf.

--
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

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

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

On Thu, Dec 05, 2002 at 11:26:22AM -0700, Mike Benjamin wrote:
>
> 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 =).

Hahaha, go find the enable password to your own route-server Mike. :)

But seriously, I've already received 4 private emails over this from
people interested in deploying Juniper's in similar situations. Sounds
like this might be a popular thing, worthy of more than bring-your-own
telnetd hacking.

--
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

On Thu, Dec 05, 2002 at 11:26:22AM -0700, Mike Benjamin wrote:
>
> 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.

So close.

Tried:
user guest {
uid 2001;
class guest;
authentication {
encrypted-password ""; # SECRET-DATA
}
}

And a telnetd wrapper called in inetd.conf:

#!/bin/sh
USER="guest"
/usr/libexec/telnetd

But it still prompts for a password (to which there is no valid answer)
the first time through.

Escape character is '^]'.
Password:
Login incorrect
login: guest
Last login: Wed Dec 4 18:51:48 from x.x.x.x

But this proves that it should be really really trivial to fix. And make
that 7 private responses about people wanting to do Juniper route-servers.
:)

--
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

On Thu, 5 Dec 2002 15:12:20 -0500
Richard A Steenbergen <ras@e-gerbil.net> wrote:

> But this proves that it should be really really trivial to fix. And
> make that 7 private responses about people wanting to do Juniper
> route-servers. :)

I hope you're also keeping a tally of those that don't want to see
Juniper become route servers. If so, no-juniper-rs++.

I think it would be much more appropriate to export routing data onto a
system designed to be a route server (e.g. a unix box running zebra).

John

On Thu, Dec 05, 2002 at 02:32:38PM -0600, John Kristoff wrote:

> On Thu, 5 Dec 2002 15:12:20 -0500 Richard A Steenbergen
> <ras@e-gerbil.net> wrote:
>
> > But this proves that it should be really really trivial to fix. And
> > make that 7 private responses about people wanting to do Juniper
> > route-servers. :)
>
> I hope you're also keeping a tally of those that don't want to see
> Juniper become route servers. If so, no-juniper-rs++.

Why on earth would you have anything against that someone else setup a
Juniper router they have bought, as a route-server ?

If Juniper add the ability to login without username/password, you can
choose to use it or not.


/Jesper

--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
Senior network engineer @ AS3292, TDC Tele Danmark

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> On Thu, Dec 05, 2002 at 02:32:38PM -0600, John Kristoff wrote:
>
> > On Thu, 5 Dec 2002 15:12:20 -0500 Richard A Steenbergen
> > <ras@e-gerbil.net> wrote:
> >
> > > But this proves that it should be really really trivial
> to fix. And
> > > make that 7 private responses about people wanting to do Juniper
> > > route-servers. :)
> >
> > I hope you're also keeping a tally of those that don't want to see
> > Juniper become route servers. If so, no-juniper-rs++.
>
> Why on earth would you have anything against that someone else setup a
> Juniper router they have bought, as a route-server ?

So long as they have no problem with their warranty and support contracts
being invalidated, users can do what they like with the boxes. They are,
after all, essentially a FreeBSD box.

> If Juniper add the ability to login without username/password, you can
> choose to use it or not.

So long as any such feature requires explicit configuration, I have no
objection. As I said, give people enough rope... However, I think it would
be a significant degradation of the behaviour of Juniper routers if this
were to become a default behaviour (i.e. accounts created with no
authentication entries allowed login without some explicit command to allow
it).

Guy

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0 (Build 349) Beta

iQA/AwUBPe+7Do3dwu/Ss2PCEQJMwgCgpvDEKt68SLHDWp3LtK9wq11707oAoIjY
w798P/EUoqlDzdSYxuBz1Igi
=O1Cc
-----END PGP SIGNATURE-----


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.

On Thu, Dec 05, 2002 at 03:12:20PM -0500, Richard A Steenbergen wrote:

> Tried:
> user guest {
> uid 2001;
> class guest;
> authentication {
> encrypted-password ""; # SECRET-DATA
> }
> }
>
> And a telnetd wrapper called in inetd.conf:
>
> #!/bin/sh
> USER="guest"
> /usr/libexec/telnetd
>
> But it still prompts for a password (to which there is no valid answer)
> the first time through.
>
> Escape character is '^]'.
> Password:
> Login incorrect
> login: guest
> Last login: Wed Dec 4 18:51:48 from x.x.x.x

What user are you logged in as on the box you are trying this from? Telnet
may be passing that username to the Juniper, so when you tried the above,
the first time it was actually asking for your, and not guest's password.

Try to connect with telnet -l guest instead.
--
Niels Raijer | "Or you could be the one
niels@fusix.nl | Who takes the long way home
http://www.fusix.nl | Roll down your window, turn off your phone"

On Thu, Dec 05, 2002 at 08:46:19PM -0000, Guy Davies wrote:

> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
> > On Thu, Dec 05, 2002 at 02:32:38PM -0600, John Kristoff wrote:
> >
> > > On Thu, 5 Dec 2002 15:12:20 -0500 Richard A Steenbergen
> > > <ras@e-gerbil.net> wrote:
> > >
> > > > But this proves that it should be really really trivial to
> > > > fix. And make that 7 private responses about people wanting to
> > > > do Juniper route-servers. :)
> > >
> > > I hope you're also keeping a tally of those that don't want to see
> > > Juniper become route servers. If so, no-juniper-rs++.
> >
> > Why on earth would you have anything against that someone else setup
> > a Juniper router they have bought, as a route-server ?
>
> So long as they have no problem with their warranty and support
> contracts being invalidated, users can do what they like with the
> boxes. They are, after all, essentially a FreeBSD box.

I'm talking about using it as a route server, if Juniper add the ability
to allow telnet login's without username or password - not about a
hacked up version of JunOS.

> > If Juniper add the ability to login without username/password, you
> > can choose to use it or not.
>
> So long as any such feature requires explicit configuration, I have no
> objection. As I said, give people enough rope... However, I think it
> would be a significant degradation of the behaviour of Juniper routers
> if this were to become a default behaviour (i.e. accounts created with
> no authentication entries allowed login without some explicit command
> to allow it).

As I know Juniper, it's obvious to me that such a feature had to
explicitly configured, and that the current default behaviour would not
change.

/Jesper

--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
Senior network engineer @ AS3292, TDC Tele Danmark

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.

On Thu, Dec 05, 2002 at 02:32:38PM -0600, John Kristoff wrote:
>
> I think it would be much more appropriate to export routing data onto a
> system designed to be a route server (e.g. a unix box running zebra).

And what praytell do you think rpd is? All the functionality, none of the
suck. And trust me, zebra IS the suck. :)

Like I tell people who go off about linux routers running zebra, as long
as you are my competetor I fully encourage you to use it. :)

--
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

On Thu, Dec 05, 2002 at 11:14:11AM -0500, Richard A Steenbergen wrote:
> 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?

There is a bug related to allow-commands, which I believe is "being fixed."
The workaround is to do the reverse - to deny the commands you don't need.
It works, we do it.

SY,
--
CCNP, CCDP (R&S) Dmitri E. Kalintsev
CDPlayer@irc Network Architect @ connect.com.au
dek @ connect.com.au phone: +61 3 8687 5954 fax: 8414 3115
http://-UNAVAIL- UIN:7150410 cell: +61 414 821 382

On Thu, 5 Dec 2002, Richard A Steenbergen wrote:
> And a telnetd wrapper called in inetd.conf:

Why not directly put the cli in inetd.conf?
telnet stream tcp nowait/75/150 guest /usr/sbin/cli cli

Haven't got a clue if this works or not. Just don't use root instead of
guest :)

--
/- Met vriendelijke groet/With kind regards, -\
<- Peter Batenburg - ProServe B.V. - www.proserve.nl ->
\- tel: +31-184-423815 - fax: +31-184-417160 -/