[j-nsp] Logging for shell sessions

[Saku Ytti]

This depends greatly on how you've set up your support.

If you have Cisco HTTS or Juniper ACP or the like, where you get named
engineers, then you can develop a mutual trust and give those
engineers access to your network.

But if you're going through a normal process, perhaps additional care
is warranted.

On Sun, 7 Jul 2024 at 19:34, Jared Mauch <jared at puck.nether.net> wrote:
>
>         I don't trust my vendors to run commands on my devices, it's not
> personal.  If there is a diagnostic that they want run, they need to be
> able to articulate the operational risk, or we may want to validate in a
> virtual or real physical router.
>
>         - Jared
>
> On Sun, Jul 07, 2024 at 11:07:48AM +0300, Saku Ytti via juniper-nsp wrote:
> > For things like TAC use, what I've previously done is made a vendor
> > shell, where the shell program is screen instead of shell, and screen
> > is set up to log.
> >
> >
> > On Sat, 6 Jul 2024 at 16:50, Job Snijders <job at sobornost.net> wrote:
> > >
> > > Perhaps it’s just about wanting to keep track “what happened?!?”
> > >
> > > For such a scenario, consider conserver
> > > https://www.conserver.com/docs/console.man.html and script
> > > http://man.openbsd.org/script to store the terminal interactions
> > >
> > > Assume untrusted users probably can escape these such environments
> > >
> > > Kind regards,
> > >
> > > Job
> >
> >
> >
> > --
> >   ++ytti
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> --
> Jared Mauch  | pgp key available via finger from jared at puck.nether.net
> clue++;      | http://puck.nether.net/~jared/  My statements are only mine.



-- 
  ++ytti