Let's give scp a try. As with our previous SSH activity, you'll need at least two machines: one with the SSH server installed and running, and another with at least the client. In this case, the distribution shouldn't matter as long as you meet this simple requirements. In addition, we'll need a file to test with. The file can be something small (such as a text file or image) or large (such as an ISO file for a Linux distribution). The goal is to transfer this file to another machine using scp. Let's see how to do this.

For the sake of this tutorial, I'll outline the procedure for a machine named foo to transfer a file to a machine named bar.

First, let's take a look at a simple example of scp:

scp my-image.jpg 192.168.1.200:/home/jdoe/

In that example, we've executed the scp command against a file named my-image.jpg. Next, we outline the target. In this case, a machine with the IP address of 192.168.1.200. Then, we type a colon and the path where we'd like the file to be stored. In this case, we are going to copy the file into the home directory for jdoe.

Since we know the name of the target machine (bar), we could use the name of the machine instead of the IP address, assuming that it is recognized by the DNS server. It was configured in ~/.ssh/config, or is an entry on foo's /etc/hosts file. The command is as follows:

scp my-image.jpg bar:/home/jdoe

We simplified the command a bit, since we know the name of the machine. Additionally, we don't have to type out the name of the directory if we're intending to copy to a user's home directory. We could have simplified the command to the following:

scp my-image.jpg bar:.

In the example, instead of typing out /home/jdoe, we replaced the path with a period. This works because the home directory is assumed, unless you give the command a separate path. We'd also get the same result if we used a tilde (~) instead:

scp my-image.jpg bar:~

What if the data we wish to copy is an entire directory, instead of just a single file? If we try to use the scp command against a directory, it will fail. In order to copy an entire directory, we need to add the -r flag that performs a recursive copy:

scp -r my_dir bar:~

Now, the my_dir directory and its contents will be transferred over. Another useful flag when copying files is -p, which preserves the modification times when the file is copied. If we combine that with the previous command, we get:

scp -rp my_dir bar:~

However, each of these commands will fail if the user name is different on the two machines. For example, if the logged-on user on foo is dlong and the user doesn't exist on bar, the command would fail because the sending computer would default to using dlong, the currently logged-on user. In this case, the other computer would ask you for the password three times, and then give you a message that access is denied. This is because you would essentially be typing a password for a user that doesn't exist. If we need to specify the username for the target, the command would become similar to the following:

scp my-image.jpg jdoe@bar:~

With the new version of the command, you'll be prompted for the jdoe password and then the file would be copied to /home/jdoe on the receiving end.

As mentioned previously in this chapter, the default port for SSH (port 22) may not be open on the target, as perhaps it is listening on a different port. With scp, we can specify a different port. To do so, use the -P flag. Note that this is an uppercase P, unlike the ssh command that uses a lowercase -p for specifying the port (this can be somewhat confusing at first when switching between ssh and scp). For example, this flag is appended to the previous command:

scp -P 6022 my-image.jpg jdoe@bar:~

Go ahead and give it a try in your lab. Find a file of any type and attempt to transfer it to another Linux machine. If you do this a few times, you should be able to get the hang of it fairly quickly. Another point of interest in regards to scp is that you can use it to copy a file or directory from a remote machine to your local one, if you already know the path of the file you wish to download. In the last example of this section, I'm copying myimage.jpg from remote host bar to my current working directory (which I designate with a period):

scp jdoe@bar:~/myimage.jpg .

One of the most useful features of SSH is creating an SSH tunnel. An SSH tunnel allows you to access services locally that originate from another computer or server. This allows you to do such things as bypass local DNS filtering, or even access an IRC server that is segregated within your company, from home.

In order for an SSH tunnel to be effective, you first need to be able to access SSH where the service you'd like to access is hosted. If you're able to initiate a normal SSH connection to a network containing the service, chances are that you'll have no problem creating a tunnel.

While utilizing SSH to create a tunnel, the command changes a bit. Instead of just executing the ssh command against a host name or IP address, there are a few more flags added. First, we add the -L flag. This sets up what is known as a bind address, which basically means we are taking a local port and forwarding it to a specific port on the other end.

The syntax for such a command string would be something like this:

ssh -L <local-port>:localhost:<remote-port> <username>@10.10.10.101

Basically, we execute SSH with the -L flag and use localhost since we intend to forward a local service to a remote one. However, we sandwich the command with a port and a colon on either side. The port on the left-hand side is our local port and on the right-hand side of the IP address, we have a colon and then the remote port. We then finish off the command with our usual syntax, that is, we type our user name and then the IP address of the gateway we will use for the connection.

Confused yet? Let's break this down further and use an example.

By default, VNC (a graphical remote access program) utilizes ports 5900-5902. If you wanted to access a desktop environment on a remote host with an IP address of 10.10.10.101, use the following command:

ssh -L 5900:localhost:5901 [email protected]

Here, we're forwarding port 5900 on our local machine to port 5901 on 10.10.10.101. As soon as the session connects and is established, we can then use the following in our VNC viewing application on our local machine to connect to the VNC service on the remote end:

localhost:5900

Anytime localhost:5900 is used, we'll be forwarded to our remote machine. To end the session, exit from the SSH connection. For VNC, we need to specify which VNC session to use. In order to use the VNC Viewer application to open a VNC session to 10.10.10.101, we would execute the following command:

vncviewer localhost:1

However, what if the machine or service we wish to connect to is behind a different gateway? The previous example only works if the IP address, 10.10.10.101, is routable through the Internet, or we are actually on the same network as the resource we wish to connect to. This is not always the case, and generally useful services are not exposed directly to the Internet. For example, if you're at home and you wish to connect to the remote desktop protocol on a computer in your work network, the previous example wouldn't work.

In this example, at the office, we have a computer with a remote desktop exposed with an IP address 10.10.10.60. We can't get to this machine directly from home, because it is not routable through the Internet. However, we just so happen to have a server at work that actually, is exposed to the Internet with an outside IP address 66.238.170.50. We are able to SSH directly into that machine from home, but host 10.10.10.60 is further within that network.

Here, we can utilize host 66.238.170.50 to facilitate our connection to 10.10.10.60 inside our work network. Let's look at a command:

ssh -L 3388:10.10.10.60:3389 [email protected]

In this example, jdoe has a user account on host 66.238.170.50 and wishes to connect to host 10.10.10.60, which is inside her company network. In this example, jdoe is forwarding local port 3388 on localhost to port 3389 on host 10.10.10.60, but establishing the connection through host 66.238.170.50. Now, user jdoe is able to open a remote desktop client and use the following command for the connection address:

localhost:3388

As long as the SSH connection remains open, jdoe will then be able to utilize a remote desktop on the server from her local computer. If the shell is closed, then the connection will terminate.

Using SSH tunnels can be very useful. Feel free to give it a try and see which services you can forward through your network.