sshpass-devel — General discussions about sshpass

Re: [Sshpass-devel] Unsubscribe

[Shachar S. <sh...@sh...>]

On 14/07/2021 1:23, LI Michael via Sshpass-devel wrote:
> Unsubscribe

 From the headers of the mailing list's messages:

List-Unsubscribe: <https://lists.sourceforge.net/lists/options/sshpass-devel>,
  <mailto:ssh...@li...?subject=unsubscribe>

So either mail "ssh...@li..." with the same message, or go to
https://lists.sourceforge.net/lists/options/sshpass-devel

Shachar

[Sshpass-devel] Unsubscribe

[LI M. <Mic...@sw...>]

Unsubscribe 

Thanks and regards.
Michael Li

SWIFT | Security Footprint
Tel: +1 703 365 6136
www.swift.com

This e-mail and any attachments thereto may contain information which is
confidential and/or proprietary and intended for the sole use of the
recipient(s) named above. If you have received this e-mail in error, please
immediately notify the sender and delete the mail.  Thank you for your
co-operation.  SWIFT reserves the right to retain e-mail messages on its
systems and, under circumstances permitted by applicable law, to monitor and
intercept e-mail messages to and from its systems.

-----Original Message-----
From: Shachar Shemesh <sh...@sh...> 
Sent: Tuesday, July 13, 2021 1:40 AM
To: Halturin Denis <dha...@ho...>;
ssh...@li...
Subject: Re: [Sshpass-devel] Added support for entering TOTP; changing
attempts entering password

Mail originates from outside SWIFT !
Be vigilant before you click on a link,
open attachments or reply !
_______________________________________

On 13/07/2021 3:26, Halturin Denis wrote:
> Hello, Shachar
>
> There is no task here to support some N-plugins for two-factor 
> authorization via ssh.
> The patch allows sshpass to work so that the utility can correctly 
> process not only the password, but also two-factor authorization. At 
> the moment, the -P key does not solve this problem, since it will only 
> change the Prompt to which you need to respond.
>
> The implementation in the patch allows you to respond to both Prompt 
> for password and Prompt for two-factor authorization simultaneously / 
> sequentially (it does not matter Duo or MFA/TOTP from Google plugin).
>
> It does not matter how soon the release gets into Debian/Ubuntu and 
> other distributions, it is important that you understand that the 
> added keys expand the functionality of sshpass and you can enter a 
> two-factor authorization code regardless of the type of plugin 
> (duo/totp/etc).
>
> I really ask you, please review the patch again, delve into the 
> essence of the issue being solved.
>
> Denis
>
The core issue you're trying to solve is what happens when a single
connection requires two password prompts to answer. That can happen for a
variety of reasons.

But if two prompts are possible, so are three and four. For example, one
reason to have two prompts is if you need to use the ssh Proxy option (the
-P option to ssh) to tunnel through one host to reach a second. But if two
hops proxy is possible, so are 15.

So, rather than accept a patch that allows SSH to handle *two* prompts, I'd
rather have an option in place handling any number of prompts.

Something along the lines of a single option *that I can give multiple
times* that says "answer this prompt with this password".

I hope what I had in mind was clearer.

Shachar



_______________________________________________
Sshpass-devel mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshpass-devel

Re: [Sshpass-devel] Added support for entering TOTP; changing attempts entering password

[Halturin D. <dha...@ho...>]

These are two different cases.

The first is a connection to the host via ProxyCommand, the second is a connection to the server where two-factor authorization is enabled.
Both cases are offered in the patch.
The -a key allows you to connect to hosts with ProxyCommand, the current implementation of sshpass does not allow this.

Denis

________________________________
От: Shachar Shemesh <sh...@sh...>
Отправлено: 13 июля 2021 г. 13:40
Кому: Halturin Denis <dha...@ho...>; ssh...@li... <ssh...@li...>
Тема: Re: [Sshpass-devel] Added support for entering TOTP; changing attempts entering password


On 13/07/2021 3:26, Halturin Denis wrote:
> Hello, Shachar
>
> There is no task here to support some N-plugins for two-factor
> authorization via ssh.
> The patch allows sshpass to work so that the utility can correctly
> process not only the password,
> but also two-factor authorization. At the moment, the -P key does not
> solve this problem,
> since it will only change the Prompt to which you need to respond.
>
> The implementation in the patch allows you to respond to both Prompt
> for password and Prompt for
> two-factor authorization simultaneously / sequentially (it does not
> matter Duo or MFA/TOTP from Google plugin).
>
> It does not matter how soon the release gets into Debian/Ubuntu and
> other distributions,
> it is important that you understand that the added keys expand the
> functionality of sshpass
> and you can enter a two-factor authorization code regardless of the
> type of plugin (duo/totp/etc).
>
> I really ask you, please review the patch again, delve into the
> essence of the issue being solved.
>
> Denis
>
The core issue you're trying to solve is what happens when a single
connection requires two password prompts to answer. That can happen for
a variety of reasons.

