> > 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. >
To each their own, but I'm with Jared on this. No way would a vendor have any direct access. The most permissive I'd accept would be a screen share giving temp terminal control, but even then on a production device I REALLY have to trust the person. I've had vendor DEs tell me a given command sequence is 'completely safe on a production device' when working a case , only to find out it actually wasn't. Not something I want them to discover on me at 2am when nobody knows they're doing it. On Mon, Jul 8, 2024 at 2:56 AM Saku Ytti via juniper-nsp < juniper-nsp@puck.nether.net> wrote: > 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 <ja...@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 <j...@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@puck.nether.net > > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > -- > > Jared Mauch | pgp key available via finger from ja...@puck.nether.net > > clue++; | http://puck.nether.net/~jared/ My statements are only > mine. > > > > -- > ++ytti > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp