Cant get responsive terminal when I ssh from Windows to Linux using putty.exe

I ssh from Windows to Linux server and execute a few commands. I have ssh keys setup between them and works fine.

The commands get executed on the Linux server however I wish to stay on the Linux terminal that was opened by putty.exe. However, the terminal simply does the job and closes.

Here is the command I run on Windows:

C:\putty\putty.exe -ssh -i "C:\putty\my_id_rsa_putty.ppk" myuser@10.8.66.126 -m "C:\putty\ssh_commands.txt"

Here is my "C:\putty\ssh_commands.txt"

cd /app/axmw/sftp; 
sshpass -p mypass sftp myuser@10.9.88.195; cd Moht; get *; quit; exit
/bin/bash

The job is done and the script gets executed fine on the target Linux, however the Linux terminal gets launch but hangs and is unresponsive.

I need it to be interactive with any shell [bash, sh, ksh] which is not the case.

If i append "-t"at the end of this command like below:

C:\putty\putty.exe -ssh -i "C:\putty\my_id_rsa_putty.ppk" myuser@10.8.66.126 -m "C:\putty\ssh_commands.txt" -t

Then it gives me interactive shell however it takes me inside the sftp terminal prompt and the commands do not get executed.

How can I get my commands executed and end up landing on interactive bash or any shell on the target Linux ?

Two ideas off the cuff that can't be tested as there's no windows machine within reach:

• run the ssh_commands.txt from within your shell's rc / login file, possibly after a plausibility check
• run / exec your shell at the end of ssh_commands.txt . I see it in your file, but are you sure execution gets to it? The exit in the line before might close the session but leave the teminal window open and unresponsive.

Removed the "-t" argument
Removed the exit from ssh_commands.txt

Ran the C:\putty\putty.exe -ssh -i "C:\putty\my_id_rsa_putty.ppk" myuser@10.8.66.126 -m "C:\putty\ssh_commands.txt"

All good and done however this leaves me with an interactive terminal on sftp prompt instead of a shell.

Same is observed when running ssh_commands.txt directly on Linux host

Kindly suggest.

Hmm. Deleted my response - not helpful.

Post an xtrace of your session, and, upfront, read comments utmost carefully.

Is the exit in your file executed? By which entity (sftp? shell?)?

Don't know how to get the xtrace in windows. By the way i modified ssh_commands.txt to debug and i came to the conclusion that "-t" is necessary to us to get the interactive terminal.

The issue with ssh_commands.txt is:

cd /app/axmw/sftp;    <--- success
touch insidesftp.txt;   <--- success
sshpass -p mypass sftp myuser@10.9.88.195; cd Moht; get *; quit;    <--- Fails (only the first statement gets executed sshpass -p mypass sftp myuser@10.9.88.195; hence i land up on sftp prompt. All the successive commands do not even get executed)
/bin/bash     <--- does not get executed.

Thus, we need to know how to pass each sftp command to be executed.

The way I read your script I don't think we were talking about xtracing in windows. Set it in your script.

Of course, they don't - the sftp command ends with the first semicolon. It expects commands on stdin if having entered "interactive command mode". Did you consider the -b batchfile option?

Of course not - you're exit ing the script before reaching this statement (in your first post's script, that is)

@Rudic I tried using the -b option of sftp but it is still failing.

I changed by ssh_commands.txt as below:

cd /app/sftp;    <--- success
touch insidesftp.txt;   <--- success
echo "cd Moht;" >execmd.txt  <--- success
echo "get *;" >>execmd.txt  <--- success
echo "quit;" >>execmd.txt   <--- success
sshpass -p mypass -b execmd.txt sftp myuser@10.9.88.195;   <--- Fails (Although the command executes on remote Linux host I get an error in output)
touch sftpcompleted.txt    <--- success

Below is the error received:

EFT Server Enterprise 7.3.2.8Permission denied (password,keyboard-interactive).
Couldn't read packet: Connection reset by peer

However, when i fire the command manualy one by one this works fine. See output of Manual steps.

sshpass -p mypass sftp myuser@10.9.88.195
EFT Server Enterprise 7.3.2.8Connected to 10.9.88.195.
sftp> cd Moht
sftp> get *
Fetching /Moht/Jenkins_v1.0.docx to Jenkins_v1.0.docx
sftp> quit
[me_user@myremotelinuxhost sftp]$ 

Also the terminal closes instead of getting me the shell prompt.

Same point? Same error?

Sounds like a "permission denied" error (to me). Are you sure about the users including their respective permissions and the applications / programs / commands (putty, ssh, sftp) on ALL THREE sides (windowsuser@windowssystem, myuser@10.8.66.126, myuser@10.9.88.195) of your experiment? Where do the scripts reside?

How about trying

sshpass -p mypass -b execmd.txt sftp myuser@10.9.88.195

in manual steps?

That's why you need to run / exec your shell after having closed the sftp connection.

@Rudic

$ cat getcmd.txt 
cd Moht
get *
quit

We have come to a point that this has nothing to do with windows as all issues have been addressed with your help / inputs.

The current issue i wish to deal with is when i fire the below command manually on target Linux host i get the below error:

sshpass  -p mypass sftp -b getcmd.txt myuser@10.9.88.195
EFT Server Enterprise 7.3.2.8Permission denied (password,keyboard-interactive).
Couldn't read packet: Connection reset by peer

However; removing the -b parameter resolves the issue in a way that I'm able to login to sftp and then i can fire the commands in getcmd.txt one by one manually successfully on sftp prompt like below.

$ sshpass  -p mypass sftp myuser@10.9.88.195
EFT Server Enterprise 7.3.2.8Connected to 10.9.88.195.
sftp> cd Moht
sftp> get *
Fetching /Moht/Jenkins_v1.0.docx to Jenkins_v1.0.docx
sftp> quit
[ sftp]$ 

For some reason it is not liking the -b option. I have made sure that getcmd.txt file has 775 file permission.

Can you please suggest ?

sftp 's -b option doesn't seem to cooperate well with sshpass , which in itself is a security risk. Comments on the net: Never Use on Production Server, Users of sshpass are encouraged to use one of the other password passing techniques, which are all more secure.

man sshpass :

• doesn't sound too secure, does it?

So - all that boils down to: Consider non-interactive, passwordless authentication.

Did you read my other comments?