From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F1F2AA00C3; Mon, 19 Sep 2022 16:22:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9556140E0F; Mon, 19 Sep 2022 16:22:12 +0200 (CEST) Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by mails.dpdk.org (Postfix) with ESMTP id A1CB540141 for ; Mon, 19 Sep 2022 16:22:10 +0200 (CEST) Received: by mail-pg1-f178.google.com with SMTP id s206so26929927pgs.3 for ; Mon, 19 Sep 2022 07:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=lGoKO9rpA345ahiNx4ZHgU5cMBG7uitnOYbT8gT17nM=; b=NCstZlaUS4CPqVsL1cYiMaaVU4PTGhiwKDD6q/C7TSIgCfUS/sNFqFK7bCGIHo6Qy+ S6bhBdLdtnYef4/I7bKpIts/4i0QEc8qOLSycSXzXhYGODfvKd9/g2n7x0CADgi4M0DN L36ly1Hx9lKQI4J4KNbpEZ7E0BLumfyOMKSeI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=lGoKO9rpA345ahiNx4ZHgU5cMBG7uitnOYbT8gT17nM=; b=fYd29t7PojpY7qwDPFH+jd4DXDVdLeSLAQhZxsZJaPz9FjbXm90SyjXzFs86o9lsE8 +Wvh+GeRFH/sHP1y1GqF00E14FZ4AjEtSZ5hFKaGEbQg62GJflsVLYRe7CnfwZKn0noB RmBaUL/cfwSdBuFHjg65JsEhy0Dq1AZRpWAUSSC60DDOZU9FYHyJCCEL10h2Rw09ClHG inS5pLYgpX6T0nf72K9892+78+keUArtIqJK07HxdRecFUo/RpcgqP+NzbPMLld2FlBs iVfGIoufnMdXwo/nnjet2YGSgvn22FxCmJucUyLFr2Axm4oiSjtfsoI8dl5NBPQb5CDw GU2A== X-Gm-Message-State: ACrzQf1/YNCfQUagMUPm8USxFr1Yn6f3WEYqxytkcUlZJ67tw+DFzSK9 JcaUaJRLpEHXAZT4tezi/DpQUGFvH6NA8mKWAtRZV2kvUW8= X-Google-Smtp-Source: AMsMyM6SOF7aE8kggL7y/Ljd/o+idB3oMbSjIBveOdYHWMO2+j9HnSpX/WTfDhvJe5HmTfls4tnMOZRJ/XxFHNlI9No= X-Received: by 2002:a63:555a:0:b0:43a:20e5:101f with SMTP id f26-20020a63555a000000b0043a20e5101fmr4581061pgm.48.1663597329727; Mon, 19 Sep 2022 07:22:09 -0700 (PDT) MIME-Version: 1.0 References: <20220728100044.1318484-1-juraj.linkes@pantheon.tech> <20220729105550.1382664-1-juraj.linkes@pantheon.tech> <20220729105550.1382664-5-juraj.linkes@pantheon.tech> <20220913144149.xbtomt2pzwywnodn@toster> In-Reply-To: From: Owen Hilyard Date: Mon, 19 Sep 2022 10:21:33 -0400 Message-ID: Subject: Re: [PATCH v4 4/9] dts: add ssh pexpect library To: Honnappa Nagarahalli Cc: Bruce Richardson , Stanislaw Kardach , =?UTF-8?Q?Juraj_Linke=C5=A1?= , "thomas@monjalon.net" , David Marchand , "ronan.randles@intel.com" , "Tu, Lijuan" , dev , nd Content-Type: multipart/alternative; boundary="000000000000e3a81e05e9086fde" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000e3a81e05e9086fde Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 14, 2022 at 3:57 PM Honnappa Nagarahalli < Honnappa.Nagarahalli@arm.com> wrote: > > > > > > > > On Fri, Jul 29, 2022 at 10:55:45AM +0000, Juraj Linke=C5=A1 wrot= e: > > > > > > > + self.session =3D pxssh.pxssh(encoding=3D"utf-= 8") > > > > + self.session.login( > > > > + self.node, > > > > + self.username, > > > > + self.password, > > > > + original_prompt=3D"[$#>]", > > > > + > > > password_regex=3Dr"(?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 ro= ot > > > 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 requi= re > > > root. This ended up running into issues because DTS sets up driver= s > 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 o= f > DTS > > > can probably run without root, but it will probably stop working a= s > > > 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 t= he > > > 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 =E2=80=98Must Have=E2=80=99 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 fo= r > now. Also > > completely agree that we need to remove hard-coded passwords and ideall= y > > 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 rathe= r > 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 mean= t > 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. --000000000000e3a81e05e9086fde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Sep 14, 2022 at 3:57 PM Honnappa Naga= rahalli <Honnappa.Nagarahalli@arm.com> wrote:
<snip>

> >
> >=C2=A0 =C2=A0 =C2=A0 On Fri, Jul 29, 2022 at 10:55:45AM +0000, Jur= aj Linke=C5=A1 wrote:
> >=C2=A0 =C2=A0 =C2=A0 <snip>
> >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 self.session =3D pxssh.pxssh(encoding=3D"utf-8"= )
> >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 self.session.login(
> >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.node,
> >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.username,
> >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.password,
> >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 original_prompt=3D"[$#>]",
> >=C2=A0 =C2=A0 =C2=A0 > +
> >=C2=A0 =C2=A0 =C2=A0 password_regex=3Dr"(?i)(?:password:)|(?:= passphrase for
> >=C2=A0 =C2=A0 =C2=A0 key)|(?i)(password for .+:)",
> >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 )
> >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 [1]self.logger.info(f"Connection to {self.node} > >=C2=A0 =C2=A0 =C2=A0 succeeded")
> >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 self.send_expect("stty -echo", "#")
> >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 self.send_expect("stty columns 1000", "#")
> >=C2=A0 =C2=A0 =C2=A0 First of all, thanks for those changes! Havin= g DTS inside DPDK makes
> >=C2=A0 =C2=A0 =C2=A0 test synchronization a lot easier. I'm ha= ppy to say (unsurprisingly)
> >=C2=A0 =C2=A0 =C2=A0 that it works with my RISC-V HiFive Unmatched= board like a charm.
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 Though there is a small issue with the lines = above. They assume "#"
> >=C2=A0 =C2=A0 =C2=A0 as
> >=C2=A0 =C2=A0 =C2=A0 the prompt sign, even though original_prompt = was set to "[$#>]".
> >=C2=A0 =C2=A0 =C2=A0 This
> >=C2=A0 =C2=A0 =C2=A0 touches on two problems:
> >=C2=A0 =C2=A0 =C2=A0 1. # is usually a root prompt - is DTS assume= d to be run with root
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0privileges? DPDK may (in theory)= run without them with some
> >=C2=A0 =C2=A0 =C2=A0 permission
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0adjustment (hugetlb, VFIO contai= ner, etc.). If we assume DTS
> >=C2=A0 =C2=A0 =C2=A0 needs
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0root access, this has to be both= documented and validated before
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0running the whole suite. Otherwi= se it'll be hard to debug.
> >
> >
> >=C2=A0 =C2=A0 Around a year ago there were some attempts to get DT= S to not require
> >=C2=A0 =C2=A0 root. This ended up running into issues because DTS = sets up drivers for
> >=C2=A0 =C2=A0 you, which requires root as far as I know, as well a= s setting up
> >=C2=A0 =C2=A0 hugepages, which I think also requires root. The cur= rent version of DTS
> >=C2=A0 =C2=A0 can probably run without root, but it will probably = stop working as
> >=C2=A0 =C2=A0 soon as DTS starts interacting with PCI devices. Ele= vating privileges
> >=C2=A0 =C2=A0 using pkexec or sudo is less portable and would requ= ire supporting a
> >=C2=A0 =C2=A0 lot more forms of authentication (kerberos/ldap for = enterprise
> >=C2=A0 =C2=A0 deployments, passwords, 2fa, etc). It is much easier= to say that the
> >=C2=A0 =C2=A0 default SSH agent must provide root access to the SU= T and Traffic
> >=C2=A0 =C2=A0 Generator either with a password or pre-configured p= asswordless
> >=C2=A0 =C2=A0 authentication (ssh keys, kerberos, etc).
> >
> >=C2=A0 =C2=A0 [Honnappa] One of the feedback we collected asks to = deprecate the use
> >=C2=A0 =C2=A0 of clear text passwords in config files and root use= r. It suggests to
> >=C2=A0 =C2=A0 use keys and sudo. It is a =E2=80=98Must Have=E2=80= =99 item.
> >
> >
> >=C2=A0 =C2=A0 I agree it should be documented. I honestly didn'= ;t consider that anyone
> >=C2=A0 =C2=A0 would try running DTS as a non-root user.
> >
> >=C2=A0 =C2=A0 [Honnappa] +1 for supporting root users for now and = documenting.
> >
> >
> >=C2=A0 =C2=A0 =C2=A0 2. Different shells use different prompts on = different distros.
> >=C2=A0 =C2=A0 =C2=A0 Hence
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0perhaps there should be a regex = here (same as with
> >=C2=A0 =C2=A0 =C2=A0 original_prompt)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and there could be a conf.yaml o= ption to modify it on a per-host
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0basis?
> >
> >
> >=C2=A0 =C2=A0 As far as customizing the prompts, I think that is d= oable via a
> >=C2=A0 =C2=A0 configuration option.
> >=C2=A0 =C2=A0 As far as different shells, I don't think we wer= e planning to support
> >=C2=A0 =C2=A0 anything besides either bash or posix-compatible she= lls. At the moment
> >=C2=A0 =C2=A0 all of the community lab systems use bash, and for e= ase of test
> >=C2=A0 =C2=A0 development it will be easier to mandate that everyo= ne uses one shell.
> >=C2=A0 =C2=A0 Otherwise DTS CI will need to run once for each shel= l to catch issues,
> >=C2=A0 =C2=A0 which in my opinion are resources better spent on mo= re in-depth testing
> >=C2=A0 =C2=A0 of DTS and DPDK.
> >
> >=C2=A0 =C2=A0 [Honnappa] +1 for using just bash, we can document t= his as well.
> >
>
> I would agree overall. Just supporting one shell is fine - certainly f= or now. Also
> completely agree that we need to remove hard-coded passwords and ideal= ly
> non-root. However, I think for the initial versions the main thing sho= uld be
> removing the passwords so I would be ok for keeping the "root&quo= t;
> login requirement, so long as we support using ssh keys for login rath= er than
> hard-coded passwords.
I would be for dropping support for the hard-coded passwords completely. Se= tting up the password-less SSH is straightforward (not sure if you meant th= e 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.=C2=A0 Right now, the community lab is using SSH keys for = everything. If Intel also doesn't need passwords, then it's up to t= he community whether to support them at all. It does make it a lot easier o= n 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.=C2=A0
--000000000000e3a81e05e9086fde--