Why does sshpass still prompt for a password?

The context :

• Debian Stretch workstation trying to SSH to numerous GNU/Linux servers (mostly RH and Debian)
• I can not change the SSH configuration of the remote servers
• I know this is far from ideal, but I have to login with login + password. No SSH key, plain old login/pass. I can NOT change this (no need to suggest using keys + passphrases)
• sshpass -V : "sshpass 1.06"

This answer gives an interesting hint using 'ssphass'.

What I've set up in '~/.ssh/config' :

Host myServer
    HostName 12.34.56.78
    User bob
    ProxyCommand sshpass -v -pmyPassword ssh %r@%h -W localhost:%p

NB: the '-v' sshpass option is there only to get details while asking this question

When I try to connect via SSH :

me@myWorkstation$ ssh myServer
SSHPASS searching for password prompt using match "assword"
SSHPASS read: [email protected]'s password:
SSHPASS detected prompt. Sending password.
SSHPASS read:

[email protected]'s password:

And it waits like this forever :-(

If I edit '~/.ssh/config' and replace 'myPassword' (which is the real password attached to this SSH login, works when logging manually) :

Host myServer
    HostName 12.34.56.78
    User bob
    ProxyCommand sshpass -v -pnotMyPasswordAnymoreOhNo ssh %r@%h -W localhost:%p

which gives :

me@myWorkstation$ ssh myServer
SSHPASS searching for password prompt using match "assword"
SSHPASS read: [email protected]'s password:
SSHPASS detected prompt. Sending password.
SSHPASS read:

Permission denied, please try again.
SSHPASS read: [email protected]'s password:
SSHPASS detected prompt, again. Wrong password. Terminating.
ssh_exchange_identification: Connection closed by remote host

I actually get a reply (albeit negative). Could you explain why ?

Solution 1:

man sshpass say:

SECURITY CONSIDERATIONS

  First and foremost, users of sshpass should realize that ssh's insistance on only  getting  the  password  interac‐
   tively is not without reason. It is close to impossible to securely store the password, and users of sshpass should
   consider whether ssh's public key authentication provides the same end-user experience, while involving less hassle
   and being more secure.

  The  -p  option  should  be  considered the least secure of all of sshpass's options.  All system users can see the
   password in the command line with a simple "ps" command. Sshpass makes a minimal attempt to hide the password,  but
   such  attempts  are  doomed  to  create  race conditions without actually solving the problem. Users of sshpass are
   encouraged to use one of the other password passing techniques, which are all more secure.

  In particular, people writing programs that are meant to communicate the password programatically are encouraged to
   use an anonymous pipe and pass the pipe's reading end to sshpass using the -d option.

You can try save ENV variable and store pass there, but it's to bad practice.

Solution 2:

In case one is interested to force the ssh to ask password once, i.e. the time when sshpass provides a password and fail in case it is wrong, then something like this works nicely

sshpass -e ssh [email protected] -o NumberOfPasswordPrompts=1 whoami

Explanation:

• sshpass takes the password from the $SSHPASS environment variable when using -e option
• ssh uses the password provided by sshpass and if successful then runs whoami command on the remote server
• if the password is wrong then it does not prompt for password because of the -o NumberOfPasswordPrompts=1 which forces ssh to only prompt once and that 1 time was already used by the wrong password provided by sshpass, hence the focus returns to the terminal