Creating Secure Tunnels With ssh
If you manage remote servers or if you have more than one computer you most likely have used the ssh command. A simple description of ssh is that it's a secure version of telnet, but that's like saying a Porsche is a just a better version of a Volkswagen bug.
Amoung other things, the ssh command allows you to setup secure tunnels to remote computers. One example of creating a tunnel that I use often is to use phpmyadmin to look at the database on a remote server without having to have phpmyadmin actually installed on the remote server.
To do this I simply install phpmyadmin on my local system then I use ssh to create a tunnel to the server that I want to interact with. This means I don't have to have phpmyadmin installed remotely and I don't have to maintain multiple phpmyadmin installations if I manage more than one server.
Now of course, mysql is network capable to begin with so it's also possible to just setup phpmyadmin on your local system to talk directly to mysql on the remote server. However, for security reasons you may not want to have mysql listening directly on a public interface: have it listen on localhost but not on the internet.
The essence of this type of tunnel is to start ssh and tell it to listen on a local TCP/IP port and to have it forward any traffic that it sees on that port to a particular port on the remote side. The normal mysql port is 3306, so what you can do is tell ssh to listen on port 3308 on your local computer and forward that to port 3306 on the remote side.
For example, if the remote server in question was myserver.example.com you could run the following command on your local system to create a tunnel as described above:
ssh -T -N -L 3308:localhost:3306 myserver.example.com
The meat of the command is the -L option, which tells ssh to listen on port 3308 locally and then on the remote side to forward all traffic on that port to localhost:3306. Note that the localhost here is not referring to the local system but rather where to forward things to on the remote side, in this case to localhost on the remote side.
The -T command disables allocation of a tty and the -N command disables the running of a command (eg your login shell) on the remote side. This means that this instance of ssh won't act like a terminal, it's just for port forwarding.
You can test the tunnel using the command line interface to mysql on your local system. You may need to specify the host name or address in the command:
$ mysql -P 3308 -u USERNAME -pPASSWORD DATABASE # OR $ mysql -h localhost -P 3308 -u USERNAME -pPASSWORD DATABASE # OR $ mysql -h 127.0.0.1 -P 3308 -u USERNAME -pPASSWORD DATABASE
This type of tunneling capability only represents some of what you can do with ssh tunneling. For example, suppose myserver.example.com were actually a firewall that protected, amoung others, the system private.local. The system private.local is accessible from myserver.example.com but not from the internet directly. So, now you could run:
ssh -T -N -L 3308:private.local:3306 myserver.example.com
Here, ssh listens on port 3308 on the local system and it forwards that data to port 3306 on private.host, but it does that via the server myserver.example.com. In other words the local traffic on port 3308 gets transferred first to the remote system which then transfers it to port 3306 on private.host. Of course, if private.local's mysql server is only listening on its local interface this won't work, you'll need something more involved.
Another type of tunneling you can do is to reverse the tunnel: rather than using -L you can specify -R so that the listen side of the tunnel is on the remote side rather than on the local side. For example, suppose phpmyadmin was installed on myserver.example.com and you wanted to allow somebody using that phpmyadmin installation to connect to the mysql instance running on your local system. Just substitute -R for -L in the first ssh command above:
ssh -T -N -R 3308:localhost:3306 myserver.example.com
Here the remote ssh listens on port 3308 of myserver.example.com and then forwards traffic on that connection to port 3306 on your local system. Note that by default ssh is only listening on the localhost interface of the remote system so if the remote phpmyadmin install is secure your local system will also be secure. Remember that you still run this ssh command from your local system, you don't run it from the server (and unless your system is routable you probably couldn't successfully execute it on the remote system anyway).
To test the connection, on the remote system execute the command line mysql client using the same commands as we used above. This should connect to the database on your local computer. Again the configuration of phpmyadmin is left as an exercise.
Mitch Frazier is an Associate Editor for Linux Journal.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide