Our team members running M1 Mac experience an intermittent issue where the SSH connection fails to establish due a null password being passed instead of the actual password. The issue is most easily reproduced by forking several connections concurrently. Note this does NOT reproduce on our Intel Mac's.
For background we are running Ansible for host orchestration which uses sshpass for connectivity. Our inventories often have several hosts which causes concurrent connections to be set up via sshpass. To reproduce this issue at will we removed Ansible and simply made concurrent sshpass connections using a parent shell script which would fork 6 connections concurrently.
Verbose logging shows that sshpass doesn't receive the password prompt at all on the failed attempts. Additional logging indicated that on the failed attempts the child process (ssh) was getting scheduled before the parent (sshpass), and that the select call failed with -1. It seemed that the pty wasn't being established properly or "in time".
After reading the comment stating that the slave fds must be opened for the select call to work I moved the call to open the slave to just above the fork() call. After a large number of tests we couldn't reproduce the issue with this change.
slavept=open(name, O_RDWR|O_NOCTTY ); // This line moved from below to here before the fork
childpid=fork();
if( childpid==0 ) {
...
}
However I'm not confident enough to be sure this won't cause other issues (for e.g. it is not tested heavily on Linux) hence filing a bug instead of a patch. For now our team is using the patched version internally.
Thanks.
I forgot mention we are using 1.09.