#Mysql command line ssh tunnel to remote server software
If the command is run manually, the software invoked will run in the background and the terminal can be closed. “ServerAliveCountMax 3” -L 4002:localhost:3306 we’ve executed that, we will have established port 4002 on the client and it will be connected to port 3306 on the server. You would execute something like this from the command-line: su - tunnel -c ‘autossh -M 0 -q -f -N -o “ServerAliveInterval 60” -o For Centos/Red Hat, it could go in the /etc/rc.local directory. In a Debian based installation, probably the best place to put the command to establish the tunnel is the directory, /etc/network/if-up.d. We’re now ready to establish the SSH tunnel. Once you’ve done that, autossh can be installed using the standard package management tools for the distribution (e.g., aptitude or yum). You can find it in the standard repositories for Debian and Ubuntu or may need to add one of the well known additional repositories for other distributions. This monitors an SSH tunnel and re-establishes it if it fails. To make the SSH tunnel robust, it’s helpful to run a utility called autossh. If it connects successfully, you have proved that the tunnel user can make a connection to the server. After this first time, you won’t get this message. Just confirm that you want to go ahead with the connection. We would do that by executing this from the command-line: ssh first time you do this, there should be a message that says that it is an unknown server. Once the keys have been created and put where they belong, we should be able to log into the server with the tunnel user from the client, without having to enter a password. Just put what you paste on a separate line in that file. You could also use a simple text editor to copy the contents of the id_dsa.pub file to the end of the authorized_keys file. If not, you can append it to the end of the file by executing something like this at the command-line from the directory where you’ve uploaded the id_dsa.pub file: cat id_dsa.pub > /home/tunnel/.ssh/authorized_keys Assuming this is the first key to be used on the server system for the tunnel user, the id_dsa.pub file can be copied into the server directory /home/tunnel/.ssh and renamed to authorized_keys. It needs to go into the file called, /home/tunnel/.ssh/authorized_keys.
Now we need to place a copy of the public key on to the server system. The second file is the public key, which can be distributed freely. The first is the secret key, which should be kept secure. The result will be two files in the /home/tunnel/.ssh directory called id_dsa and id_dsa.pub. It will also ask for a password, but this isn’t needed. When you execute the ssh-keygen command, it will offer to create the keys in the /home/tunnel/.ssh directory. The comment will be added to the end of the public key, and is useful for keeping track of what key belongs to what system. The last parameter, indicated by -C is purely a comment and doesn’t affect the use of the keys. This can be done by executing the ssh-keygen utility while logged in as the tunnel user like so: ssh-keygen -t DSA -b 1024 -C example uses DSA, although you could use RSA. The user on the client side will need to create SSH keys. They shouldn’t have any special privileges, but they need to have a home directory (assumed to be /home/tunnel) and the ability to run a command shell. We’ll assume we’ve done that and called them simply, tunnel on both. It’s useful to establish dedicated users on each machine. $IPTABLES -A OUTPUT -d $IP_SERVER -p tcp -dport 22 -m state -state NEW -j ACCEPT # Accept inbound packets that are part of previously-OK’ed sessions On the client side, the iptables script might include the following entries: IP_SERVER=1.2.3.4 $IPTABLES -A INPUT -s $IP_CLIENT -p tcp -j ACCEPT -dport 22 -m state -state NEW $IPTABLES -A INPUT -m state -state RELATED,ESTABLISHED -j ACCEPT So the iptables script on the server might contain something like this: IP_CLIENT=5.6.7.8 The tunnel will be instigated by the client. Let’s use the standard port for SSH (i.e., port 22). The first step is to open the firewall for SSH communications between the systems. We’ll also suppose that there are tightly configured iptables firewalls on both systems. Suppose further that the client is on a host named,, with an IP address of 5.6.7.8. For the examples here, let’s assume that there is a database server running on a host named,, with an IP address of 1.2.3.4. This article suggests a simple approach which is adequate in many situations. There are various ways to implement an SSH tunnel. Traffic through an SSH tunnel is encrypted with all of the security of the SSH protocol, which has a strong track record against attacks. Although SSL often may seem to be the best option, SSH tunnels are in fact easier to implement and can be very effective. When you want to connect a client to a database server through an insecure network, there are two main choices: use SSL or use an SSH tunnel.
0 kommentar(er)
