Chapter 1: Is an overview of the Linux.
Be sure to pay special attention to the keywords at the end of each chapter and the review questions.
Chapter 2: Covers the hardware required to support Linux.
Chapter 3: This reviews the install of Linux.
The instructor, during the start of the course, will provide server information.
For this course, we have already installed Linux on the server, but this is an important part of Linux.
The install covered in the 2nd edition of this book is valid for Fedora before 10.
We are using Fedora 14 and the install process has changed a lot, but the basic process is very similar.
The additional course web links above have links to a number of good sites that review the install process.
We did a number of steps during the install to get the system to the stage where you can login.
Chapter 4: Exploring the Linux File System
We want to complete the following things:
|Using PuttySSH to login into your server.|
|Using vi and nano|
What is sudoers?
Switch to the root user:$ su
Change the permissions on /etc/sudoers so it can be modified:# chmod u+w /etc/sudoers
Edit the /etc/sudoers file with either 'vi' or 'nano':# nano /etc/sudoers
Enter the following at the end of the file (where 'ACCOUNT_NAME' is the name of the user account you want to be able to use the 'sudo' command):ACCOUNT_NAME ALL=(ALL) ALL
Save and exit
Change the permissions on /etc/sudoers back its original settings (otherwise the 'sudo' command won't work):# chmod u-w /etc/sudoers
Test the 'sudo' command by exiting the root account and reading the last 30 lines of one of the system logs:# exit
Create the following file, you can use 'vi' or 'nano':$ sudo nano /etc/ssh/ssh_allowed_users
The contents of this file should be the names of user accounts, each on its own line.
Edit the PAM (Pluggable Authentication Module) file for the SSH daemon to use our list of allowed accounts:$ sudo nano /etc/pam.d/sshd
Add the following to the top of the file (should be the first line after "#%PAM-1.0"):auth required pam_listfile.so sense=allow item=user file=/etc/ssh/ssh_allowed_users onerr=fail
Save and exit
Restart the SSH daemon:$ sudo service sshd restart
To update your system via the command line:$ sudo yum update
To update your system via YUMEX (graphical interface):$ sudo yum install yumex
First you have to install the Sendmail Configuration File package via 'yum':$ sudo yum install sendmail-cf
Next, we edit the configuration file for sendmail using either 'vi' or 'nano':$ sudo nano /etc/mail/sendmail.mc
Change the following line:dnl define(`SMART_HOST',`smtp.your.provider')dnl
And change this line:DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
To this:dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
Save and exit
Next we have to 'make' the changes:$ sudo make -C /etc/mail
Restart the sendmail daemon:$ service sendmail restart
Edit the /etc/aliases file to setup email forwarding:$ sudo nano /etc/aliases
Add the aliases to the end of the file in the following format. Please note that while 'USER_ACCOUNT' is the actual name of the user account, 'GROUP_ALIAS' does not have to correspond to a system group, just a group of email aliases (Note that for group aliases, multiple account aliases must be separated by a comma with NO SPACES in between):# Local Aliases
The entry for the root user account is commented out:# Person who should get root's mail
Uncomment the line (remove the #) and replace 'marc' with either an account alias, a list of account aliases, or a group aliases:root: GROUP_ALIAS1
Save and exit
Commit the changes to the /etc/aliases file:$ sudo newaliases
Send an email to the root account from the command line (to end the message, put a sole period on a line and hit Enter):mail root
Install the Logwatch package via 'yum':$ sudo yum install logwatch
You will now get all system e-mails including the nightly logs. It is your responsibility to read these daily messages and monitor activity on your system.
Note: If your server requires a password to authenticate against a network mailserver the following web site gives some examples of how to setup your system for use on the Verizon network.
Chapter 5: Filesystem Management
Be sure to pay special attention the file permission system and how you use the chmod command.
Chapter 6: Filesystem Admin
If you plan on taking the cert, be sure to read this chapter.
Chapter 7: Adv Installation
If you plan on taking the cert, be sure to read this chapter.
Chapter 8: More Bash Shell
This chapter goes beyond the basics we did earlier in the semester. The ability to pipe and redirect is essential in using the command line.
Chapter 9: System Ini and X Windows
If you plan on taking the cert, be sure to read this first half of the chapter. Be sure to review the X windows system section. We will be using the GNOME desktop.
Chapter 10: Managing Linux Processes
UNIX is a multi processing system, which allows it to run more than one process at a time. This chapter discusses how to manage and control processes. Be sure to review run levels and managing processes.
Fedora uses what is called IPTABLES to control the firewall on your server. IPTABLES is a rules file that tells the OS which ports should be open and how and who should have access to them. We will be doing the basic setup for Assignment 2. IPTABLES provides a many ways to configure your server to provide protection from outside attacks. One of the best ways to protect your server is to only open ports that you are using and to control access as required. This is in addition to only running software that accesses these ports as required.
Since, we have not enabled remote desktop access yet (assignment 3), we will edit the iptables file by hand using vi or another command line editor. IPTABLES is already installed on your server as the basic install package. You will need to open up ports 80 (http) and 443 (https) to allow the apache server, that we have not started yet, to talk to the outside world via these ports. As discussed in the defition above, a port can be thought of as a conduit between the outside network and software running on your server. While port 80 is the default for web services (and 443 the default for encrypted web services), you can run a web server on any port you want to define depending on conditions you find your server operating in.
Edit /etc/sysconfig/iptables:$ sudo nano /etc/sysconfig/iptables
Enter the folling rules before the last three lines:-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
You can add other rules for other services later if needed. If you would like to see a list of standard ports, you can 'cat /etc/services' to view them.
Save and exit
Restart the iptables service, so that it reads in the new settings you have created.$ sudo service iptables restart
If this work correctly, you will get the following OKs back. If you get an error message, then go back and look at the file to see if you made a mistake in the edit
iptables: Flushing firewall rules: [ OK ] iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Unloading modules: [ OK ] iptables: Applying firewall rules: [ OK ]
You have now opened up ports 80 and 443. There is way using the GUI to control these ports, but learning to work on the file directly allows you to use SSH to open a session to your server from just about anywhere (like from my iphone now) to be able to control access.
First, lets check to make sure that httpd is installed:$ rpm -qa httpd
If nothing outputs from this command, the package is not installed, otherwise it will display the complete name (including version information) of the installed package. If the package needs to be installed, simply run:$ sudo yum install httpd
You should see the following:httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
These are the various runlevels and the status of the daemon when the computer is booted into these runlevels: runlevel 1 is single-user mode (usually a recovery mode), runlevel 3 is a text-only mode (what a lot of servers run in), and runlevel 5 is a graphical mode (what a desktop computer would normally run).
To make the Apache daemon start at boot, run:$ sudo chkconfig httpd on
You can verify the status change with:$ chkconfig --list | grep httpd
You should now see the updated run states:httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Start the Apache daemon:$sudo service httpd start
The command should have output:
Starting httpd: [ OK ]
As a further check, lets look at the process table and see if the Apache daemon is running:$ ps aux | grep httpd
You should see something similar to the following:
root 17960 1 0 15:14 ? 00:00:00 /usr/sbin/httpd apache 17962 17960 0 15:14 ? 00:00:00 /usr/sbin/httpd apache 17963 17960 0 15:14 ? 00:00:00 /usr/sbin/httpd apache 17964 17960 0 15:14 ? 00:00:00 /usr/sbin/httpd apache 17965 17960 0 15:14 ? 00:00:00 /usr/sbin/httpd apache 17966 17960 0 15:14 ? 00:00:00 /usr/sbin/httpd apache 17967 17960 0 15:14 ? 00:00:00 /usr/sbin/httpd apache 17968 17960 0 15:14 ? 00:00:00 /usr/sbin/httpd apache 17969 17960 0 15:14 ? 00:00:00 /usr/sbin/httpd
You have now set httpd to autostart on server reset and have started the web server. It should display the default web page if you go to your server.
Using a browser, enter http://yourserverdomainname
If it does not, then you need to check iptables again (did you enter the right enter and did you restart it) and check httpd (did you start it).
It is now time to upload a web site (or pages) to replace the default page just seen
Using whatever web authoring package you like, create a home page for your site. Please create a motif/layout that goes with the name of your system. NOTE: Apache uses index.html as the default startup web page, so make sure your first page in any new web directory is called index.html. We will talk more about how to configure httpd.conf in a bit, when we setup user web areas.
You will need to make sure you have the proper permissions to load files into this directory, since the default owner and group is 'root'. You should change the group of the web directory to 'apache', add the appropriate user accounts to the 'apache' group (where USER_ACCOUNT is the actual user account), and give the group the appropriate permissions and restart the webserver:$ sudo chgrp -R apache /var/www/html
Using WINSCP upload the new web content to the default web area of /var/www/html.
Using your browser check your new home page. Congrats! You now have a working web server.
You now have a server web area. Apache supports the ability to setup user web areas that reside under the user's account. This is handy in several cases. One of the main reasons is that users are then responsble for their own content and you do not have to allow user access to your web directory (/var/www/html) for security issues. Keep in mind, there are some downsides, so the choice of enabling this or not depends on your server needs. We will enable it on your server as a further use of Apache.
The first is to edit the httpd configuration file: /etc/httpd/conf/httpd.conf is a very complex settings file. It controls everything to do with the Apache daemon. It would be well advised to make a copy of this file as a backup before you start editing.
To this:#UserDir disable
And right below it is this:#UserDir public_html
Should be changed to this:UserDir public_html
You should receive the following output. If you get a status of 'FAILED' on restarting the daemon, then you have an error in your httpd.conf file. Either try to find it or copy back the backup and start the edit again. Mistakes in editing httpd.conf are very unforgiving.
Stopping httpd: [ OK ] Starting httpd: [ OK ]
We have a number of steps now to create a user's public_html area and the open it for outside viewing. This is the more complex part of the process and any problem in this chain can cause a failure notice when you try to access the user web area.
Each student will have to perform the following from their home directory (/home/USER_ACCONT):$ mkdir public_html
The last two commands will allow Apache to view the contents of the users' public_html directory with SELinux enabled.
Upload or create (via 'vi' or 'nano') a test file into the public_html directory to test the following steps:$ nano public_html/index.html
The file should contain the following:<html>
Save and exit.
View your HTML file by opening a web browser and going to:http://SERVER_NAME.lt.unt.edu/~USER_ACCOUNT
If you don't get the test page, then you missed or made a mistake in one of the above steps. Go back and review.
It is now time to upload a web site (or pages) for the empty user home page
Using whatever web authoring package you like, create a home page for your user site. Be sure to put your name, photo, and a bio about yourself on the personal page. Also, be sure to provide a link on your system home page to your personal web site. NOTE: Apache uses index.html as the default startup web page, so make sure your first page in any new web directory is called index.html.
Uising WINSCP, each student should upload the new web content to their public_html directory.
Using your browser check your new home page:http://SERVER_NAME.lt.unt.edu/~USER_ACCOUNT
Many webservers serve more than one domain per each installation. The way they are able to do this is by configuring Apache to serve Virtual Hosts, one Virtual Host per domain.
We'll first need to define our Virtual Hosts. This can be done in the main Apache configuration file (/etc/httpd/conf/httpd.conf), though in my experience it's easier to have a separate file for this. We first create the file:$ sudo nano /etc/httpd/conf.d/vhosts.conf
The first line in the file needs to enable Name-based Virtual Hosting:NameVirtualHost *:80
The '*:80' tells Apache that it will serve Name-based Virtual Hosting on all IPs on the server on port 80.
Each site needs its own Virtual Host section. It's usually a good idea to have the first entry be the IP address of the server with its own directory. Each site should have its own directory under the web root (/var/www/html). In this example, the FQDNs for the sites hosted from this server are 'pegasus.lt.unt.edu', and 'pegasus-vh.lt.unt.edu':
NameVirtualHost *:80 <VirtualHost *:80> ServerName 126.96.36.199 DocumentRoot /var/www/html/default </VirtualHost> <VirtualHost *:80> ServerName pegasus.lt.unt.edu DocumentRoot /var/www/html/pegasus.lt.unt.edu ErrorLog logs/pegasus.lt.unt.edu_error-log CustomLog logs/pegasus.lt.unt.edu_access-log common </VirtualHost> <VirtualHost *:80> ServerName pegasus-vh.lt.unt.edu DocumentRoot /var/www/html/pegasus-vh.lt.unt.edu ErrorLog logs/pegasus-vh.lt.unt.edu_error-log CustomLog logs/pegasus-vh.lt.unt.edu_access-log common </VirtualHost>
Save and exit
If you had a site with multiple FQDNs associated with it, you could use the 'ServerAlias' directive to associate them with a host like so:
<VirtualHost *:80> ServerName pegasus.lt.unt.edu ServerAlias www.pegasus.lt.unt.edu pegasus.learningtechnologies.unt.edu DocumentRoot /var/www/html/pegasus.lt.unt.edu ErrorLog logs/pegasus.lt.unt.edu_error-log CustomLog logs/pegasus.lt.unt.edu_access-log common </VirtualHost>
Please note that the above is just an example, and for this course you will only be assigned two FQDNs for your server.
Create the directories for your Virtual Hosts that you defined in the /etc/httpd/conf.d/vhosts.conf file:$ sudo mkdir /var/www/html/default/ /var/www/html/pegasus.lt.unt.edu/ /var/www/html/pegasus-vh.lt.unt.edu/
Create a test HTML file forea each Virtual Host:$ sudo nano /var/www/html/default/index.html
Restart the Apache daemon:$ sudo service httpd restart
Open your web browser and go to your server's IP and both FQDNs and make sure you see the correct corresponding test pages.
Encrypted web traffic is essential for passing sensitive information over the web. For part of this assignment you will be required to enable encryption via SSL with Apache. The method used in this class takes advantage of an extension to the SSL (Secure Socket Layer) and TLS (Transport Layer Security) protocols called SNI (Server Name Indication). Before this a server could only serve one certificate per IP & port combination, but now we can use TLS with virtual hosting. You can read more about this here.
You first need to install the SSL module that Apache will use to establish encrypted connections:$sudo yum install mod_ssl
Next, you have to generate a Certificate Signing Request. This uses your server's public RSA key as well as some identifying information which will be sent to a Certificate Authority to create the certifcate. Make sure to replace 'pegasus_lt_unt_edu' with the name of your server.$ sudo openssl req -new -newkey rsa:2048 -nodes -out pegasus_lt_unt_edu.csr -keyout pegasus_lt_unt_edu.key -subj "/C=US/ST=TEXAS/L=Denton/O=University of North Texas/OU=Learning Technologies/CN=*.lt.unt.edu"
This will generate two files: the Certificate Signing Request and the private RSA key. You need to email the .csr file to your instructor so they can send it to a Certificate Authority. Afterwards you need to move the .key file to the default certificate directory and set the appropriate SELinux contexts to them:$ sudo mv *.key /etc/pki/tls/private/
Your instructor will email you two files: one will be the public certificate for your server, and the other will be the Certificate Authority's public certificate; put the files in the following directories:$ sudo mv pegasus_lt_unt_edu.crt /etc/pki/tls/certs/
The next step is to alter the SSL configuration file that Apache uses, /etc/httpd/conf.d/ssl.conf. First, find the line containing the following:<VirtualHost _default_:443>
Replace it with the following lines:NameVirtualHost *:443
Find the following lines:#DocumentRoot "/var/www/html"
And replace the values with those we used in the /etc/httpd/conf.d/vhosts.conf file for the Virtual Host section of the server's IP address:DocumentRoot /var/www/html/default
Change the 'SSLCertiicateFile' variable to:SSLCertificateFile /etc/pki/tls/certs/pegasus_lt_unt_edu.crt
Change the 'SSLCertiicateKeyFile' variable to:SSLCertificateFile /etc/pki/tls/private/pegasus_lt_unt_edu.key
Change the 'SSLCertiicateChainFile' variable to:SSLCertificateFile /etc/pki/tls/certs/DigiCertCA.crt
Add Virtual Host sections for your virtual hosts at the end of the file. Make sure you have the correct paths for your SSL certificate and key directives:
<VirtualHost *:443> SSLEngine On SSLProtocol all -SSLv2 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW SSLCertificateFile /etc/pki/tls/certs/pegasus_lt_unt_edu.crt SSLCertificateKeyFile /etc/pki/tls/private/pegasus_lt_unt_edu.key SSLCertificateChainFile /etc/pki/tls/certs/DigiCertCA.crt ServerName pegasus.lt.unt.edu DocumentRoot /var/www/html/pegasus.lt.unt.edu ErrorLog logs/pegasus.lt.unt.edu_error-log CustomLog logs/pegasus.lt.unt.edu_access-log common SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </VirtualHost> <VirtualHost *:443> SSLEngine On SSLProtocol all -SSLv2 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW SSLCertificateFile /etc/pki/tls/certs/pegasus_lt_unt_edu.crt SSLCertificateKeyFile /etc/pki/tls/private/pegasus_lt_unt_edu.key SSLCertificateChainFile /etc/pki/tls/certs/DigiCertCA.crt ServerName pegasus-vh.lt.unt.edu DocumentRoot /var/www/html/pegasus-vh.lt.unt.edu ErrorLog logs/pegasus-vh.lt.unt.edu_error-log CustomLog logs/pegasus-vh.lt.unt.edu_access-log common SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </VirtualHost>
Save and exit
Restart the Apache daemon:$ sudo service httpd restart
Open your web browser and go to your server's IP and both FQDNs, but make sure to change the protocol to https:// and make sure you see the correct corresponding test pages.
Chapter 11: Common Administrative Tasks
Chapter 12: Compression, Sytems Backup, and Software Installation
Chapter 13: Troubleshooting and Performance
Go here for the NoMachine Client, Node, and Server Installers for Linux.
Download the i386 RPMs.
Change your working directory to the location where you saved the package and install it by running from the console as root. We use yum with the options so that the system will install any dependencies it needs. Change the file name based on the download:$ sudo yum -y --nogpgcheck localinstall nxclient-3.4.0-7.x86_64.rpm
Download the CLIENT software for your system and install.
See the directions on accessing a remote system.
|An example of setting up the local client to use NX No Machine to access remote server.|
For this part of the exercise there will not be many step-by-step directions provided. Be sure to read the install information comntained in the software.
Swiki is a standalone wiki that is based on squeak, which is based on the small-talk 80 language.
This is an example of an application that does not require php or apache to run.
You can download the software at http://wiki.squeak.org/swiki/15
Now that you have remote access to your server GUI, you can run firefox on your server and download it directly to the file system.
Once you have it downloaded and extracted, read the install steps.
The first time you run it will be using the remote GUI (vncserver) so that you can see the Swiki gui and configure it for port 8080 and the other elements that are required as stated in the install directions. [Hint: You will be using the terminal program within the Fedora GUI that you are accessing via VNC to start the swiki in order to see the setup window.]
If all things are right and the swiki is started, you can access your server swiki remotely using your web browser. The direction for doing this and starting the configuration process are contained in the SETUP window that is discussed in the previous paragraph.
Once you know this works when running it by hand from the GUI, you need to read the directions on how to run it "headless".
Fedora provides a file that is always read at startup to run scripts and applications. It is named /etc/rc.d/rc.local. You will want to place the swiki headless command in this file
You can test if headless runs, by running rc.local$ sudo /etc/rc.d/rc.local
Just be sure to kill any processes that are started so that you do not have more than one swiki runningHow to find and kill a process
find the process$ ps -ef | less
Look to see if you can find the process in question, for swiki we ran the command squeak..so we are looking for something line
root 3041 1 2 Feb08 ? 06:05:30 ./squeak -headless squeak.image
This tells us that the process for squeak is 3041
You can now kill that process:$ sudo kill -9 3041
and be able to run the rc.local again for testing
once you know the swiki runs okay in rc.local, try restarting your computer remotely and testing to see if it comes up as you expect
the command to restart your server is:$ sudo shutdown -r now
NOTE: you have to be root to issue this command and YOU MUST ALWAYS put -r (for restart). If you don't your server will shutdown and turn off.
Your computer will NOW restart. Hopefully!
Chapter 14: Network Configuration
Chapter 12: Configuring Network Services and Security
Appendix A: Certification
Assignment 4 focuses on the following issues. Be sure to examine these issues in the book and online in order to fully understand the concepts and terms:
Open a connection to your server with the NX No Machine interface. Then, open a web browser and go to http://localhost/phpmyadmin: you should be presented with a login prompt. Enter your MySQL root user's information. By default phpMyAdmin will only be accessible from the computer it is running on, but this can be changed in the /etc/httpd/conf.d/phpMyAdmin.conf file if needed. It is recommended that you do not open this up to everyone, as phpMyAdmin is a popular MySQL management application and as such your server will be probed for this address by remote hosts with the intention of using brute force attacks to access your database.
MySQL Workbench has replaced Mysql Administrator for mamaging the database locally on the system. Currently mysql workbench is not supported on yum, so you will need to go to the mysql site and download the software and install it manually.
|Some notes and comments about installing Joomla|
For Assignment 5 we're going to move the database off our host servers and onto a dedicated machine of its own so that it can consolidate databases across multiple systems. We'll be creating an SSH tunnel from our host system to the database server, so that our data is encrypted as it passes between the two. The purpose of this is to demonstrate both a local database configuration (assignment 4) and a remote database configuration (assignment 5). Once the steps below are completed, assignment 4 will no longer be functional.
For this class, another system (poseidon.lt.unt.edu) running Fedora with a MySQL database installed and running. All student user accounts have been created and should have access to the system via SSH. Some of the steps outlined below you have already done and will indicate that they do NOT need to be carried out in this class, but theyI have included them if you wish to duplicate this setup in another environment.
Start by configuring the system that is hosting our web-based services, which will eventually connect to the centralized database system.
The first thing you will want to do is backup your databases. You can do this by logging into phpMyAdmin, selecting your database and clicking the 'Export' tab. Make sure to check 'Save as file' to download your exported data.
Next, you'll want to shut down your MySQL daemon and stop it from starting at boot:# service mysqld stop
Next, in order for our SSH tunnel to be established without having to be created manually, we'll be using public key authentication, and in order to do so, we must create the keys for our root account:# ssh-keygen -t rsa
Hit Enter to save to the default path (/root/.ssh), and hit Enter when it asks for a passphrase (no passphrase): DO NOT ENTER A PASSPHRASE!
Now we must transfer the public key for the root account to the database server. Since the server has been configured to not allow the root account to log in over SSH, you'll have to use your regular user account:# scp /root/.ssh/id_rsa.pub USERACCOUNT@poseidon.lt.unt.edu:
While we're still on the host system, we can go ahead and make some changes to phpMyAdmin's configuration file (/etc/phpMyAdmin/config.inc.php). Change this line:$cfg['Servers'][$i]['host'] = 'localhost';
To this:$cfg['Servers'][$i]['host'] = '127.0.0.1';
Also, while we're here, we need to change an SELinux boolean so that Apache can connect to the MySQL database over the network:# setsebool -P httpd_can_network_connect_db 1
We've done all we can do on our host machine, so we'll have to move on to the database server. For this course, the first five steps (in red), so do not do these now.
Install the MySQL server daemon:$ sudo yum install mysql mysql-server
Edit the MySQL configuration file (/etc/my.cnf). Find this line:socket=/var/lib/mysql/mysql.sock
And comment it out:#socket=/var/lib/mysql/mysql.sock
Also, add the following line right after it:bind-address=127.0.0.1
Save and exit
We'll have to set an SELinux boolean to allow SSH to forward ports through the tunnel:$ sudo setsebool -P sshd_forward_ports 1
Start the MySQL daemon and set it to run at boot:$ sudo service mysqld start
Set password for the MySQL root account:$ sudo mysqladmin -u root password "ACTUALPASSWORDHERE"
Create a user account for the SSH tunnel creation (NOTE: you can name this account anything you want):$ sudo useradd tunnel
Now you will have to copy the public key we copied earlier to the authorized_keys file for the SSH tunnel account:$ sudo cat /home/USERACCOUNT/id_rsa.pub >> /home/tunnel/.ssh/authorized_keys
Back on the web host, we'll first established the SSH tunnel:# ssh -fNL 3306:127.0.0.1:3306 email@example.com
What this command does is binds our port (3306) to an IP address (127.0.0.1) and connects it to the remote port (3306) on the remote system (poseidon.lt.unt.edu) that we will connect to with public key authentication against the remote user account (tunnel).
To test the connection, run the following:$ mysql -h 127.0.0.1 -u root -p
If after entering the password you're presented with a MySQL prompt (mysql> ), then everything is working.
Open a browser and go to your phpMyAdmin installation, using the password for the new database root account. If you're successful, create the database that you had on your local MySQL server and import the data that you exported earlier.
If everything is working, the last step is to add the following to the /etc/rc.local file, which is run at boot:ssh -fNL 3306:127.0.0.1:3306 firstname.lastname@example.org