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.
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.
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.
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?
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.