Discussion:
How to close a SSH connection from a BAT file
Anthony de Sousa
2007-08-01 04:44:32 UTC
Permalink
I am hoping that someone may be able to advise as to whether the following is
possible. I have a server running SSH as a service (SRVA) and another server
(SRVB) which runs the SSH client and port forwards port 139. On SRVB I have
an existing BAT file that I wish to wrap the port forwarding around so that
port 139 goes through port 22. This all works except that I also wand to drop
the SSH connection after the BAT file has finished what it needs to do. Is
this possible as I am finding that I end up with two command windows with one
still running the SSH connection. The simple BAT that I initiate is as follows:

@echo off
cd c:\dirb
rem the following line starts the existing bat file in a seperate window
Start run1.bat
rem
cd c:\cygwin\bin
bash -c "(ssh -N -L 10.0.0.1:139:20.250.205.96:139 ***@srvb)"



As stated this all works and the output of run1.bat is transferred to SRVB
however I would like the connection dropped and the window terminated.

Thanking you in advance

Tony
Brian Dessent
2007-08-01 05:18:02 UTC
Permalink
Post by Anthony de Sousa
I am hoping that someone may be able to advise as to whether the following is
possible. I have a server running SSH as a service (SRVA) and another server
(SRVB) which runs the SSH client and port forwards port 139. On SRVB I have
an existing BAT file that I wish to wrap the port forwarding around so that
port 139 goes through port 22. This all works except that I also wand to drop
the SSH connection after the BAT file has finished what it needs to do. Is
this possible as I am finding that I end up with two command windows with one
@echo off
cd c:\dirb
rem the following line starts the existing bat file in a seperate window
Start run1.bat
rem
cd c:\cygwin\bin
As stated this all works and the output of run1.bat is transferred to SRVB
however I would like the connection dropped and the window terminated.
The best way is to run the ssh command as a service using cygrunsrv.
Then your batch file amounts to:

@echo off
net start sshtunnelservicename
run1.bat
net stop sshtunnelservicename

Failing that you can record the PID and use it to kill the ssh process
later:

@echo off
setsid sh -c 'echo $$ >/var/run/ssh.pid; exec ssh -N -L
10.0.0.1:139:20.250.205.96:139 ***@srvb'
run1.bat
sh -c 'kill -INT $(cat /var/run/ssh.pid)'

(This assumes you have the Cygwin bin directory in the PATH, if you
don't then just use absolute paths to setsid and bash.)

Also, if you only want the one command window I don't see why you are
doing "start run1.bat". You don't need to use start, just call run1.bat
from the other batch file and when it's done stop the ssh process.

Brian
Anthony de Sousa
2007-08-03 06:43:14 UTC
Permalink
Brian Thanks for the suggestions and I was extreemly interested in trying your
suggestion of running the SSH client as a service. However I have not been
successful in setting it up. Although it does install as a service, when it is
started it immediatly stops as unable to authenticate with the other server.
If SSH is run manually there is no issue. Currently going through the logs
with verbose on and trying to determine what the issue is.
Brian Dessent
2007-08-03 16:22:04 UTC
Permalink
Post by Anthony de Sousa
Brian Thanks for the suggestions and I was extreemly interested in trying your
suggestion of running the SSH client as a service. However I have not been
successful in setting it up. Although it does install as a service, when it is
started it immediatly stops as unable to authenticate with the other server.
If SSH is run manually there is no issue. Currently going through the logs
with verbose on and trying to determine what the issue is.
If you don't provide --user to cygrunsrv it runs the service as the
system account. You probably need to run it as your regular user
account, so that your public keys in $HOME/.ssh/ are found, et cetera.
I'm assuming you're using pubkey auth here, as password auth would
present a problem for an automated service.

Brian
Andrew Schulman
2007-08-03 16:56:11 UTC
Permalink
Post by Anthony de Sousa
Brian Thanks for the suggestions and I was extreemly interested in trying your
suggestion of running the SSH client as a service. However I have not been
successful in setting it up. Although it does install as a service, when it is
started it immediatly stops as unable to authenticate with the other server.
If SSH is run manually there is no issue. Currently going through the logs
with verbose on and trying to determine what the issue is.
As Brian suggests, in order to run an ssh client as a service you have to
give it enough information to authenticate unattended to the server. That
means you have to give the client one of the following:

- a plaintext password
- an unencrypted (i.e. empty password) private key file
- a running ssh-agent that holds the private key

Whatever method you use to authenticate when you login manually, it will
probably be simplest to give that same information to your ssh client when
it runs unattended.

All of the above methods carry potential security risks, but the risks can
be minimized by, for example, using an account with shell access disabled on
the remote host. For a full discussion of the unattended login problem, see
chapter 11 of "SSH, The Secure Shell: The Definitive Guide", 2nd ed., by R.
Silverman and D. Barrett.

A.
Anthony de Sousa
2007-08-06 06:07:58 UTC
Permalink
Post by Andrew Schulman
Post by Anthony de Sousa
Brian Thanks for the suggestions and I was extreemly interested in trying your
suggestion of running the SSH client as a service. However I have not been
successful in setting it up. Although it does install as a service, when it is
started it immediatly stops as unable to authenticate with the other server.
If SSH is run manually there is no issue. Currently going through the logs
with verbose on and trying to determine what the issue is.
As Brian suggests, in order to run an ssh client as a service you have to
give it enough information to authenticate unattended to the server. That
- a plaintext password
- an unencrypted (i.e. empty password) private key file
- a running ssh-agent that holds the private key
Whatever method you use to authenticate when you login manually, it will
probably be simplest to give that same information to your ssh client when
it runs unattended.
All of the above methods carry potential security risks, but the risks can
be minimized by, for example, using an account with shell access disabled on
the remote host. For a full discussion of the unattended login problem, see
chapter 11 of "SSH, The Secure Shell: The Definitive Guide", 2nd ed., by R.
Silverman and D. Barrett.
A.
Brian and Andrew thank you for the wealth of information. Brian hit it on the
head in that the service account was being used and the keys weren't being
found. I have fixed this and the service now start with the net start ssh or
the cyrunsrv S ssh commands. The stop also appears to work in that the service
stops, but what I am finding is the process continues to run (appears in the
task manager list)and the next time that net start ssh is issued the following
errors are in the log
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 139
Could not request local forwarding.
Cannot bind until the processes are killed also noted, is if I don't kill the
process and just issue another net start ssh, then the number of processes
will continue to increase.
I hope there is a easy way around this as the solution originally provided
offers minimal impact to an existing application. Many thanks again
Anthony de Sousa
2007-08-21 01:18:33 UTC
Permalink
I would like to conclude that we have decided to use AUTOSSH to control ssh.
With autossh the processes are stoped automatically whenever autossh is
stoped. As Brian originally suggested all that is then required on either side
of the bat file is a Net Start Autossh and a Net Stop Autossh. Many Thanks
Sylvain Richard
2007-08-21 06:24:07 UTC
Permalink
Post by Anthony de Sousa
the next time that net start ssh is issued the following
errors are in the log
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 139
Could not request local forwarding
Re your port 139 problem, see:

http://www.blisstonia.com/eolson/notes/smboverssh.php


You can check that port 139 is owned by your ssh client by using:
netstat -ano
tasklist /svc
or (more easily):
netstat -abn

Some webpages suggest stopping the "server" process but then you'd lose
the shares hosted by your client machines.

Best of luck

Sylvain

Loading...