> -----Original Message-----
> From: Jerin Jacob <jerinjac...@gmail.com>
> Sent: Wednesday, September 21, 2022 7:37 AM
> To: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>
> Cc: Owen Hilyard <ohily...@iol.unh.edu>; Bruce Richardson
> <bruce.richard...@intel.com>; Stanislaw Kardach <k...@semihalf.com>; Juraj
> Linkeš <juraj.lin...@pantheon.tech>; tho...@monjalon.net; David Marchand
> <david.march...@redhat.com>; ronan.rand...@intel.com; Tu, Lijuan
> <lijuan...@intel.com>; dev <dev@dpdk.org>; nd <n...@arm.com>;
> jer...@marvell.com; hemant.agra...@nxp.com
> Subject: Re: [PATCH v4 4/9] dts: add ssh pexpect library
>
> On Tue, Sep 20, 2022 at 11:25 PM Honnappa Nagarahalli
> <honnappa.nagaraha...@arm.com> wrote:
> >
> > <snip>
> > > >
> > > > On Fri, Jul 29, 2022 at 10:55:45AM +0000, Juraj Linkeš wrote:
> > > > <snip>
> > > > > + self.session = pxssh.pxssh(encoding="utf-8")
> > > > > + self.session.login(
> > > > > + self.node,
> > > > > + self.username,
> > > > > + self.password,
> > > > > + original_prompt="[$#>]",
> > > > > +
> > > > password_regex=r"(?i)(?:password:)|(?:passphrase for
> > > > key)|(?i)(password for .+:)",
> > > > > + )
> > > > > + [1]self.logger.info(f"Connection to {self.node}
> > > > succeeded")
> > > > > + self.send_expect("stty -echo", "#")
> > > > > + self.send_expect("stty columns 1000", "#")
> > > > First of all, thanks for those changes! Having DTS inside DPDK
> > > > makes
> > > > test synchronization a lot easier. I'm happy to say
> > > > (unsurprisingly)
> > > > that it works with my RISC-V HiFive Unmatched board like a charm.
> > > >
> > > >
> > > > Though there is a small issue with the lines above. They assume "#"
> > > > as
> > > > the prompt sign, even though original_prompt was set to "[$#>]".
> > > > This
> > > > touches on two problems:
> > > > 1. # is usually a root prompt - is DTS assumed to be run with root
> > > > privileges? DPDK may (in theory) run without them with some
> > > > permission
> > > > adjustment (hugetlb, VFIO container, etc.). If we assume DTS
> > > > needs
> > > > root access, this has to be both documented and validated before
> > > > running the whole suite. Otherwise it'll be hard to debug.
> > > >
> > > >
> > > > Around a year ago there were some attempts to get DTS to not require
> > > > root. This ended up running into issues because DTS sets up drivers
> > > > for
> > > > you, which requires root as far as I know, as well as setting up
> > > > hugepages, which I think also requires root. The current version of
> > > > DTS
> > > > can probably run without root, but it will probably stop working as
> > > > soon as DTS starts interacting with PCI devices. Elevating privileges
> > > > using pkexec or sudo is less portable and would require supporting a
> > > > lot more forms of authentication (kerberos/ldap for enterprise
> > > > deployments, passwords, 2fa, etc). It is much easier to say that the
> > > > default SSH agent must provide root access to the SUT and Traffic
> > > > Generator either with a password or pre-configured passwordless
> > > > authentication (ssh keys, kerberos, etc).
> > > >
> > > > [Honnappa] One of the feedback we collected asks to deprecate the use
> > > > of clear text passwords in config files and root user. It suggests to
> > > > use keys and sudo. It is a ‘Must Have’ item.
> > > >
> > > >
> > > > I agree it should be documented. I honestly didn't consider that
> > > > anyone
> > > > would try running DTS as a non-root user.
> > > >
> > > > [Honnappa] +1 for supporting root users for now and documenting.
> > > >
> > > >
> > > > 2. Different shells use different prompts on different distros.
> > > > Hence
> > > > perhaps there should be a regex here (same as with
> > > > original_prompt)
> > > > and there could be a conf.yaml option to modify it on a per-host
> > > > basis?
> > > >
> > > >
> > > > As far as customizing the prompts, I think that is doable via a
> > > > configuration option.
> > > > As far as different shells, I don't think we were planning to support
> > > > anything besides either bash or posix-compatible shells. At the
> > > > moment
> > > > all of the community lab systems use bash, and for ease of test
> > > > development it will be easier to mandate that everyone uses one
> > > > shell.
> > > > Otherwise DTS CI will need to run once for each shell to catch
> > > > issues,
> > > > which in my opinion are resources better spent on more in-depth
> > > > testing
> > > > of DTS and DPDK.
> > > >
> > > > [Honnappa] +1 for using just bash, we can document this as well.
> > > >
> > >
> > > I would agree overall. Just supporting one shell is fine - certainly
> > > for now. Also completely agree that we need to remove hard-coded
> > > passwords and ideally non-root. However, I think for the initial
> > > versions the main thing should be removing the passwords so I would be ok
> for keeping the "root"
> > > login requirement, so long as we support using ssh keys for login
> > > rather than hard-coded passwords.
> > I would be for dropping support for the hard-coded passwords completely.
> Setting up the password-less SSH is straightforward (not sure if you meant the
> same).
> >
> > >
> > > /Bruce
> >
> >
> > I think the question is whether there are any platforms/devices that should
> > be
> tested by DTS that do not support passwordless SSH. Right now, the community
> lab is using SSH keys for everything. If Intel also doesn't need passwords,
> then
> it's up to the community whether to support them at all. It does make it a lot
> easier on DTS if we can just require that the active OpenSSH agent can log
> into
> all of the systems involved without a password. This would also make it
> easier to
> enable AD authentication for Windows.
> >
> > [Honnappa] Jerin, Hemant do you have any concerns for your platforms
> regarding this?
>
> No. We are using passwordless SSH in our CI testing framework.
Based on the e-mail discussion and a brainstorming session (where we talked
over the implications for the whole DTS codebase) the best approach seems to be:
1. Don't use root. Intead, use passwordless sudo with a regular user (where
needed). This requires a bit of server setup, which I'll document.
2. Support password authentication, but don't document it. It would be
basically a last resort if for any reason keys can't be used.
3. Strongly encourage the use of SSH keys by documenting it, but not
documenting password logins.
Let me know what you all think, especially about 2 - does that make sense or do
we want to remove password authentication support altogether?
