sshpass-devel Mailing List for Non-interactive ssh password auth (Page 2)
Brought to you by:
thesun
Menu
▾
▴
sshpass-devel — General discussions about sshpass
You can subscribe to this list here.
| 2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
(6) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(12) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: LI M. <Mic...@sw...> - 2017-11-13 16:31:47
|
Hi Shemesh,
I’ve tested the new patch, it still does not work, got the same error message :
$ /tmp/sshpass/sshpass-1.06/sshpass -p Abcd1234 ssh -vvv nledfd02 date
OpenSSH_6.2p1+sftpfilecontrol-v1.3-hpn13v12, OpenSSL 0.9.8y 5 Feb 2013
HP-UX Secure Shell-A.06.20.006, HP-UX Secure Shell version
debug3: RNG is ready, skipping seeding
……
debug2: input_userauth_info_req: num_prompts 1
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug3: packet_send2: adding 32 (len 14 padlen 18 extra_pad 64)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug3: packet_send2: adding 32 (len 14 padlen 18 extra_pad 64)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug3: packet_send2: adding 64 (len 50 padlen 14 extra_pad 64)
debug2: we sent a password packet, wait for reply
Received disconnect from 10.8.65.51: 2: Too many authentication failures for test1
You can use “__hpux” to distinguish HPUX and others, see below :
#include <stdio.h>
int main() {
#ifdef hpux
printf("HPUX\n");
#else
printf("Not HPUX\n");
#endif
return 0;
}
# cc -c t.c; cc -o t t.o
# ./t
Not HPUX
#include <stdio.h>
int main() {
#ifdef __hpux
printf("HPUX\n");
#else
printf("Not HPUX\n");
#endif
return 0;
}
# cc -c t.c; cc -o t t.o
# ./t
HPUX
#
Thanks and regards.
Michael Li
SWIFT | Security Infrastructure, Messaging Solutions
Tel: +1 703 365 6136
www.swift.com <http://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.
From: Shachar Shemesh [mailto:sh...@sh...]
Sent: Saturday, November 11, 2017 10:24 AM
To: LI Michael
Cc: SSHPass Development
Subject: Re: [Sshpass-devel] FW: sshpass at HPUX 11.31
-----------------------------------------------------------------------------
This message originates from outside our organisation. Please be
extra vigilant before you click on a link, open attachments or reply.
-----------------------------------------------------------------------------
On 06/11/17 16:43, LI Michael via Sshpass-devel wrote:
Hi Shemesh,
Thank you very much for your reply.
I am greatly appreciated you will provide me a patch.
I tried “sleep 20 >/dev/null 2>&1 </dev/null” on my HPUX box, pressing Ctrl-C cannot abort the sleep, but on my linux box, pressing Ctrl-C aborts the sleep.
Thanks and regards.
Michael Li
SWIFT | Security Infrastructure, Messaging Solutions
Tel: +1 703 365 6136
www.swift.com <http://www.swift.com/>
Hi,
Can you please test the attached patch and see if it solves your problem?
Also, please run the program below and let me know what it prints:
#include <stdio.h>
int main() {
#ifdef hpux
printf("HPUX\n");
#else
printf("Not HPUX\n");
#endif
return 0;
}
Thanks,
Shachar
|
|
From: Shachar S. <sh...@sh...> - 2017-11-11 15:24:05
|
On 06/11/17 16:43, LI Michael via Sshpass-devel wrote: > > Hi Shemesh, > > Thank you very much for your reply. > > I am greatly appreciated you will provide me a patch. > > > > I tried “sleep 20 >/dev/null 2>&1 </dev/null” on my HPUX box, > pressing Ctrl-C cannot abort the sleep, but on my linux box, pressing > Ctrl-C aborts the sleep. > > > > Thanks and regards. > > Michael Li > > > > SWIFT | Security Infrastructure, Messaging Solutions > Tel: +1 703 365 6136 > www.swift.com <http://www.swift.com/> > Hi, Can you please test the attached patch and see if it solves your problem? Also, please run the program below and let me know what it prints: #include <stdio.h> int main() { #ifdef hpux printf("HPUX\n"); #else printf("Not HPUX\n"); #endif return 0; } Thanks, Shachar |
|
From: LI M. <Mic...@sw...> - 2017-11-06 14:43:40
|
Hi Shemesh, Thank you very much for your reply. I am greatly appreciated you will provide me a patch. I tried “sleep 20 >/dev/null 2>&1 </dev/null” on my HPUX box, pressing Ctrl-C cannot abort the sleep, but on my linux box, pressing Ctrl-C aborts the sleep. Thanks and regards. Michael Li SWIFT | Security Infrastructure, Messaging Solutions Tel: +1 703 365 6136 www.swift.com <http://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. From: Shachar Shemesh [mailto:sh...@sh...] Sent: Saturday, November 04, 2017 2:10 PM To: LI Michael Cc: SSHPass Development Subject: Re: FW: [Sshpass-devel] sshpass at HPUX 11.31 ----------------------------------------------------------------------------- This message originates from outside our organisation. Please be extra vigilant before you click on a link, open attachments or reply. ----------------------------------------------------------------------------- Hello Michael, I think I understand now. The problem is that, on HPUX, closing all file descriptors for the controlling TTY disconnect the process. As far as I can tell, this is a HPUX idiosyncrasy, and is not defined in Posix or, for that matter, any other Unix whose man page I could lay my hand on. Due solely to my curiosity, I wonder whether it is possible to break, using Ctrl-C, the following (bourne shell) command line: $ sleep 20 >/dev/null 2>&1 </dev/null On Linux, pressing Ctrl-C aborts the sleep. Does it do so on HPUX? I'll try to get a patch out to you in the coming couple of days. Thanks, Shachar On 01/11/2017 17:10, LI Michael wrote: Hi Shemesh, Thank you very much for your reply. I've forwarded your analysis to HP support, Based on their suggestions, I've done some tests, still no luck. Please see the mail I sent to HP support. Thanks and regards. Michael Li SWIFT | Security Infrastructure, Messaging Solutions Tel: +1 703 365 6136 www.swift.com <http://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. From: LI Michael Sent: Wednesday, November 01, 2017 10:57 AM Subject: RE: [Sshpass-devel] sshpass at HPUX 11.31 Hi Fluyt, Thank you very much for your suggestions. I have done the various combinations, no luck. Please see the testing results below. Any suggestions? commented out results error message tusc file close( slavept ); close( masterpt ); Failed read_passphrase: can't open /dev/tty: No such device or address tusc.out_close_slavept_masterpt setsid(); close( slavept ); close( masterpt ); Failed debug2: input_userauth_info_req: num_prompts 1 Password: Abcd1234 debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) Read from socket failed: Connection reset by peer tusc.out_setsid_close_slavept_masterpt setsid(); Success(*) debug2: input_userauth_info_req: num_prompts 1 Password: Abcd1234 debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) ... Wed Nov 1 13:47:41 GMT 2017 ... debug1: Exit status 0 tusc.out_setsid setsid(); close( slavept ); Success(*) debug2: input_userauth_info_req: num_prompts 1 Password: Abcd1234 debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) ... Wed Nov 1 13:50:35 GMT 2017 ... debug1: Exit status 0 tusc.out_setsid_close_slavept setsid(); close( masterpt ); Success(*) debug2: input_userauth_info_req: num_prompts 1 Password: Abcd1234 debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) ... Wed Nov 1 13:52:51 GMT 2017 ... debug1: Exit status 0 tusc.out_setsid_close_masterpt Success(*) means that even though get the correct date back, I have to type password interactively, unable to exit the process in the end, it must be killed by using "kill" command. /tmp/mli/tusc.ksh "/tmp/sshpass/sshpass-1.06/sshpass -p Abcd1234 ssh -vvv nledfd02 date" $ cat /tmp/mli/tusc.ksh /usr/contrib/bin/tusc -a -e -k -E -f -F -h -l -n -p -r all -R -T -u -v -w all -o /tmp/tusc/tusc.out $1 For the tusc files, please see the attached sshpass_tusc.z_ip. C:\CShared\SSHLite\sshpass>unzip -l sshpass_tusc.zip Archive: sshpass_tusc.zip Length Date Time Name --------- ---------- ----- ---- 1458612 11/01/2017 09:20 tusc.out_close_slavept_masterpt 1498879 11/01/2017 09:47 tusc.out_setsid 1498255 11/01/2017 09:52 tusc.out_setsid_close_masterpt 1498549 11/01/2017 09:50 tusc.out_setsid_close_slavept 1450065 11/01/2017 09:44 tusc.out_setsid_close_slavept_masterpt --------- ------- Thanks and regards. Michael Li SWIFT | Security Infrastructure, Messaging Solutions Tel: +1 703 365 6136 www.swift.com <http://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. From: Fluyt, Andre Sent: Wednesday, October 25, 2017 8:35 AM To: LI Michael Subject: RE: [Sshpass-devel] sshpass at HPUX 11.31 ----------------------------------------------------------------------------- This message originates from outside our organisation. Please be extra vigilant before you click on a link, open attachments or reply. ----------------------------------------------------------------------------- Hi Michael, Thanks. At least I can now see the exact same symptom as you observed. Reading the comment in the source, it looks like the developer has struggled getting the tty as controlling terminal working. There is a piece of source code that I don't understand the logic of. ... int childpid=fork(); if( childpid==0 ) { // Child // Detach us from the current TTY setsid(); // This line makes the ptty our controlling tty. We do not otherwise need it open slavept=open(name, O_RDWR ); close( slavept ); close( masterpt ); .... This results in this tusc trace output : ... fork() ....................................................................................... = 13356 fork() .................................................... (returning as child ...) ......... = 13354 setpgrp3(2) .................................................................................. = 13356 open("/dev/pts/0", O_RDWR|O_NOCTTY, 024700) .................................................. = 6 open("/dev/pts/0", O_RDWR, 01210) ............................................................ = 6 sigprocmask(SIG_SETMASK, 0x7ffff0c0, NULL) ................................................... = 0 close(6) ..................................................................................... = 0 close(4) ..................................................................................... = 0.. Now, if we look at the documentation : The Controlling Terminal A terminal can belong to a process as its controlling terminal. Each process of a session that has a controlling terminal has the same controlling terminal. A terminal can be the controlling terminal for at most one session. The controlling terminal for a session is allocated by the session leader. If a session leader has no controlling terminal and opens a terminal device file that is not already associated with a session without using the O_NOCTTY option (see open(2), the terminal becomes the controlling terminal of the session and the controlling terminal's foreground process group is set to the process group of the session leader. While a controlling terminal is associated with a session, the session leader is said to be the controlling process of the controlling terminal. The controlling terminal is inherited by a child process during a fork() (see fork(2)). A process relinquishes its controlling terminal if it creates a new session with setsid() or setpgrp() (see setsid(2) and setpgrp(2)), or when all file descriptors associated with the controlling terminal have been closed. When the controlling process terminates, the controlling terminal is disassociated from the current session, allowing it to be acquired by a new session leader. A SIGHUP signal is sent to all processes in the foreground process group of the controlling terminal. Subsequent access to the terminal by other processes in the earlier session can be denied (see Terminal Access Control) with attempts to access the terminal treated as if a modem disconnect had been sensed. So, the child does a 'setsid()' call which creates a new session and makes the child the session group leader, thereby relinquishing the controlling terminal. The developer states that the line : "slavept=open(name, O_RDWR );" should make the tty the controlling terminal for the child process. Ok, fair enough, but why does he then immediately close the slavept & masterpt ? See the yellow highlights in the documentation paragraph. What I would suggest is that you recompile without the closing of slavept & masterpt in the child process. See if that works. Also, I don't understand why we need to detach from the TTY by doing setsid(). Another test could be to leave out the setsid() call. Normally a child process inherits the controlling terminal from its parent. Best regards. Andre Fluyt Technical Account Manager Customer Solution Center hpesm_pri_grn_pos_email_011116 From: Shachar Shemesh [mailto:sh...@sh...] Sent: Sunday, September 03, 2017 10:07 AM To: LI Michael Cc: SSHPass Development Subject: Re: [Sshpass-devel] sshpass at HPUX 11.31 ----------------------------------------------------------------------------- This message originates from outside our organisation. Please be extra vigilant before you click on a link, open attachments or reply. ----------------------------------------------------------------------------- On 02/09/17 00:39, LI Michael wrote: Hi Shemesh, Thank you very much for your reply. Please see the attached tusc output, tusc.out. I ran the command as follows : test1@host1234 [/home/test1] $/tmp/tusc/tusc.ksh "/tmp/sshpass/sshpass-1.06/sshpass -p Xyza1234 ssh -vvv host1234 date" root@host1234 [/tmp/tusc] # cat tusc.ksh /usr/contrib/bin/tusc -a -e -k -E -f -F -h -l -n -p -r all -R -T -u -v -w all -o /tmp/tusc/tusc.out $1 Thanks and regards. Michael Li Here's what I see in the traces you sent me: -u [/tmp/sshpass][14066]{3783827} fork() ................... (returning as child ...) ......... = 14064 {3783821} The child process is 14066. -u [/tmp/sshpass][14066]{3783827} setpgrp3(2) ................................................. [entry] -u [/tmp/sshpass][14066]{3783827} setpgrp3(2) ................................................. = 14066 Start a new session, disconnecting from the previous TTY -u [/tmp/sshpass][14066]{3783827} open(0x400132d0, O_RDWR, 01210) ............................. [entry] -u [/tmp/sshpass][14066]{3783827} open("/dev/pts/5", O_RDWR, 01210) ........................... = 6 Open /dev/pts/5 with the flags O_RDWR. According to Posix, at this point pts/5 is supposed to become the controlling terminal for the new process. This, obviously, does not happen. At this point I need to return the responsibility to this problem to you. As far as I can tell, the process is not behaving the way it should. I have no tools for investigating this any further than that. If you can find out why opening a TTY device does not turn it into the controlling TTY of the process, please do let me know, and I can work that into sshpass. Shachar |
|
From: Shachar S. <sh...@sh...> - 2017-11-04 18:29:12
|
Hello Michael, I think I understand now. The problem is that, on HPUX, closing all file descriptors for the controlling TTY disconnect the process. As far as I can tell, this is a HPUX idiosyncrasy, and is not defined in Posix or, for that matter, any other Unix whose man page I could lay my hand on. Due solely to my curiosity, I wonder whether it is possible to break, using Ctrl-C, the following (bourne shell) command line: $ sleep 20 >/dev/null 2>&1 </dev/null On Linux, pressing Ctrl-C aborts the sleep. Does it do so on HPUX? I'll try to get a patch out to you in the coming couple of days. Thanks, Shachar On 01/11/2017 17:10, LI Michael wrote: > Hi Shemesh, > > Thank you very much for your reply. > > I've forwarded your analysis to HP support, > > Based on their suggestions, I've done some tests, still no luck. > > Please see the mail I sent to HP support. > > Thanks and regards. > > Michael Li > > SWIFT | Security Infrastructure, Messaging Solutions > Tel: +1 703 365 6136 > www.swift.com [1] > > 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. > > FROM: LI Michael > SENT: Wednesday, November 01, 2017 10:57 AM > SUBJECT: RE: [Sshpass-devel] sshpass at HPUX 11.31 > > Hi Fluyt, > > Thank you very much for your suggestions. > > I have done the various combinations, no luck. > > Please see the testing results below. Any suggestions? > > COMMENTED OUT > > RESULTS > > ERROR MESSAGE > > TUSC FILE > > close( slavept ); > close( masterpt ); > > Failed > > read_passphrase: can't open /dev/tty: No such device or address > > tusc.out_close_slavept_masterpt > > setsid(); > close( slavept ); > close( masterpt ); > > Failed > > debug2: input_userauth_info_req: num_prompts 1 > Password: Abcd1234 > debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) > Read from socket failed: Connection reset by peer > > tusc.out_setsid_close_slavept_masterpt > > setsid(); > > Success(*) > > debug2: input_userauth_info_req: num_prompts 1 > Password: Abcd1234 > debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) > ... > Wed Nov 1 13:47:41 GMT 2017 > ... > debug1: Exit status 0 > > tusc.out_setsid > > setsid(); > close( slavept ); > > Success(*) > > debug2: input_userauth_info_req: num_prompts 1 > Password: Abcd1234 > debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) > ... > Wed Nov 1 13:50:35 GMT 2017 > ... > debug1: Exit status 0 > > tusc.out_setsid_close_slavept > > setsid(); > close( masterpt ); > > Success(*) > > debug2: input_userauth_info_req: num_prompts 1 > Password: Abcd1234 > debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) > ... > Wed Nov 1 13:52:51 GMT 2017 > ... > debug1: Exit status 0 > > tusc.out_setsid_close_masterpt > > Success(*) means that even though get the correct date back, I have to type password interactively, unable to exit the process in the end, it must be killed by using "kill" command. > > /tmp/mli/tusc.ksh "/tmp/sshpass/sshpass-1.06/sshpass -p Abcd1234 ssh -vvv nledfd02 date" > > $ cat /tmp/mli/tusc.ksh > > /usr/contrib/bin/tusc -a -e -k -E -f -F -h -l -n -p -r all -R -T -u -v -w all -o /tmp/tusc/tusc.out $1 > > For the tusc files, please see the attached sshpass_tusc.z_ip. > > _C:CSharedSSHLitesshpass>unzip -l sshpass_tusc.zip_ > > _Archive: sshpass_tusc.zip_ > > _ Length Date Time Name_ > > _--------- ---------- ----- ----_ > > _ 1458612 11/01/2017 09:20 tusc.out_close_slavept_masterpt_ > > _ 1498879 11/01/2017 09:47 tusc.out_setsid_ > > _ 1498255 11/01/2017 09:52 tusc.out_setsid_close_masterpt_ > > _ 1498549 11/01/2017 09:50 tusc.out_setsid_close_slavept_ > > _ 1450065 11/01/2017 09:44 tusc.out_setsid_close_slavept_masterpt_ > > _--------- -------_ > > Thanks and regards. > > Michael Li > > SWIFT | Security Infrastructure, Messaging Solutions > Tel: +1 703 365 6136 > www.swift.com [1] > > 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. > > FROM: Fluyt, Andre > SENT: Wednesday, October 25, 2017 8:35 AM > TO: LI Michael > > SUBJECT: RE: [Sshpass-devel] sshpass at HPUX 11.31 > > ----------------------------------------------------------------------------- > This message originates from outside our organisation. Please be > extra vigilant before you click on a link, open attachments or reply. > ----------------------------------------------------------------------------- > > Hi Michael, > > Thanks. At least I can now see the exact same symptom as you observed. > > Reading the comment in the source, it looks like the developer has struggled getting the tty as controlling terminal working. > > There is a piece of source code that I don't understand the logic of. > > _..._ > > _int childpid=fork();_ > > _ if( childpid==0 ) {_ > > _ // Child_ > > _ _ > > _ // Detach us from the current TTY_ > > _ setsid();_ > > _ // This line makes the ptty our controlling tty. We do not otherwise need it open_ > > _ slavept=open(name, O_RDWR );_ > > _ close( slavept );_ > > _ _ > > _ close( masterpt );_ > > _...._ > > _ _ > > _ _ > > This results in this tusc trace output : > > ... > > fork() ....................................................................................... = 13356 > > fork() .................................................... (returning as child ...) ......... = 13354 > > setpgrp3(2) .................................................................................. = 13356 > > open("/dev/pts/0", O_RDWR|O_NOCTTY, 024700) .................................................. = 6 > > open("/dev/pts/0", O_RDWR, 01210) ............................................................ = 6 > > sigprocmask(SIG_SETMASK, 0x7ffff0c0, NULL) ................................................... = 0 > > close(6) ..................................................................................... = 0 > > close(4) ..................................................................................... = 0.. > > Now, if we look at the documentation : > > The Controlling Terminal A terminal can belong to a process as its controlling terminal. Each process of a session that has a controlling terminal has the same controlling terminal. A terminal can be the controlling terminal for at most one session. The controlling terminal for a session is allocated by the session leader. If a session leader has no controlling terminal and opens a terminal device file that is not already associated with a session without using the O_NOCTTY option (see open(2), the terminal becomes the controlling terminal of the session and the controlling terminal's foreground process group is set to the process group of the session leader. While a controlling terminal is associated with a session, the session leader is said to be the controlling process of the controlling terminal. The controlling terminal is inherited by a child process during a fork() (see fork(2)). A process relinquishes its controlling terminal if it creates a new session with setsid() or setpgrp() (see setsid(2) and setpgrp(2)), or when all file descriptors associated with the controlling terminal have been closed. When the controlling process terminates, the controlling terminal is disassociated from the current session, allowing it to be acquired by a new session leader. A SIGHUP signal is sent to all processes in the foreground process group of the controlling terminal. Subsequent access to the terminal by other processes in the earlier session can be denied (see Terminal Access Control) with attempts to access the terminal treated as if a modem disconnect had been sensed. > > So, the child does a 'setsid()' call which creates a new session and makes the child the session group leader, thereby relinquishing the controlling terminal. > > The developer states that the line : "_slavept=open(name, O_RDWR );" _should make the tty the controlling terminal for the child process. > > Ok, fair enough, but why does he then immediately close the slavept & masterpt ? > > See the yellow highlights in the documentation paragraph. > > What I would suggest is that you recompile without the closing of slavept & masterpt in the child process. See if that works. > > Also, I don't understand why we need to detach from the TTY by doing setsid(). Another test could be to leave out the setsid() call. Normally a child process inherits the controlling terminal from its parent. > > Best regards. > > Andre Fluyt > Technical Account Manager > Customer Solution Center > > FROM: Shachar Shemesh [mailto:sh...@sh...] > SENT: Sunday, September 03, 2017 10:07 AM > TO: LI Michael > CC: SSHPass Development > SUBJECT: Re: [Sshpass-devel] sshpass at HPUX 11.31 > > ----------------------------------------------------------------------------- > This message originates from outside our organisation. Please be > extra vigilant before you click on a link, open attachments or reply. > ----------------------------------------------------------------------------- > > On 02/09/17 00:39, LI Michael wrote: > > Hi Shemesh, > > Thank you very much for your reply. > > Please see the attached tusc output, tusc.out. > > I ran the command as follows : > > _test1@host1234 [/home/test1] $/tmp/tusc/tusc.ksh "/tmp/sshpass/sshpass-1.06/sshpass -p Xyza1234 ssh -vvv host1234 date"_ > > _ _ > > _root@host1234 [/tmp/tusc]_ > > _# cat tusc.ksh_ > > _/usr/contrib/bin/tusc -a -e -k -E -f -F -h -l -n -p -r all -R -T -u -v -w all -o /tmp/tusc/tusc.out $1_ > > _ _ > > Thanks and regards. > > Michael Li > > Here's what I see in the traces you sent me: > > -u [/tmp/sshpass][14066]{3783827} fork() ................... (returning as child ...) ......... = 14064 {3783821} > > The child process is 14066. > > -u [/tmp/sshpass][14066]{3783827} setpgrp3(2) ................................................. [entry] > -u [/tmp/sshpass][14066]{3783827} setpgrp3(2) ................................................. = 14066 > > Start a new session, disconnecting from the previous TTY > > -u [/tmp/sshpass][14066]{3783827} open(0x400132d0, O_RDWR, 01210) ............................. [entry] > -u [/tmp/sshpass][14066]{3783827} open("/dev/pts/5", O_RDWR, 01210) ........................... = 6 > > Open /dev/pts/5 with the flags O_RDWR. According to Posix, at this point pts/5 is supposed to become the controlling terminal for the new process. This, obviously, does not happen. > > At this point I need to return the responsibility to this problem to you. As far as I can tell, the process is not behaving the way it should. I have no tools for investigating this any further than that. > > If you can find out why opening a TTY device does not turn it into the controlling TTY of the process, please do let me know, and I can work that into sshpass. > > Shachar Links: ------ [1] http://www.swift.com/ |
|
From: LI M. <Mic...@sw...> - 2017-11-01 15:23:23
|
Hi Shemesh, Thank you very much for your reply. I’ve forwarded your analysis to HP support, Based on their suggestions, I’ve done some tests, still no luck. Please see the mail I sent to HP support. Thanks and regards. Michael Li SWIFT | Security Infrastructure, Messaging Solutions Tel: +1 703 365 6136 www.swift.com <http://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. From: LI Michael Sent: Wednesday, November 01, 2017 10:57 AM Subject: RE: [Sshpass-devel] sshpass at HPUX 11.31 Hi Fluyt, Thank you very much for your suggestions. I have done the various combinations, no luck. Please see the testing results below. Any suggestions? commented out results error message tusc file close( slavept ); close( masterpt ); Failed read_passphrase: can't open /dev/tty: No such device or address tusc.out_close_slavept_masterpt setsid(); close( slavept ); close( masterpt ); Failed debug2: input_userauth_info_req: num_prompts 1 Password: Abcd1234 debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) Read from socket failed: Connection reset by peer tusc.out_setsid_close_slavept_masterpt setsid(); Success(*) debug2: input_userauth_info_req: num_prompts 1 Password: Abcd1234 debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) … Wed Nov 1 13:47:41 GMT 2017 … debug1: Exit status 0 tusc.out_setsid setsid(); close( slavept ); Success(*) debug2: input_userauth_info_req: num_prompts 1 Password: Abcd1234 debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) … Wed Nov 1 13:50:35 GMT 2017 … debug1: Exit status 0 tusc.out_setsid_close_slavept setsid(); close( masterpt ); Success(*) debug2: input_userauth_info_req: num_prompts 1 Password: Abcd1234 debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) … Wed Nov 1 13:52:51 GMT 2017 … debug1: Exit status 0 tusc.out_setsid_close_masterpt Success(*) means that even though get the correct date back, I have to type password interactively, unable to exit the process in the end, it must be killed by using "kill" command. /tmp/mli/tusc.ksh "/tmp/sshpass/sshpass-1.06/sshpass -p Abcd1234 ssh -vvv nledfd02 date" $ cat /tmp/mli/tusc.ksh /usr/contrib/bin/tusc -a -e -k -E -f -F -h -l -n -p -r all -R -T -u -v -w all -o /tmp/tusc/tusc.out $1 For the tusc files, please see the attached sshpass_tusc.z_ip. C:\CShared\SSHLite\sshpass>unzip -l sshpass_tusc.zip Archive: sshpass_tusc.zip Length Date Time Name --------- ---------- ----- ---- 1458612 11/01/2017 09:20 tusc.out_close_slavept_masterpt 1498879 11/01/2017 09:47 tusc.out_setsid 1498255 11/01/2017 09:52 tusc.out_setsid_close_masterpt 1498549 11/01/2017 09:50 tusc.out_setsid_close_slavept 1450065 11/01/2017 09:44 tusc.out_setsid_close_slavept_masterpt --------- ------- Thanks and regards. Michael Li SWIFT | Security Infrastructure, Messaging Solutions Tel: +1 703 365 6136 www.swift.com <http://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. From: Fluyt, Andre Sent: Wednesday, October 25, 2017 8:35 AM To: LI Michael Subject: RE: [Sshpass-devel] sshpass at HPUX 11.31 ----------------------------------------------------------------------------- This message originates from outside our organisation. Please be extra vigilant before you click on a link, open attachments or reply. ----------------------------------------------------------------------------- Hi Michael, Thanks. At least I can now see the exact same symptom as you observed. Reading the comment in the source, it looks like the developer has struggled getting the tty as controlling terminal working. There is a piece of source code that I don’t understand the logic of. ... int childpid=fork(); if( childpid==0 ) { // Child // Detach us from the current TTY setsid(); // This line makes the ptty our controlling tty. We do not otherwise need it open slavept=open(name, O_RDWR ); close( slavept ); close( masterpt ); .... This results in this tusc trace output : ... fork() ....................................................................................... = 13356 fork() .................................................... (returning as child ...) ......... = 13354 setpgrp3(2) .................................................................................. = 13356 open("/dev/pts/0", O_RDWR|O_NOCTTY, 024700) .................................................. = 6 open("/dev/pts/0", O_RDWR, 01210) ............................................................ = 6 sigprocmask(SIG_SETMASK, 0x7ffff0c0, NULL) ................................................... = 0 close(6) ..................................................................................... = 0 close(4) ..................................................................................... = 0.. Now, if we look at the documentation : The Controlling Terminal A terminal can belong to a process as its controlling terminal. Each process of a session that has a controlling terminal has the same controlling terminal. A terminal can be the controlling terminal for at most one session. The controlling terminal for a session is allocated by the session leader. If a session leader has no controlling terminal and opens a terminal device file that is not already associated with a session without using the O_NOCTTY option (see open(2), the terminal becomes the controlling terminal of the session and the controlling terminal’s foreground process group is set to the process group of the session leader. While a controlling terminal is associated with a session, the session leader is said to be the controlling process of the controlling terminal. The controlling terminal is inherited by a child process during a fork() (see fork(2)). A process relinquishes its controlling terminal if it creates a new session with setsid() or setpgrp() (see setsid(2) and setpgrp(2)), or when all file descriptors associated with the controlling terminal have been closed. When the controlling process terminates, the controlling terminal is disassociated from the current session, allowing it to be acquired by a new session leader. A SIGHUP signal is sent to all processes in the foreground process group of the controlling terminal. Subsequent access to the terminal by other processes in the earlier session can be denied (see Terminal Access Control) with attempts to access the terminal treated as if a modem disconnect had been sensed. So, the child does a ‘setsid()’ call which creates a new session and makes the child the session group leader, thereby relinquishing the controlling terminal. The developer states that the line : “slavept=open(name, O_RDWR );” should make the tty the controlling terminal for the child process. Ok, fair enough, but why does he then immediately close the slavept & masterpt ? See the yellow highlights in the documentation paragraph. What I would suggest is that you recompile without the closing of slavept & masterpt in the child process. See if that works. Also, I don’t understand why we need to detach from the TTY by doing setsid(). Another test could be to leave out the setsid() call. Normally a child process inherits the controlling terminal from its parent. Best regards. Andre Fluyt Technical Account Manager Customer Solution Center hpesm_pri_grn_pos_email_011116 From: Shachar Shemesh [mailto:sh...@sh...] Sent: Sunday, September 03, 2017 10:07 AM To: LI Michael Cc: SSHPass Development Subject: Re: [Sshpass-devel] sshpass at HPUX 11.31 ----------------------------------------------------------------------------- This message originates from outside our organisation. Please be extra vigilant before you click on a link, open attachments or reply. ----------------------------------------------------------------------------- On 02/09/17 00:39, LI Michael wrote: Hi Shemesh, Thank you very much for your reply. Please see the attached tusc output, tusc.out. I ran the command as follows : test1@host1234 [/home/test1] $/tmp/tusc/tusc.ksh "/tmp/sshpass/sshpass-1.06/sshpass -p Xyza1234 ssh -vvv host1234 date" root@host1234 [/tmp/tusc] # cat tusc.ksh /usr/contrib/bin/tusc -a -e -k -E -f -F -h -l -n -p -r all -R -T -u -v -w all -o /tmp/tusc/tusc.out $1 Thanks and regards. Michael Li Here's what I see in the traces you sent me: -u [/tmp/sshpass][14066]{3783827} fork() ................... (returning as child ...) ......... = 14064 {3783821} The child process is 14066. -u [/tmp/sshpass][14066]{3783827} setpgrp3(2) ................................................. [entry] -u [/tmp/sshpass][14066]{3783827} setpgrp3(2) ................................................. = 14066 Start a new session, disconnecting from the previous TTY -u [/tmp/sshpass][14066]{3783827} open(0x400132d0, O_RDWR, 01210) ............................. [entry] -u [/tmp/sshpass][14066]{3783827} open("/dev/pts/5", O_RDWR, 01210) ........................... = 6 Open /dev/pts/5 with the flags O_RDWR. According to Posix, at this point pts/5 is supposed to become the controlling terminal for the new process. This, obviously, does not happen. At this point I need to return the responsibility to this problem to you. As far as I can tell, the process is not behaving the way it should. I have no tools for investigating this any further than that. If you can find out why opening a TTY device does not turn it into the controlling TTY of the process, please do let me know, and I can work that into sshpass. Shachar |
|
From: Shachar S. <sh...@sh...> - 2017-09-03 14:07:30
|
On 02/09/17 00:39, LI Michael wrote:
>
>
>
> Hi Shemesh,
>
>
>
> Thank you very much for your reply.
>
>
>
> Please see the attached tusc output, tusc.out.
>
>
>
> I ran the command as follows :
>
>
>
> /test1@host1234 [/home/test1] $/tmp/tusc/tusc.ksh
> "/tmp/sshpass/sshpass-1.06/sshpass -p Xyza1234 ssh -vvv host1234 date"/
>
> / /
>
> /root@host1234 [/tmp/tusc]/
>
> /# cat tusc.ksh/
>
> //usr/contrib/bin/tusc -a -e -k -E -f -F -h -l -n -p -r all -R -T -u
> -v -w all -o /tmp/tusc/tusc.out $1/
>
> / /
>
>
>
> Thanks and regards.
>
> Michael Li
>
>
>
Here's what I see in the traces you sent me:
-u [/tmp/sshpass][14066]{3783827} fork() ................... (returning
as child ...) ......... = 14064 {3783821}
The child process is 14066.
-u [/tmp/sshpass][14066]{3783827} setpgrp3(2)
................................................. [entry]
-u [/tmp/sshpass][14066]{3783827} setpgrp3(2)
................................................. = 14066
Start a new session, disconnecting from the previous TTY
-u [/tmp/sshpass][14066]{3783827} open(0x400132d0, O_RDWR, 01210)
............................. [entry]
-u [/tmp/sshpass][14066]{3783827} open("/dev/pts/5", O_RDWR, 01210)
........................... = 6
Open /dev/pts/5 with the flags O_RDWR. According to Posix, at this point
pts/5 is supposed to become the controlling terminal for the new
process. This, obviously, does not happen.
At this point I need to return the responsibility to this problem to
you. As far as I can tell, the process is not behaving the way it
should. I have no tools for investigating this any further than that.
If you can find out why opening a TTY device does not turn it into the
controlling TTY of the process, please do let me know, and I can work
that into sshpass.
Shachar
|
|
From: Shachar S. <sh...@sh...> - 2017-09-01 18:51:54
|
On 29/08/17 22:47, LI Michael via Sshpass-devel wrote: > > Hi, > > > > Does anyone successfully run sshpass at HPUX 11.31 ? > > > > I’ve compiled sshpass 1.06 at HPUX 1131, but when I run it, I got errors. > > The command I run : > > $ sshpass -p Abcd1234 ssh -vvv nledfd02 date; > > > Following my previous email, it appears HPUX has tusc: > *HP-UX* > For HP-UX, tusc can be downloaded from the HP web site www.hp.com > <http://www.hp.com> at the Porting and Archiving Center and installed > on your HP-UX system. To put tusc on the path, for bourne shell, > type, for tusc installed in /usr/local/bin: > "PATH=$PATH:/usr/local/bin;export PATH" and for C shell, type "setenv > PATH {$PATH}:/usr/local/bin. > > to run tusc, type > tusc -f -o <full path name to output file> <program name and any > arguments> > > This will give the default output for tusc. To get information about > all the options for tusc, type "tusc -h". > > http://knowledgebase.progress.com/articles/Article/3669 Please use it on sshpass and let me know what the output is. Thanks, Shachar |
|
From: Shachar S. <sh...@sh...> - 2017-09-01 17:48:31
|
On 29/08/17 22:47, LI Michael via Sshpass-devel wrote: > > Hi, > > > > Does anyone successfully run sshpass at HPUX 11.31 ? > > > > I’ve compiled sshpass 1.06 at HPUX 1131, but when I run it, I got errors. > > The command I run : > > $ sshpass -p Abcd1234 ssh -vvv nledfd02 date; > > > > The error message in the console output : > > debug1: read_passphrase: can't open /dev/tty: No such device or address > Does HPUX have strace? Maybe some similar tool that logs system calls that a process performs? If so, please send me the output of what system calls sshpass is issuing. Thanks, Shachar > > debug3: packet_send2: adding 64 (len 50 padlen 14 extra_pad 64) > > debug2: we sent a password packet, wait for reply > > debug1: Authentications that can continue: password,keyboard-interactive > > Permission denied, please try again. > > debug1: read_passphrase: can't open /dev/tty: No such device or address > > debug3: packet_send2: adding 64 (len 50 padlen 14 extra_pad 64) > > debug2: we sent a password packet, wait for reply > > Received disconnect from 10.8.65.51: 2: Too many authentication > failures for test1 > > > > The error message in sshd output : > > root@NLEDFD02 [/tmp/sshpass/sshpass105] > > # /opt/ssh/sbin/sshd -d > > > > Postponed keyboard-interactive for test1 from 10.8.65.51 port 52444 > ssh2 [preauth] > > PAM: Authentication failed for test1 from 10.8.65.51 > > Failed keyboard-interactive/pam for test1 from 10.8.65.51 port 52444 ssh2 > > debug1: Entering record_failed_login uid 0 > > debug1: audit event euid 0 user test1 event 5 (AUTH_FAIL_KBDINT) > > debug1: aud_sav_flag=1 > > debug1: userauth-request for user test1 service ssh-connection method > password [preauth] > > debug1: attempt 4 failures 3 [preauth] > > Failed none for test1 from 10.8.65.51 port 52444 ssh2 > > debug1: audit event euid 0 user test1 event 3 (AUTH_FAIL_NONE) > > debug1: userauth-request for user test1 service ssh-connection method > password [preauth] > > debug1: attempt 5 failures 4 [preauth] > > Failed password for test1 from 10.8.65.51 port 52444 ssh2 > > debug1: Entering record_failed_login uid 0 > > debug1: audit event euid 0 user test1 event 4 (AUTH_FAIL_PASSWD) > > debug1: aud_sav_flag=1 > > Disconnecting: Too many authentication failures for test1 [preauth] > > debug1: do_cleanup [preauth] > > debug1: monitor_read_log: child log fd closed > > debug1: audit event euid 0 user test1 event 0 (LOGIN_EXCEED_MAXTRIES) > > debug1: aud_sav_flag=1 > > debug1: do_cleanup > > debug1: PAM: cleanup > > debug1: Killing privsep child 21704 > > debug1: audit event euid 0 user test1 event 12 (CONNECTION_ABANDON) > > debug1: aud_sav_flag=1 > > > > > > root@NLEDFD02 [/tmp/sshpass/sshpass105] > > # uname -a > > HP-UX NLEDFD02 B.11.31 U ia64 3687447314 unlimited-user license > > > > root@NLEDFD02 [/tmp/sshpass/sshpass105] > > # cc -V > > (Bundled) cc: HP C/aC++ B3910B A.06.12 [Oct 11 2006] > > > > root@NLEDFD02 [/tmp/sshpass/sshpass105] > > # ssh -version > > OpenSSH_6.2p1+sftpfilecontrol-v1.3-hpn13v12, OpenSSL 0.9.8y 5 Feb 2013 > > HP-UX Secure Shell-A.06.20.006, HP-UX Secure Shell version > > > > Thanks and regards. > > Michael Li > > > > SWIFT | Security Infrastructure, Messaging Solutions > Tel: +1 703 365 6136 > www.swift.com <http://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. > > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Sshpass-devel mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshpass-devel |
|
From: LI M. <Mic...@sw...> - 2017-08-29 20:23:10
|
Hi, Does anyone successfully run sshpass at HPUX 11.31 ? I've compiled sshpass 1.06 at HPUX 1131, but when I run it, I got errors. The command I run : $ sshpass -p Abcd1234 ssh -vvv nledfd02 date; The error message in the console output : debug1: read_passphrase: can't open /dev/tty: No such device or address debug3: packet_send2: adding 64 (len 50 padlen 14 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentications that can continue: password,keyboard-interactive Permission denied, please try again. debug1: read_passphrase: can't open /dev/tty: No such device or address debug3: packet_send2: adding 64 (len 50 padlen 14 extra_pad 64) debug2: we sent a password packet, wait for reply Received disconnect from 10.8.65.51: 2: Too many authentication failures for test1 The error message in sshd output : root@NLEDFD02 [/tmp/sshpass/sshpass105] # /opt/ssh/sbin/sshd -d Postponed keyboard-interactive for test1 from 10.8.65.51 port 52444 ssh2 [preauth] PAM: Authentication failed for test1 from 10.8.65.51 Failed keyboard-interactive/pam for test1 from 10.8.65.51 port 52444 ssh2 debug1: Entering record_failed_login uid 0 debug1: audit event euid 0 user test1 event 5 (AUTH_FAIL_KBDINT) debug1: aud_sav_flag=1 debug1: userauth-request for user test1 service ssh-connection method password [preauth] debug1: attempt 4 failures 3 [preauth] Failed none for test1 from 10.8.65.51 port 52444 ssh2 debug1: audit event euid 0 user test1 event 3 (AUTH_FAIL_NONE) debug1: userauth-request for user test1 service ssh-connection method password [preauth] debug1: attempt 5 failures 4 [preauth] Failed password for test1 from 10.8.65.51 port 52444 ssh2 debug1: Entering record_failed_login uid 0 debug1: audit event euid 0 user test1 event 4 (AUTH_FAIL_PASSWD) debug1: aud_sav_flag=1 Disconnecting: Too many authentication failures for test1 [preauth] debug1: do_cleanup [preauth] debug1: monitor_read_log: child log fd closed debug1: audit event euid 0 user test1 event 0 (LOGIN_EXCEED_MAXTRIES) debug1: aud_sav_flag=1 debug1: do_cleanup debug1: PAM: cleanup debug1: Killing privsep child 21704 debug1: audit event euid 0 user test1 event 12 (CONNECTION_ABANDON) debug1: aud_sav_flag=1 root@NLEDFD02 [/tmp/sshpass/sshpass105] # uname -a HP-UX NLEDFD02 B.11.31 U ia64 3687447314 unlimited-user license root@NLEDFD02 [/tmp/sshpass/sshpass105] # cc -V (Bundled) cc: HP C/aC++ B3910B A.06.12 [Oct 11 2006] root@NLEDFD02 [/tmp/sshpass/sshpass105] # ssh -version OpenSSH_6.2p1+sftpfilecontrol-v1.3-hpn13v12, OpenSSL 0.9.8y 5 Feb 2013 HP-UX Secure Shell-A.06.20.006, HP-UX Secure Shell version Thanks and regards. Michael Li SWIFT | Security Infrastructure, Messaging Solutions Tel: +1 703 365 6136 <http://www.swift.com/> 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. |
|
From: Infused W JC <inf...@gm...> - 2017-07-29 20:41:29
|
I get the following error:
$ sshpass.exe
3 [main] sshpass (9292) C:\Program Files\Git\mingw64\bin\sshpass.exe:
*** fatal error - cygheap base mismatch detected - 0x1802F4408/0x180304408.
This problem is probably due to using incompatible versions of the cygwin
DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version
*should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
I have placed cygwin1.dll in the C:\Program Files\Git\mingw64\bin
What else do I need to do to get this to work?
Ed
|
|
From: Nadelman, J. <jna...@sr...> - 2016-05-10 12:34:39
|
Is sshpass is suppressing or hiding the console output of scp? There is no console output when using sshpass in a script to scp files. Is there a way to enable the sshpass scp output to console? $ sshpass -p [password] scp [file] root@[ip]:/[dir] Jack N Note: This message is directed to and is for the use of the above-noted addressee only, and its contents may be legally privileged or confidential. If the reader of this message is not the intended recipient, you are hereby notified that any distribution, dissemination, or copy of this message is strictly prohibited. If you have received this message in error, please delete it immediately and notify the sender. This message is not intended to be an electronic signature nor to constitute an agreement of any kind under applicable law unless otherwise expressly indicated hereon. |
|
From: Brian S. <bs...@gm...> - 2015-08-11 15:44:30
|
As noted in bug ticket #12 sshpass 1.05 does not work with SSH servers running on FreeBSD hosts. I have built from trunk and confirmed that does work with my hosts. Any thoughts on when we could expect a 1.06 release? It would be nice to get this fixed in the upstream package repositories. Thanks |
|
From: Russell W. <rus...@gm...> - 2014-01-23 06:48:40
|
ssh-pass complied on cygwin works, but there seems to be a bug when ever the program is executed from anything other than the cygwin mintty terminal. Example. open up a command window, run cygwin from the command window, run sshpass... sshpass will return with 2 from the command window as opposed to oppenning up cygwin inside mintty which runs flawlessly. Before all the windows jokes come in, it's not that I like windows, it's that I am forced to work with it. Cygwin is what makes my living tolerable. Did I just say that?? Some please knife me in my sleep...... the exit code is being returned around line 350 return WEXITSTATUS(status); As far as I could tell, pselect never returns anything and then I ran out of time to debug the issue. |
|
From: Bruce K. <bk...@us...> - 2013-07-27 17:08:40
|
On 07/26/13 20:14, Shachar Shemesh wrote:
>> I only do it if it is welcome. If it won't get applied, I won't bother.
>> As the author, you probably have an idea about whether the whole idea
>> would be accepted or not.
>>
>> I will guess now that it would be. Thanks! Cheers - Bruce
> I'm sorry, this simply is not how open source works.
It all depends upon the actors. There is an effort difference of
close to a factor of four between hacking together enough that
it meets my needs and polishing it enough to be documented and
generally usable.
What you say about stashing passwords is mostly true.
However, whenever I have had need to ssh to an internet-accessible
domain, they have always used public keys. In fact, I usually
do not even have password access. Where this tool is useful
to me is on a private network behind a very secure firewall.
I need to ssh into many nodes that have pre-configured read-only
home directories.
Why not just have all nodes use the same password? Excellent
question. I do wish I had a cogent answer. I guess because
I am accessing machines that were configured by different groups
and each had better (or different) ideas about what password to
use. Whatever. I'm here now. My first idea was to have a
bash config script that filled an associative array with all
the passwords I needed. That is probably the easiest.
> If you believe in this patch, preferably because you need it yourself,
> then you write it.
I tried to be sufficiently clear. Maybe I was not.
I was not expecting anyone else to step up and do anything.
Sorry I was not clearer.
> This might mean that it might get accepted, or it might mean it will not.
> It might even mean there is a fundamental problem with the concept.
I was trying to guard against the 4X effort for something that
had no chance whatever.
> If you want to be taken seriously, though, you show effort by writing
> the patch.
It is not like I've not made patches. I have a chunk of GCC,
I've hacked core utils, I've done many things. I also strive
to avoid wasting my time on futile efforts, though I've done
that, too.
> ... it is better to start your email with something along
> the lines of "here is a new feature I was thinking of implementing,
> and I'd love to get feedback on whether this is even needed or useful".
That was the intent. I am sorry it wasn't clear enough.
> Specifically regarding your suggestion: I do not like it much.
> I have security as my background, and I cringe whenever passwords
> are stored in plain text. Your idea involves plain text passwords
Indeed. It really is not intended for secure access. It is for
insecure access via secure mechanisms.
> laying around in the clear for much longer than the other alternatives.
> Then again, ssh-pass has been a compromise from the get-go, and as you
> have stated, there are tradeoffs either way. As such, if you write it,
> and if there is no technical reason not to, I'll *probably* include it.
> After all, with the proper warnings in the man page, a user is always
> free not to use this feature.
The caveat would be along the lines of:
Don't use this feature unless you are using it only for access
behind a secure firewall.
> Having said that, I think there are things we can do to make this idea
> better, without compromising the usability. In fact, with a little bit
> of work, we can make this into a feature that can be the recommended
> method of doing things. One thing we might do is to tie the passwords
> in to the ssh public key infrastructure.
That is, of course, why I was suggesting SSH-like syntax and
using a file in ~/.ssh -- which, to work, must be secured properly.
> Most valid uses of ssh-pass
> are for cases where the user only controls the client side, and the
> server, for whatever reason, does not allow public key authentication.
Like "compute nodes" that have no local storage and read-only
home directories?
> If we offer a "remember this password" feature for ssh-pass, and
> particularly, encrypt the password files with the user's private key
> (through the ssh-agent or otherwise), then we might get a feature
> that gives you the usability you want, while actually being MORE
> secure than the other ssh-pass password passing options.
That would be nice. Beyond my scope of expertise, but this suggestion
is certainly very welcome.
=================
To a completely different topic, but related to passwords across a network.
You said:
> I have security as my background, ...
I do not.
So I have a toy for providing passwords that *does not* involve
storing them and yet does not require complex memorization gymnastics
to retrieve them either. The concept is that you start with a
hash seed stored away that is difficult to gain access to.
The hashed text is augmented by an unlikely permutation of
a domain name to produce the actual hash. That permutation
is only stored in the brain of the user. The hash bits are
converted to plain text via base64 encoding and trimmed to length.
That's your password (modulo tweaks for certain requirements).
The result is that it is easier to have different passwords
for every domain than it is to use the same one for many sites.
In essence, an attacker has two ways to gain access:
1. obtain the password from a particular domain. The only thing
a user can do is make sure other domains have other passwords.
2. obtain the hash seed file ("something the user has"), obtain
the domain name transform ("something the user knows"),
know that the target uses this obscure little thing I
cooked up, and, finally, know which domains the user has
access to (more stuff known by the user).
I think that is reasonably secure. I've presented it to the FSF
for blessing, but they want some feedback from security types,
which I'm not. And it is dragging a bit.
In case you (all) might be interested and willing to play and comment:
http://autogen.sourceforge.net/data/gnu-pw-mgr-0.5.tar.xz
The tarball includes a man page and texi docs.
Thank you for your feedback, Shachar!
Regards, Bruce
|
|
From: Shachar S. <sh...@sh...> - 2013-07-27 03:15:00
|
On 26/07/13 23:16, Bruce Korb wrote: > On 07/26/13 12:05, Shachar Shemesh wrote: >>> So let me know if you want the patch. >> Sending the patch to an open source project is the rule rather than >> the exception. > > I only do it if it is welcome. If it won't get applied, I won't > bother. :) > As the author, you probably have an idea about whether the whole idea > would be accepted or not. > > I will guess now that it would be. Thanks! Cheers - Bruce I'm sorry, this simply is not how open source works. What I'm about to say is true, to greater or lesser degree, to every single open source project I have ever participated in. First of all, open source project discussions are about the community. This means you do not exclude the mailing list from your response merely because the maintainer answered your email. Unless you have something personal to say to me, you hit the "reply to all" button and include the community in the discussion. It is possible that someone other than me will have something to contribute to this discussion. If you believe in this patch, preferably because you need it yourself, then you write it. You send it to the list/maintainer/whatever, because, generally speaking, having your patch available through upstream is the best course for everyone involved (may not be as true for a "complete" project such as ssh-pass). This might mean that it might get accepted, or it might mean it will not. It might even mean there is a fundamental problem with the concept. If you want to be taken seriously, though, you show effort by writing the patch. The rule is that talk is cheap and good ideas are a dime a dozen. I try hard on my project's lists not to abuse anyone, especially not those who made an effort to back their own words. This, however, does not mean that your patch will be accepted. There are no guarantees. If you believe in your patch (and I sure hope you do not intend to submit a patch you do not believe in), you are free to offer it as a fork. In some projects, you might get an answer whether your patch even has a chance. On some of the bigger projects you will not. Either way, as a word of advice, it is better to start your email with something along the lines of "here is a new feature I was thinking of implementing, and I'd love to get feedback on whether this is even needed or useful". This way, you do not sound as if you expect someone else to implement your idea. Specifically regarding your suggestion: I do not like it much. I have security as my background, and I cringe whenever passwords are stored in plain text. Your idea involves plain text passwords laying around in the clear for much longer than the other alternatives. Then again, ssh-pass has been a compromise from the get-go, and as you have stated, there are tradeoffs either way. As such, if you write it, and if there is no technical reason not to, I'll *probably* include it. After all, with the proper warnings in the man page, a user is always free not to use this feature. Having said that, I think there are things we can do to make this idea better, without compromising the usability. In fact, with a little bit of work, we can make this into a feature that can be the recommended method of doing things. One thing we might do is to tie the passwords in to the ssh public key infrastructure. Most valid uses of ssh-pass are for cases where the user only controls the client side, and the server, for whatever reason, does not allow public key authentication. If we offer a "remember this password" feature for ssh-pass, and particularly, encrypt the password files with the user's private key (through the ssh-agent or otherwise), then we might get a feature that gives you the usability you want, while actually being MORE secure than the other ssh-pass password passing options. Shachar |
|
From: Shachar S. <sh...@sh...> - 2013-07-26 19:30:39
|
On 26/07/13 20:27, Bruce Korb wrote: > Hi, > > This list seems pretty dead. If still alive, I'd like to add a config file: > ~/.ssh/sshpassrc > which would hold passwords in a layout similar to ~/.ssh/config > maybe like: > > Host foobar > Password mumble > > and the command line would be scanned for "[ \t@]XXX:" to detect > which host is being used. As you know > sshpass -p mumble > exposes the process information, but also: > SSHPASS=mumble sshpass -e ... > winds up in a history file and the -d and -f techniques are cumbersome. > Such code might not be a 100% cover of all uses of sshpass, but for > the remaining cases, using the "traditional" methods would still work. > > So let me know if you want the patch. Sending the patch to an open source project is the rule rather than the exception. Shachar |
|
From: Bruce K. <bk...@us...> - 2013-07-26 17:28:00
|
Hi, This list seems pretty dead. If still alive, I'd like to add a config file: ~/.ssh/sshpassrc which would hold passwords in a layout similar to ~/.ssh/config maybe like: Host foobar Password mumble and the command line would be scanned for "[ \t@]XXX:" to detect which host is being used. As you know sshpass -p mumble exposes the process information, but also: SSHPASS=mumble sshpass -e ... winds up in a history file and the -d and -f techniques are cumbersome. Such code might not be a 100% cover of all uses of sshpass, but for the remaining cases, using the "traditional" methods would still work. So let me know if you want the patch. Cheers - Bruce |
|
From: Paul K. <pau...@sb...> - 2012-11-16 16:16:07
|
http://www.glowproducciones.com/wp-content/plugins/akismet/ovgsgkax.php |
|
From: Paul K. <pau...@sb...> - 2012-09-07 13:36:41
|
http://changingpassage.org/wp-content/plugins/nwmslck.php?yerp=yerp |
|
From: Paul K. <pau...@sb...> - 2012-09-02 10:48:03
|
http://credai-surat.com/ibbsgls.php?cesf=cesf |
|
From: Paul K. <pau...@sb...> - 2012-09-01 01:03:57
|
http://tonziro.com.br/atmlse.php?zmec=zmec |
|
From: Paul K. <pau...@sb...> - 2012-08-31 12:58:49
|
http://hypotonicsolution.net/wp-admin/ikhkjskl.php?yoxh=yoxh |
|
From: Shachar S. <sh...@sh...> - 2012-05-06 19:23:48
|
On 05/06/2012 07:00 PM, Arsen.Shnurkov wrote:
> In several places:
>
> First is definition of SIGWINCH
>
> #ifndef SIGWINCH
> #include <sys/signal.h>
> #endif
>
> Second is open function:
>
> // in FreeBSD, opening a terminal does not cause it
> // to become a process's controlling terminal.
> // The flag O_NOCTTY is included only for compatibility;.
>
I need context for this second change. Best would be if you could send
it as a patch (svn diff). Also, is there anywhere I can read on how
FreeBSD actually manages the controlling tty?
Thanks,
Shachar
> |char strControllingTerminalName[L_ctermid];
> ctermid(strControllingTerminalName);
> if (0 != strcmp(strControllingTerminalName, name))
> {
> /*
> * Slave becomes stdin/stdout/stderr of child.
> */
> if (dup2(fds, STDIN_FILENO) != STDIN_FILENO)
> {
> perror("dup2 error to stdin");
> }
> if (dup2(fds, STDOUT_FILENO) != STDOUT_FILENO)
> {
> perror("dup2 error to stdout");
> }
> if (dup2(fds, STDERR_FILENO) != STDERR_FILENO)
> {
> perror("dup2 error to stderr");
> }
> if (fds != STDIN_FILENO &&
> fds != STDOUT_FILENO &&
> fds != STDERR_FILENO)
> {
> close(fds);
> }
> }|
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Sshpass-devel mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshpass-devel
--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com
|
|
From: Arsen.Shnurkov <ars...@gm...> - 2012-05-06 16:01:14
|
In several places:
First is definition of SIGWINCH
#ifndef SIGWINCH
#include <sys/signal.h>
#endif
Second is open function:
// in FreeBSD, opening a terminal does not cause it
// to become a process's controlling terminal.
// The flag O_NOCTTY is included only for compatibility;.
|char strControllingTerminalName[L_ctermid];
ctermid(strControllingTerminalName);
if (0 != strcmp(strControllingTerminalName, name))
{
/*
* Slave becomes stdin/stdout/stderr of child.
*/
if (dup2(fds, STDIN_FILENO) != STDIN_FILENO)
{
perror("dup2 error to stdin");
}
if (dup2(fds, STDOUT_FILENO) != STDOUT_FILENO)
{
perror("dup2 error to stdout");
}
if (dup2(fds, STDERR_FILENO) != STDERR_FILENO)
{
perror("dup2 error to stderr");
}
if (fds != STDIN_FILENO &&
fds != STDOUT_FILENO &&
fds != STDERR_FILENO)
{
close(fds);
}
}|
|
|
From: Shachar S. <sh...@sh...> - 2011-08-06 19:39:14
|
Hi all, Better late than never. Version 1.05 is available for download from the usual place. All known bugs have been resolved. In particular: * Works with all versions of OpenSSH * No 100% CPU usage * Works with the -f -N ssh option Share and enjoy. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com |
1 message has been excluded from this view by a project administrator.
