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
