From ericjmonson@gmail.com Fri Apr 15 02:16:48 2022 Received: (at submit) by bugs.x2go.org; 15 Apr 2022 00:16:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=0.7 required=3.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 77BCB5DA94 for ; Fri, 15 Apr 2022 02:16:48 +0200 (CEST) Received: by mail-lf1-x12a.google.com with SMTP id bu29so11807614lfb.0 for ; Thu, 14 Apr 2022 17:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=hdEOOGX3yC2hPay2NI1euxsxwESj6Uj7mwsJgENchBk=; b=eU26nOJHebA+sBG4VukkZt8t6FstoMy//YuTaB2IbQYxJRK1r0DsPcMqHVv3sYtSJ9 KJ1SRw0alqR33AvwwuQtkOrb9Z4k7uqT1XQJOFdzPKDQWStYlnY5p50SJ9g/3cAjm1k3 JuzedYjplm7tcVzV5YBNh6y90/vEOUMIs7t0IRAbt0VMTp7KOzQYHn6JXcANIdxn06CM lpOyDuQpTQgVQPQCI0Qs5XBEhZzNOQwAuagYR2MxGVV/XuEi7SLDRUygsLPNhTUFWGyl Tk05PCdow+P9fXg87uU/o3Il01LtHO0O4iUb5VP+O9EPOa3BdnTlozFxl+NFPhcJvpxd u+pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hdEOOGX3yC2hPay2NI1euxsxwESj6Uj7mwsJgENchBk=; b=dyAqIksdC5wF5IuapvK0iPg/7Gdu5lADHv9JUlt0bkWaNpWUIATJQJWWJKxBWZiXF8 KV4V7Sm3/hq0QU/QaZDttcDpye6QojUCC16VCUypMtfeKhc2pHXT7p45QdgKz8xXOLuB +oqHNUUzol4SdMSxFB225nGS6qQAqzmjSF1iLuPoar3JFpQW9zTfWhzgcVDMFZT1VqEh cJWSAuop5JwDcx+10nYn14UCJ2kOnSCJO89bOf6bWGl1hifMy4BqB1dEbqJvOrNszByO KtEI6M3yuamzpb9egeSl/8TOWviPsstXP3z8J3Sl5TMKQvsIUImtrjwKCHnxyqsa1wnc CKsg== X-Gm-Message-State: AOAM532wVGehg+kD2kPeeGf195BWIa4gQe99Wf9g38M2kRUCnsWXWD2r CenRP2RwbKMV3JfvXLheV4IkS8aAGw9ve+TssLjIWuSALcPh X-Google-Smtp-Source: ABdhPJwiHTr89Gpo97fXNhy1YsbXUB0ZvRFAdTquB3/NG1AXZJ221L+iWDhWnLwDPDSisGzCYZ/OdRjmqghcwOwkuFk= X-Received: by 2002:a05:6512:1504:b0:44b:36e:b50d with SMTP id bq4-20020a056512150400b0044b036eb50dmr3431893lfb.558.1649981807283; Thu, 14 Apr 2022 17:16:47 -0700 (PDT) MIME-Version: 1.0 From: Eric Monson Date: Thu, 14 Apr 2022 18:16:35 -0600 Message-ID: Subject: pyhoca-cli does not honor the -k (--ssh-privkey) option To: submit@bugs.x2go.org Content-Type: multipart/alternative; boundary="0000000000008251ea05dca65366" --0000000000008251ea05dca65366 Content-Type: text/plain; charset="UTF-8" Package: pyhoca-cli Version: 0.4.0.3 I've created a session and defined a private key (not at the location ~/.ssh/id_rsa). In the command line, I run "pyhocal-cli -k ...". However, pyhoca-cli still attempts to use ~/.ssh/id_rsa. Here's what I believe happens: x2go/defaults.py: autologin is defaulted to True x2go/utils.py: autologin is translated to 'look_for_keys', so look_for_keys is now set to True x2go/backends/control/plain.py (in the function connect): We hit is following if statement: if look_for_keys: key_filename = None pkey = None (so key_filename and pkey are cleared) Finally in backends/control/plain.py, we hit the if statement that calls one of 3 paramiko connect calls. However, since key_filename and pkey are set to None, but look_for_keys is set to true, the software ends up trying to use the ~/.ssh/id_rsa file, if that doesn't work, it will then ask for a password, but never uses the passed in private key. If you comment out the if statement in "plain.py": if look_for_keys: key_filename = None pkey = None then the software does in fact use the private key passed in at the command line. I don't know why that if statement is there. I'm sure there is a reason, but don't know the codebase well enough to say that would be a global fix. --0000000000008251ea05dca65366 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Package: pyhoca-cli
Version: 0.4.0.3
I've created a session and defined a=C2=A0private=C2=A0key = (not at the location ~/.ssh/id_rsa). In the command line, I run "pyhoc= al-cli=C2=A0-k <private_key> ...".=C2=A0 However, pyhoca-cli sti= ll attempts to use ~/.ssh/id_rsa.

Here's what = I believe happens:
x2go/defaults.py: autologin is defaulted to Tr= ue
x2go/utils.py: autologin is translated to 'look_for_keys&#= 39;, so look_for_keys is now set to True
x2go/backends/control/pl= ain.py (in the function connect): We hit is following if statement:
=C2=A0 if look_for_keys:
=C2=A0 =C2=A0 key_filename =3D None
=C2= =A0 =C2=A0 pkey =3D None
(so key_filename and pkey are cleare= d)

Finally in backends/control/plain.py, we hit th= e if statement that calls one of 3 paramiko connect calls. However, since k= ey_filename and pkey are set to None, but look_for_keys is set to true, the= =C2=A0software ends up trying to use the ~/.ssh/id_rsa file, if that doesn&= #39;t work, it will then ask for a password, but never uses the passed in p= rivate key.

If you comment out the if statement in= "plain.py":
=C2=A0 if look_for_keys:
=C2=A0 =C2=A0 = key_filename =3D None
=C2=A0 =C2=A0 pkey =3D None

then the software does in fact use the private key passed in at the = command line. I don't know why that if statement is there. I'm sure= there is a reason, but don't know the codebase well enough to say that= would be a global fix.
--0000000000008251ea05dca65366--