But if two prompts are possible, so are three and four. For example, one
reason to have two prompts is if you need to use the ssh Proxy option
(the -P option to ssh) to tunnel through one host to reach a second. But
if two hops proxy is possible, so are 15.

So, rather than accept a patch that allows SSH to handle *two* prompts,
I'd rather have an option in place handling any number of prompts.

Something along the lines of a single option *that I can give multiple
times* that says "answer this prompt with this password".

I hope what I had in mind was clearer.

Shachar

Re: [Sshpass-devel] Added support for entering TOTP; changing attempts entering password

[Shachar S. <sh...@sh...>]

On 13/07/2021 3:26, Halturin Denis wrote:
> Hello, Shachar
>
> There is no task here to support some N-plugins for two-factor 
> authorization via ssh.
> The patch allows sshpass to work so that the utility can correctly 
> process not only the password,
> but also two-factor authorization. At the moment, the -P key does not 
> solve this problem,
> since it will only change the Prompt to which you need to respond.
>
> The implementation in the patch allows you to respond to both Prompt 
> for password and Prompt for
> two-factor authorization simultaneously / sequentially (it does not 
> matter Duo or MFA/TOTP from Google plugin).
>
> It does not matter how soon the release gets into Debian/Ubuntu and 
> other distributions,
> it is important that you understand that the added keys expand the 
> functionality of sshpass
> and you can enter a two-factor authorization code regardless of the 
> type of plugin (duo/totp/etc).
>
> I really ask you, please review the patch again, delve into the 
> essence of the issue being solved.
>
> Denis
>
The core issue you're trying to solve is what happens when a single 
connection requires two password prompts to answer. That can happen for 
a variety of reasons.

But if two prompts are possible, so are three and four. For example, one 
reason to have two prompts is if you need to use the ssh Proxy option 
(the -P option to ssh) to tunnel through one host to reach a second. But 
if two hops proxy is possible, so are 15.

So, rather than accept a patch that allows SSH to handle *two* prompts, 
I'd rather have an option in place handling any number of prompts.

Something along the lines of a single option *that I can give multiple 
times* that says "answer this prompt with this password".

I hope what I had in mind was clearer.

Shachar

Re: [Sshpass-devel] Added support for entering TOTP; changing attempts entering password

[Halturin D. <dha...@ho...>]

Hello, Shachar

There is no task here to support some N-plugins for two-factor authorization via ssh.
The patch allows sshpass to work so that the utility can correctly process not only the password,
but also two-factor authorization. At the moment, the -P key does not solve this problem,
since it will only change the Prompt to which you need to respond.

The implementation in the patch allows you to respond to both Prompt for password and Prompt for
two-factor authorization simultaneously / sequentially (it does not matter Duo or MFA/TOTP from Google plugin).

It does not matter how soon the release gets into Debian/Ubuntu and other distributions,
it is important that you understand that the added keys expand the functionality of sshpass
and you can enter a two-factor authorization code regardless of the type of plugin (duo/totp/etc).

I really ask you, please review the patch again, delve into the essence of the issue being solved.

Denis

________________________________
От: Shachar Shemesh <sh...@sh...>
Отправлено: 12 июля 2021 г. 22:40
Кому: ssh...@li... <ssh...@li...>
Тема: Re: [Sshpass-devel] Added support for entering TOTP; changing attempts entering password



On 09/07/2021 12:39, Halturin Denis wrote:
Hello Shachar,
Tell me, can I help with the review of my patch?


Hello Denis,

First, thank you for your patience. I'm overwhelmed by... life, and these things take time, unfortunately.

My review for your patch is the same as it is for https://sourceforge.net/p/sshpass/patches/13/, trying to add Duo support. If you look at those patches you will notice they are very very very similar, and for pretty much the same reason.

I can summarize both as "ssh added another type of prompt, and we want sshpass to support it".

That's not the way to go. To understand why, just think what would happen if I accepted your patch today. It will be about a month until Debian Sid would carry it, and quite a few more months until Ubuntu would. I have no idea how long it would take for other distros to pick it up. All of that is assuming I am immediately responsive. As you have experienced, that is hardly the case.

I'm not against sshpass supporting totp, or duo, or any other ssh plugin. I'm against it supporting those plugins individually.

Sshpass already have a "-P" option for telling it what prompt to look out for. I understand why that is not always a good enough solution, but if that's the case for you, I would like a patch that provides a solution that is good enough while also being generic. Not adding support to TOTP, but "adding support for two password prompts in a row" (or whatever the reason that -P doesn't satisfy your need).

Let's go through the release cycle once and solve this for as many ssh plugins as we can.

Shachar

Re: [Sshpass-devel] Option for reading from arbitrary environment variable

[Chris B. <chr...@gm...>]

