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 E2663A034C; Wed, 21 Sep 2022 07:37:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B523540E0F; Wed, 21 Sep 2022 07:37:32 +0200 (CEST) Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by mails.dpdk.org (Postfix) with ESMTP id 9655140E0F for ; Wed, 21 Sep 2022 07:37:31 +0200 (CEST) Received: by mail-qk1-f170.google.com with SMTP id q11so3266939qkc.12 for ; Tue, 20 Sep 2022 22:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=XOunp3IiBzpLc7QHBaGjyFiRjzZghAo+yTry4E6ruGU=; b=pZR6MA4F1g86XlWpRwcHcFipCzKrMprEHrewNul1+AE+wHaDtQmUF8c3AbJ7K1wTdH Zs+t9ZRZHzQwai28tvjhwb7axvtPUywHa8ReRgau+Eqj4osAmtfpqhoBoeQvOHIur21g 5nd4ft1uoyiov1VGLEFK6aIT64EM4xYLWnjwtsC4VRYzPloR+0MrGdWLpj8jL2m8vRMn bRP+AX+ngXon3pJ80czP2cJxLmf5MFgEC3cuYf/yJgEZxPa98Dnh73bAd9BbIpa1vv/G yI1sxCM7wTMQMKXowzORVlJKqxRhcuBRQlQ7ZC+dyfvCKvcYGI/3TQ/YevyZqxy6BafC FiEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=XOunp3IiBzpLc7QHBaGjyFiRjzZghAo+yTry4E6ruGU=; b=GAhnkpw7tEhu72h0qoFHiEV5huNiwvt35miByHRJNDgzHI6PYp9m1K+kmlcf/XD/c4 AQNr6zT6Xq47/x8k8QxpiwtLDCH45q9weQNQ/ym4q3nkTkFlQHTtj+8JpLpSxOAZ2QZp r7IRQmNwkLil7nQjIU6IOQdjE02ACWN73jywU3zBrGveRTIvX3DKmSSqFBQz2pqGGIK4 avneefffGsMOLVuZnCcZv9E3W4shTgeM+e1b5n0Vb6YL5v4sL5CMqdnZB+h8ts9EgToM xtxrlHy/MbTJMVrFxWUNcpK8JMi7msrU9DcrlK9XaKsAoHf93+JzXWCwJDDTg7zvUdbr ViTQ== X-Gm-Message-State: ACrzQf3orUuJ9v+MUUQoWzZIxSafQJEXum9QgY0nwkOKLs8QVeGqx57n CSTk+BUnFTkTH9+K8WYmDS5a+j/pf3FU/pYG9DQ= X-Google-Smtp-Source: AMsMyM5EocJr+dWzsNfG+o3KNTaSAG4TKLqhalUqZF6tybXdmFD5LcMYH7CWFTrTTlNgH/fhRfOk10R6nG4ww/8f58I= X-Received: by 2002:a05:620a:4248:b0:6be:7848:3ce5 with SMTP id w8-20020a05620a424800b006be78483ce5mr18954018qko.26.1663738650892; Tue, 20 Sep 2022 22:37:30 -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: Jerin Jacob Date: Wed, 21 Sep 2022 11:07:04 +0530 Message-ID: Subject: Re: [PATCH v4 4/9] dts: add ssh pexpect library To: Honnappa Nagarahalli Cc: Owen Hilyard , Bruce Richardson , Stanislaw Kardach , =?UTF-8?Q?Juraj_Linke=C5=A1?= , "thomas@monjalon.net" , David Marchand , "ronan.randles@intel.com" , "Tu, Lijuan" , dev , nd , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Tue, Sep 20, 2022 at 11:25 PM Honnappa Nagarahalli 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.nod= e} > > > succeeded") > > > > + self.send_expect("stty -echo", "#") > > > > + self.send_expect("stty columns 1000", "#") > > > First of all, thanks for those changes! Having DTS inside DPDK m= akes > > > test synchronization a lot easier. I'm happy to say (unsurprisin= gly) > > > 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 bef= ore > > > 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 privile= ges > > > 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 a= nyone > > > 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-h= ost > > > 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 supp= ort > > > anything besides either bash or posix-compatible shells. At the mo= ment > > > all of the community lab systems use bash, and for ease of test > > > development it will be easier to mandate that everyone uses one sh= ell. > > > Otherwise DTS CI will need to run once for each shell to catch iss= ues, > > > which in my opinion are resources better spent on more in-depth te= sting > > > 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 shou= ld 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 meant = the same). > > > > > /Bruce > > > I think the question is whether there are any platforms/devices that shou= ld be tested by DTS that do not support passwordless SSH. Right now, the c= ommunity lab is using SSH keys for everything. If Intel also doesn't need p= asswords, 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 Ope= nSSH agent can log into all of the systems involved without a password. Thi= s would also make it easier to enable AD authentication for Windows. > > [Honnappa] Jerin, Hemant do you have any concerns for your platforms rega= rding this? No. We are using passwordless SSH in our CI testing framework.