tony.chamberlain@xxxxxxxxx wrote:
The following is for CentOS 4.5
...
which gets me into my machine. Test passes. Problem is, by
the time I get home, my ssh -l root -R 10022:127.0.0.1:22 10.20.30.40
has timed out
...
This is what autossh is for. Previous advice is good about settings,
and here is why, and a complete solution:
The ssh server process by default controls the connection process. It
determines longevity and termination requirements. As said, this is the
default behavior.
You can modify the CLIENT to control the connection instead. The client
can demand longer timeouts, and it can ask for a periodic 'check' to see
if its still connected. These are the settings mentioned in the
previous messages.
But that may not be enough, especially when tunneling. autossh is
specifically designed to 'enhance' the process of tunneling. One thing
that can be easily managed with autossh is a tunnel to a port on
localhost of the server, thus avoiding port scanners and other
unauthorized intrusions.
Here is how we do it, top to bottom:
Our objective was to provide ssh access to any remote server, on a truck
via Cell card, or a fixed location via phone or private LAN.
A corporate server needs a sshd running to be the intermediary in this
example. The corporate server need to expose a port for the ssh daemon
-- does not need to be 22, but we will assume 22 for this example.
Create a rsh key and make sure that the account on the client and the
account on the corp server to be used, share the same authorized_keys
The account on the corp server can be locked, but the ssh key needs to
be available.
On the remote system:
edit /etc/ssh/ssh_config and add these two lines:
ServerAliveCountMax 10
ServerAliveInterval 30
start a tunnel to the corp server -- we made a startup script:
/etc/init.d/autossh
autossh -M 0 -f user@xxxxxxxxxxxxxx -R 2222:localhost:22 -nN
This starts a tunnel on the corpserver listening on port 2222 of the
localhost interface. The combination of the client settings and autossh
will keep this connection alive as long as the client is up. We use a
different port number for each remote client. Since the ports appear
only on localhost, they cannot be port scanned from the outside.
On my desktop inside the firewall, I perform this to establish a tunnel
to the client for myself:
autossh -M 0 -f user@xxxxxxxxxxxxxx -L 2222:localhost:2222 -nN
This establishes a tunnel from my localhost to the server localhost.
This tunnel will remain connected as long as both systems are up, or
until I manually take it down by killing autossh.
Now to connect to the remote system, I simply do:
ssh -p 2222 localhost
or
scp -P 2222 myfile localhost:/wherever
works like a champ. The key to automating it all is to share common ssh
keys. You can certainly do it manually without them.
Good Luck!
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