Understood! I guess my other thought had been that if I were to attempt
something like sshpass from scratch, I would personally consider flexible
environment variable names to be more generic and useful than using a fixed
name (just like using flexible file names is more generic and useful than
using a fixed file location); although I'm sure there are arguments to the
contrary. It's not like the current design has been limiting the tool's
usefulness or popularity, of course!

Thanks for getting round to reviewing this.

On Mon, 12 Jul 2021 at 18:40, Shachar Shemesh <sh...@sh...> wrote:

> On 12/07/2021 17:51, Chris Barnes wrote:
> > My initial use case was rsync proxyjumping through another server,
> > both of which need passwords (in my case, the gateway disallows key
> > logins and doesn't pass keys over to the next server). It was
> > convenient to load the password(s) from a .env file rather than typing
> > them myself and having them in the shell history.
> >
> I think the use case you describe falls under the same hospice as the
> answer I gave Denise. If I accept your patch (or the feature under any
> other name), then you'd end up running two nested instances of sshpass.
> I think it makes more sense for sshpass to be able to generically handle
> more than one password prompt. That would solve the problem without
> introducing specialized features into sshpass.
>
> Shachar
>
>
>

Re: [Sshpass-devel] Option for reading from arbitrary environment variable

[Shachar S. <sh...@sh...>]

On 12/07/2021 17:51, Chris Barnes wrote:
> My initial use case was rsync proxyjumping through another server, 
> both of which need passwords (in my case, the gateway disallows key 
> logins and doesn't pass keys over to the next server). It was 
> convenient to load the password(s) from a .env file rather than typing 
> them myself and having them in the shell history.
>
I think the use case you describe falls under the same hospice as the 
answer I gave Denise. If I accept your patch (or the feature under any 
other name), then you'd end up running two nested instances of sshpass. 
I think it makes more sense for sshpass to be able to generically handle 
more than one password prompt. That would solve the problem without 
introducing specialized features into sshpass.

Shachar

Re: [Sshpass-devel] Option for reading from arbitrary environment variable

[Chris B. <chr...@gm...>]

My initial use case was rsync proxyjumping through another server, both of
which need passwords (in my case, the gateway disallows key logins and
doesn't pass keys over to the next server). It was convenient to load the
password(s) from a .env file rather than typing them myself and having them
in the shell history.

On Mon, 12 Jul 2021, 15:44 Shachar Shemesh, <sh...@sh...> wrote:

>
> On 08/06/2021 12:56, Chris Barnes wrote:
>
> Hi,
>
> There have been some situations where I've needed to invoke sshpass a
> couple of times in a particular environment. The -f option reasonably
> allows you to read from an arbitrary file, rather than saying "this will
> always read from the file ~/.sshpass": I felt the same advantage could be
> derived from an option to allow you to read from an arbitary environment
> variable rather than one with a fixed name.
>
> There is a patch on sourceforge implementing this as a -E option:
> https://sourceforge.net/p/sshpass/patches/14/
>
> I am not really familiar with sourceforge, svn, C, or roff, so I'm happy
> to receive feedback.
>
> Thanks
> Chris
>
> Hello Chris,
>
> Can you explain why setting an environment variable per-invocation doesn't
> solve your use case? Under bourne shell and derivatives, you can just do:
>
> SSHPASS=foo sshpass ssh user1@somewhere ls -la
>
> SSHPASS=bar sshpass ssh user2@somewhere rm -rf /
>
>
> Does that not solve your use case?
>
> Thank you,
>
> Shachar
>

Re: [Sshpass-devel] Option for reading from arbitrary environment variable

[Shachar S. <sh...@sh...>]

<html style="direction: ltr;">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <style id="bidiui-paragraph-margins" type="text/css">body p { margin-bottom: 0.3cm; margin-top: 0pt; } </style>
  </head>
  <body bidimailui-charset-is-forced="true" style="direction: ltr;">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 08/06/2021 12:56, Chris Barnes
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAN=dRi...@ma...">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>Hi,</div>
        <div><br>
        </div>
        <div>There have been some situations where I've needed to invoke
          sshpass a couple of times in a particular environment. The -f
          option reasonably allows you to read from an arbitrary file,
          rather than saying "this will always read from the file
          ~/.sshpass": I felt the same advantage could be derived from
          an option to allow you to read from an arbitary environment
          variable rather than one with a fixed name.</div>
        <div><br>
        </div>
        <div>There is a patch on sourceforge implementing this as a -E
          option: <a
            href="https://sourceforge.net/p/sshpass/patches/14/"
            moz-do-not-send="true">https://sourceforge.net/p/sshpass/patches/14/</a>
          <br>
        </div>
        <div><br>
        </div>
        <div>I am not really familiar with sourceforge, svn, C, or roff,
          so I'm happy to receive feedback.</div>
        <div><br>
        </div>
        <div>Thanks</div>
        <div>Chris<br>
        </div>
      </div>
      <br>
    </blockquote>
    <p>Hello Chris,</p>
    <p>Can you explain why setting an environment variable
      per-invocation doesn't solve your use case? Under bourne shell and
      derivatives, you can just do:</p>
    <p>SSHPASS=foo sshpass ssh user1@somewhere ls -la</p>
    <p>SSHPASS=bar sshpass ssh user2@somewhere rm -rf /</p>
    <p><br>
    </p>
    <p>Does that not solve your use case?</p>
    <p>Thank you,</p>
    <p>Shachar<br>
    </p>
  </body>
</html>

Re: [Sshpass-devel] Added support for entering TOTP; changing attempts entering password

[Shachar S. <sh...@sh...>]

<html style="direction: ltr;">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <style id="bidiui-paragraph-margins" type="text/css">body p { margin-bottom: 0.3cm; margin-top: 0pt; } </style>
  </head>
  <body bidimailui-charset-is-forced="true" style="direction: ltr;">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 09/07/2021 12:39, Halturin Denis
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:DBA...@DB...">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
      Hello Shachar, <br>
      <span>Tell me, can I help with the review of my patch?</span>
      <div>
        <div style="font-family:Calibri,Helvetica,sans-serif;
          font-size:12pt; color:rgb(0,0,0)">
          <br>
        </div>
      </div>
    </blockquote>
    <p>Hello Denis,</p>
    <p>First, thank you for your patience. I'm overwhelmed by... life,
      and these things take time, unfortunately.</p>
    <p>My review for your patch is the same as it is for
      <a class="moz-txt-link-freetext" href="https://sourceforge.net/p/sshpass/patches/13/">https://sourceforge.net/p/sshpass/patches/13/</a>, trying to add Duo
      support. If you look at those patches you will notice they are
      very very <i>very</i> similar, and for pretty much the same
      reason.</p>
    <p>I can summarize both as "ssh added another type of prompt, and we
      want sshpass to support it".</p>
    <p>That's not the way to go. To understand why, just think what
      would happen if I accepted your patch today. It will be about a
      month until Debian Sid would carry it, and quite a few more months
      until Ubuntu would. I have no idea how long it would take for
      other distros to pick it up. All of that is assuming I am
      immediately responsive. As you have experienced, that is hardly
      the case.</p>
    <p>I'm not against sshpass supporting totp, or duo, or any other ssh
      plugin. I'm against it supporting those plugins individually.</p>
    <p>Sshpass already have a "-P" option for telling it what prompt to
      look out for. I understand why that is not always a good enough
      solution, but if that's the case for you, I would like a patch
      that provides a solution that is good enough <i>while also being
        generic</i>. Not adding support to TOTP, but "adding support for
      two password prompts in a row" (or whatever the reason that -P
      doesn't satisfy your need).</p>
    <p>Let's go through the release cycle once and solve this for as
      many ssh plugins as we can.</p>
    Shachar<br>
  </body>
</html>

Re: [Sshpass-devel] Added support for entering TOTP; changing attempts entering password

[Halturin D. <dha...@ho...>]

Hello Shachar,
Tell me, can I help with the review of my patch?

________________________________
От: Shachar Shemesh <sh...@sh...>
Отправлено: 30 июня 2021 г. 11:06
Кому: ssh...@li... <ssh...@li...>
Тема: Re: [Sshpass-devel] Added support for entering TOTP; changing attempts entering password


Hello Denis,

Thank you for your submission. I'm in a bit of a high pressure time right now, but I'll try to have a look around next week. Please feel free to ping me if you don't hear back from me.

Thank you again,

Shachar

On 30/06/2021 1:52, Halturin Denis wrote:
Hello.

When connecting to the server, it is sometimes necessary to enter a password and TOTP (-t, -T)

It may also be necessary to change the number of password entry attempts, since some servers may be located behind the DMZ (for example, connecting via bastion: ssh-J %bastion_ip% %second_server_ip%).
In this case, the password will be requested 2 times.
The proposed changes will not allow sshpass to fail if you change the number of attempts from one to two (-a 2).

Finally, a prompt has been added to enter the become password for ansible (-A)

Link to the patch:
https://sourceforge.net/p/sshpass/patches/15/

Denis




_______________________________________________
Sshpass-devel mailing list
Ssh...@li...<mailto:Ssh...@li...>
https://lists.sourceforge.net/lists/listinfo/sshpass-devel

Re: [Sshpass-devel] Added support for entering TOTP; changing attempts entering password

[Halturin D. <dha...@ho...>]

Hello, Shachar! Is there any news?

Thanks,
Denis

________________________________
От: Shachar Shemesh <sh...@sh...>
Отправлено: 30 июня 2021 г. 11:06
Кому: ssh...@li... <ssh...@li...>
Тема: Re: [Sshpass-devel] Added support for entering TOTP; changing attempts entering password


Hello Denis,

Thank you for your submission. I'm in a bit of a high pressure time right now, but I'll try to have a look around next week. Please feel free to ping me if you don't hear back from me.

Thank you again,

Shachar

On 30/06/2021 1:52, Halturin Denis wrote:
Hello.

When connecting to the server, it is sometimes necessary to enter a password and TOTP (-t, -T)

It may also be necessary to change the number of password entry attempts, since some servers may be located behind the DMZ (for example, connecting via bastion: ssh-J %bastion_ip% %second_server_ip%).
In this case, the password will be requested 2 times.
The proposed changes will not allow sshpass to fail if you change the number of attempts from one to two (-a 2).

Finally, a prompt has been added to enter the become password for ansible (-A)

Link to the patch:
https://sourceforge.net/p/sshpass/patches/15/

Denis




_______________________________________________
Sshpass-devel mailing list
Ssh...@li...<mailto:Ssh...@li...>
https://lists.sourceforge.net/lists/listinfo/sshpass-devel

Re: [Sshpass-devel] Added support for entering TOTP; changing attempts entering password

[Shachar S. <sh...@sh...>]

<html style="direction: ltr;">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=KOI8-R">
    <style id="bidiui-paragraph-margins" type="text/css">body p { margin-bottom: 0.3cm; margin-top: 0pt; } </style>
  </head>
  <body bidimailui-charset-is-forced="true" style="direction: ltr;">
    <p>Hello Denis,</p>
    <p>Thank you for your submission. I'm in a bit of a high pressure
      time right now, but I'll try to have a look around next week.
      Please feel free to ping me if you don't hear back from me.</p>
    <p>Thank you again,</p>
    <p>Shachar<br>
    </p>
    <div class="moz-cite-prefix">On 30/06/2021 1:52, Halturin Denis
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:AM8...@AM...">
      <meta http-equiv="Content-Type" content="text/html;
        charset=KOI8-R">
      <div style="font-family: &quot;segoe ui westeuropean&quot;,
        &quot;segoe ui&quot;, helvetica, arial, sans-serif; font-size:
        12pt; color: rgb(0, 0, 0);">
        Hello. </div>
      <div style="font-family: &quot;segoe ui westeuropean&quot;,
        &quot;segoe ui&quot;, helvetica, arial, sans-serif; font-size:
        12pt; color: rgb(0, 0, 0);">
        <div><br>
        </div>
        When connecting to the server, it is sometimes necessary to
        enter a password and TOTP (-t, -T)</div>
      <div style="font-family: &quot;segoe ui westeuropean&quot;,
        &quot;segoe ui&quot;, helvetica, arial, sans-serif; font-size:
        12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div style="font-family: &quot;segoe ui westeuropean&quot;,
        &quot;segoe ui&quot;, helvetica, arial, sans-serif; font-size:
        12pt; color: rgb(0, 0, 0);">
        It may also be necessary to change the number of password entry
        attempts, since some servers may be located behind the DMZ (for
        example, connecting via bastion: ssh-J %bastion_ip%
        %second_server_ip%).</div>
      <div style="font-family: &quot;segoe ui westeuropean&quot;,
        &quot;segoe ui&quot;, helvetica, arial, sans-serif; font-size:
        12pt; color: rgb(0, 0, 0);">
        In this case, the password will be requested 2 times.</div>
      <div style="font-family: &quot;segoe ui westeuropean&quot;,
        &quot;segoe ui&quot;, helvetica, arial, sans-serif; font-size:
        12pt; color: rgb(0, 0, 0);">
        The proposed changes will not allow sshpass to fail if you
        change the number of attempts from one to two (-a 2).</div>
      <div style="font-family: &quot;segoe ui westeuropean&quot;,
        &quot;segoe ui&quot;, helvetica, arial, sans-serif; font-size:
        12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div style="font-family: &quot;segoe ui westeuropean&quot;,
        &quot;segoe ui&quot;, helvetica, arial, sans-serif; font-size:
        12pt; color: rgb(0, 0, 0);">
        Finally, a prompt has been added to enter the become password
        for ansible (-A)<br>
      </div>
      <div style="font-family: &quot;segoe ui westeuropean&quot;,
        &quot;segoe ui&quot;, helvetica, arial, sans-serif; font-size:
        12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div style="font-family: &quot;segoe ui westeuropean&quot;,
        &quot;segoe ui&quot;, helvetica, arial, sans-serif; font-size:
        12pt; color: rgb(0, 0, 0);">
        Link to the patch:<br>
      </div>
      <div style="font-family: &quot;segoe ui westeuropean&quot;,
        &quot;segoe ui&quot;, helvetica, arial, sans-serif; font-size:
        12pt; color: rgb(0, 0, 0);">
        <a class="moz-txt-link-freetext" href="https://sourceforge.net/p/sshpass/patches/15/">https://sourceforge.net/p/sshpass/patches/15/</a><br>
      </div>
      <div style="font-family: &quot;segoe ui westeuropean&quot;,
        &quot;segoe ui&quot;, helvetica, arial, sans-serif; font-size:
        12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div style="font-family: &quot;segoe ui westeuropean&quot;,
        &quot;segoe ui&quot;, helvetica, arial, sans-serif; font-size:
        12pt; color: rgb(0, 0, 0);">
        Denis</div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Sshpass-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ssh...@li...">Ssh...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/sshpass-devel">https://lists.sourceforge.net/lists/listinfo/sshpass-devel</a>
</pre>
    </blockquote>
  </body>
</html>

[Sshpass-devel] Added support for entering TOTP; changing attempts entering password

[Halturin D. <dha...@ho...>]

Hello.

When connecting to the server, it is sometimes necessary to enter a password and TOTP (-t, -T)

It may also be necessary to change the number of password entry attempts, since some servers may be located behind the DMZ (for example, connecting via bastion: ssh-J %bastion_ip% %second_server_ip%).
In this case, the password will be requested 2 times.
The proposed changes will not allow sshpass to fail if you change the number of attempts from one to two (-a 2).

Finally, a prompt has been added to enter the become password for ansible (-A)

Link to the patch:
https://sourceforge.net/p/sshpass/patches/15/

Denis

[Sshpass-devel] Option for reading from arbitrary environment variable

[Chris B. <chr...@gm...>]

Hi,

There have been some situations where I've needed to invoke sshpass a
couple of times in a particular environment. The -f option reasonably
allows you to read from an arbitrary file, rather than saying "this will
always read from the file ~/.sshpass": I felt the same advantage could be
derived from an option to allow you to read from an arbitary environment
variable rather than one with a fixed name.

There is a patch on sourceforge implementing this as a -E option:
https://sourceforge.net/p/sshpass/patches/14/

I am not really familiar with sourceforge, svn, C, or roff, so I'm happy to
receive feedback.

Thanks
Chris

[Sshpass-devel] Version 1.0.7 released

[Shachar S. <sh...@sh...>]

<html style="direction: ltr;">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <style id="bidiui-paragraph-margins" type="text/css">body p { margin-bottom: 0.3cm; margin-top: 0pt; } </style>
  </head>
  <body bidimailui-charset-is-forced="true" style="direction: ltr;">
    <p>Hello everyone,</p>
    <p>After too-many-years, version 1.0.7 is now available for
      download. Nothing major has changed, but a few bugs have been
      resolved.</p>
    <p>Share and enjoy.</p>
    <p>Shachar<br>
    </p>
  </body>
</html>

[Sshpass-devel] sshpass hang in pselect

[jason <huz...@gm...>]

Hello,
I encountered several times that sshpass hang forever in pselect() while
child is defunct.

It seems child failed to send SIGCHLD or sshpass lost it. Then I looked at
the code and this line
https://sourceforge.net/p/sshpass/code/HEAD/tree/trunk/main.c#l219 may have
problem. If the child run so fast, it can terminate and kernel send SIGCHLD
before sshpass run into pselect() which will hang forever.

According to https://lwn.net/Articles/176911/ may be we need to do SIG_BLOCK
the SIGCHLD before forking the child and unblock it by pselect().  So
sshpass will not lost signal. Is it really a bug here or I am not clear
with it? Please help to take look.

Many thanks.

Re: [Sshpass-devel] sshpass sometimes fails with errcode=5

[Alexey K. <al...@ko...>]

Please see attached patch. We have tested it on the box where we were 
able to reproduce the issue. Without this fix it failed once in five, 
with the patch it works without fails.

Thank you,
Alexey Komarov

[Sshpass-devel] sshpass sometimes fails with errcode=5

[Alexey K. <al...@ko...>]

Dear maintainers,

We found sometimes sshpass fails to connect with error code 5.
Looking in to the code I see two things:

int handleoutput( int fd )
{
     // We are looking for the string
     static int prevmatch=0; // If the "password" prompt is repeated, we 
have the wrong password.
     static int state1, state2;
...


Later state1, state2 are used to match the output with password prompt 
but since they are not initialized, the 'match' function works 
unpredictable and returns true when it should return false.
We saw this problem with new new OpenSSH_7.6p1 at the server side when 
we using gssapikeyexchange=no, in this case ssh client also prints:
"command-line line 0: Unsupported option "gssapikeyexchange" and retcode 
= 5" and sometimes sshpass fails with 5.

Later in the code we can see why it returns 5:

     if( !prevmatch ) {
             if( args.verbose )
                 fprintf(stderr, "SSHPASS detected prompt. Sending 
password.\n");
         write_pass( fd );
         state1=0;
         prevmatch=1;
     } else {
         // Wrong password - terminate with proper error code
             if( args.verbose )
                 fprintf(stderr, "SSHPASS detected prompt, again. Wrong 
password. Terminating.\n");
         ret=RETURN_INCORRECT_PASSWORD;
     }

So, my suggestion is match function doesn't work always correctly 
because of initialized state1, state2.

There is also one more place which looks suspiciously to me:

int match( const char *reference, const char *buffer, ssize_t bufsize, 
int state )
{
     // This is a highly simplisic implementation. It's good enough for 
matching "Password: ", though.
     int i;
     for( i=0;reference[state]!='\0' && i<bufsize; ++i ) {
     if( reference[state]==buffer[i] )
         state++;
     else {
         state=0;
         if( reference[state]==buffer[i] )
         state++;
     }
     }

     return state;
}

I'm not sure about reference[state]!='\0', is there additional byte for 
'\0' in the compare1 which is passed from handleoutput to match as the 
reference?

Kind regards,
Alexey Komarov

Re: [Sshpass-devel] SIGCHLD blocking?

[Martin G. <omg...@gm...>]

Thanks a lot for the answers.

2018-07-06 0:36 GMT-03:00 Shachar Shemesh <sh...@sh...>:

> On 05/07/2018 20:53, Martin Galvan wrote:
>
> Hi Shachar, thanks for the answer.
>
> 2018-07-05 14:39 GMT-03:00 Shachar Shemesh <sh...@sh...>:
>
> In sshpass's particular case, however, you are right - there is a race in
> the use case you mention. The reason there is a case is not because the
> child might send a SIGCHLD before we block it. It is because we call
> "waitpid" after we call pselect (thus, if the signal arrives before we
> block it, we won't get around to releasing the process until the select
> returns for whatever other reason).
>
> Why would pselect return, other than if there happens to be some
> output on the term? I don't fully understand the PTY magic here, so
> bear with me.
>
>
> I suggest you read about how pselect works. It will return if there is
> output on the TTY or if a signal arrives while it's sleeping. It will also
> return if the process exited and closed the TTY (the TTY would then be
> available for read, with the read returning 0 bytes to indicate the other
> side has closed).
>
> This is also the reason that the race you found in the previous mail is
> not a serious issue. If the child exited before we even managed to block
> SIGCHLD, in most cases pselect will not sleep because the TTY would close.
>
>
>
> While we're at that, there's a comment saying that handleoutput will
> return a negative value if the slave end of the PTY is closed.
> However, looking at handleoutput I couldn't find a case where the
> return value would be negative. Am I missing something?
>
>
>
> No. It's a bug. Worse, if read returns -1 we write to buffer at location -1. It should definitely be fixed.
>
>
>
> And since it can't hurt to ask: I noticed there's a check for
> 'terminate' at the beginning of the do-while loop. If terminate is not
> zero, we'll do wait_id=waitpid( childpid, &status, 0 );. Is this just
> a way to make sure we wait on the child process in case SSH (or
> whatever program we end up running) errored out?
>
> If we're asked to terminate (i.e. - we receive a SIGTERM) we pass it on to ssh. We then wait for it to exit.
>
> Since the code currently passes the signal on to ssh, maybe it makes more sense to just continue what we're doing while we wait.
>
>
>
>  Also, what if pselect
> returns -1 for some reason other than us getting a signal (e.g.
> ENOMEM)? Wouldn't we be stuck in an infinite loop since the WNOHANG
> waitpid would always set wait_id to zero?
>
> Only if the pselect error repeats. These errors are, typically
> (sometimes?), transient.
>
> This is a corner case where there is no good handling to be had. If a
> system call fails due to reasons that are outside of our program's
> influence, it's never clear what to do.
>
> So, all in all, good questions :-)
>
> Shachar
>
>

Re: [Sshpass-devel] SIGCHLD blocking?

[Shachar S. <sh...@sh...>]

 

On 05/07/2018 20:53, Martin Galvan wrote: 

> Hi Shachar, thanks for the answer.
> 
> 2018-07-05 14:39 GMT-03:00 Shachar Shemesh <sh...@sh...>:
> 
>> In sshpass's particular case, however, you are right - there is a race in the use case you mention. The reason there is a case is not because the child might send a SIGCHLD before we block it. It is because we call "waitpid" after we call pselect (thus, if the signal arrives before we block it, we won't get around to releasing the process until the select returns for whatever other reason).
> 
> Why would pselect return, other than if there happens to be some
> output on the term? I don't fully understand the PTY magic here, so
> bear with me.

I suggest you read about how pselect works. It will return if there is
output on the TTY or if a signal arrives while it's sleeping. It will
also return if the process exited and closed the TTY (the TTY would then
be available for read, with the read returning 0 bytes to indicate the
other side has closed). 

This is also the reason that the race you found in the previous mail is
not a serious issue. If the child exited before we even managed to block
SIGCHLD, in most cases pselect will not sleep because the TTY would
close. 

> While we're at that, there's a comment saying that handleoutput will
> return a negative value if the slave end of the PTY is closed.
> However, looking at handleoutput I couldn't find a case where the
> return value would be negative. Am I missing something?

No. It's a bug. Worse, if read returns -1 we write to buffer at location
-1. It should definitely be fixed.

> And since it can't hurt to ask: I noticed there's a check for
> 'terminate' at the beginning of the do-while loop. If terminate is not
> zero, we'll do wait_id=waitpid( childpid, &status, 0 );. Is this just
> a way to make sure we wait on the child process in case SSH (or
> whatever program we end up running) errored out?

If we're asked to terminate (i.e. - we receive a SIGTERM) we pass it on
to ssh. We then wait for it to exit.

Since the code currently passes the signal on to ssh, maybe it makes
more sense to just continue what we're doing while we wait.

> Also, what if pselect
> returns -1 for some reason other than us getting a signal (e.g.
> ENOMEM)? Wouldn't we be stuck in an infinite loop since the WNOHANG
> waitpid would always set wait_id to zero?

Only if the pselect error repeats. These errors are, typically
(sometimes?), transient. 

This is a corner case where there is no good handling to be had. If a
system call fails due to reasons that are outside of our program's
influence, it's never clear what to do. 

So, all in all, good questions :-) 

Shachar 
 

Re: [Sshpass-devel] SIGCHLD blocking?

[Shachar S. <sh...@sh...>]

<html style="direction: ltr;">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body bidimailui-charset-is-forced="true" style="direction: ltr;"
    text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 05/07/18 05:29, Martin Galvan wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAN...@ma...">
      <pre wrap="">Hi all,

I'm looking at the sshpass code, and noticed the following: in
runprogram, SIGCHLD is blocked for the parent process after the fork
is done. Shouldn't the blocking be done before the fork, restoring the
old sigmask for the child if needed? What would happen if the child
finishes for some reason before the parent blocks the signal? If the
answer is that pselect would still return successfully, then what's
the point of blocking the signal in the first place?

</pre>
    </blockquote>
    Generally speaking, that's not a very good argument. The race is not
    between the parent and the child, it is between the signal and
    checking the handler's results. As such, there is no problem <b>in
      general</b> with the code structure as it is.<br>
    <br>
    In sshpass's particular case, however, you are right - there is a
    race in the use case you mention. The reason there is a case is not
    because the child might send a SIGCHLD before we block it. It is
    because we call "waitpid" <i>after</i> we call pselect (thus, if
    the signal arrives before we block it, we won't get around to
    releasing the process until the select returns for whatever other
    reason). This is also the reason that there is no corresponding race
    for the other signals - their side effect (setting term) is checked
    before we dive into the select.<br>
    <br>
    This was a very elaborate and round-about way to say "good catch.
    Thank you".<br>
    <br>
    I'll fix it, though probably not by blocking SIGCHLD before the
    fork. That would only require unblocking it in the child process,
    adding a redundant  system call and making the code less clear.<br>
    <br>
    Thank you again,<br>
    Shachar<br>
  </body>
</html>

Re: [Sshpass-devel] SIGCHLD blocking?

[Martin G. <omg...@gm...>]

Hi Shachar, thanks for the answer.

2018-07-05 14:39 GMT-03:00 Shachar Shemesh <sh...@sh...>:
> In sshpass's particular case, however, you are right - there is a race in
> the use case you mention. The reason there is a case is not because the
> child might send a SIGCHLD before we block it. It is because we call
> "waitpid" after we call pselect (thus, if the signal arrives before we block
> it, we won't get around to releasing the process until the select returns
> for whatever other reason).

Why would pselect return, other than if there happens to be some
output on the term? I don't fully understand the PTY magic here, so
bear with me.

While we're at that, there's a comment saying that handleoutput will
return a negative value if the slave end of the PTY is closed.
However, looking at handleoutput I couldn't find a case where the
return value would be negative. Am I missing something?

And since it can't hurt to ask: I noticed there's a check for
'terminate' at the beginning of the do-while loop. If terminate is not
zero, we'll do wait_id=waitpid( childpid, &status, 0 );. Is this just
a way to make sure we wait on the child process in case SSH (or
whatever program we end up running) errored out? Also, what if pselect
returns -1 for some reason other than us getting a signal (e.g.
ENOMEM)? Wouldn't we be stuck in an infinite loop since the WNOHANG
waitpid would always set wait_id to zero?

[Sshpass-devel] SIGCHLD blocking?

[Martin G. <omg...@gm...>]

Hi all,

I'm looking at the sshpass code, and noticed the following: in
runprogram, SIGCHLD is blocked for the parent process after the fork
is done. Shouldn't the blocking be done before the fork, restoring the
old sigmask for the child if needed? What would happen if the child
finishes for some reason before the parent blocks the signal? If the
answer is that pselect would still return successfully, then what's
the point of blocking the signal in the first place?

Re: [Sshpass-devel] FW: sshpass at HPUX 11.31

[Shachar S. <sh...@sh...>]

 

On 13/11/2017 18:31, LI Michael via Sshpass-devel wrote: 

> Hi Shemesh, 
> 
> I've tested the new patch, it still does not work, got the same error message :

 Can you run with truss again? Make sure it traces both sshpass and the
actual ssh process (i.e. - it follows child processes)

Something diverts off script here, and I need to understand what. 

Shachar