Issuing Remote Commands
When you open a SSH connection to a remote machine, it typically opens an interactive session on the other machine and drops you into that user's default shell, culled from the /etc/passwd file, like this:

[james@server1 ~]$ ssh James@server2
james@server2's password:
[James@server2 ~]$

However, the interactive session isn't really required; SSH just does this by default when it isn't asked to do something else. By specifying a command to be executed on the remote server, you can execute that command and have the output returned directly to the screen without logging in to the remote server interactively. Here, I check the uptime of a remote machine without opening an interactive session (the command is in boldface for clarity):

[james@server1 ~]$ ssh james@server2 uptime
james@server2's password:
3:10pm up 298 day(s), 22:12, 0 users, load average: 0.69, 0.50, 0.49
[james@server1 ~]$

This syntax, coupled with public-key (passwordless) authentication, can speed up everyday tasks significantly.

To understand what's really happening here, it helps to know something about how SSH actually uses the user's shell to execute commands. The SSH daemon running on server2 is listening for incoming connections. When it receives a request that passes authentication, it runs that user's shell, as specified in the /etc/passwd file. If we were to do this from the command line on server2 itself, we would open a new shell as a child of the shell we already had open (note how the prompt changes; the Bourne shell, which is located at /bin/sh in this example, is very austere by default):

[james@server2 ~]$ /bin/sh
$

If, however, additional commands are detected in the incoming SSH request, the SSH daemon runs the user's shell with a "-c" switch, followed by the command. This feature of SSH takes advantage of a feature of the Bourne shell, from which most popular Unix shells derive. In Bourne shell syntax, the "-c" switch indicates that the commands included in the string following the "-c" are to be executed immediately. So, this is equivalent to what actually happened on the remote machine in the preceding uptime example:

[james@server2 ~]$ /bin/sh -c uptime
3:15pm up 298 day(s), 22:17, 0 users, load average: 0.69, 0.50, 0.49
[james@server2 ~]$

This will become important later on, when we discuss the secure file transfer protocol (SFTP).

Editing Remote Files
Since you can easily issue a remote command using SSH, it stands to reason that you should be able to perform tasks more complex than checking the system's uptime. However, some applications require a tty or terminal to run. A tty, or teletypewriter device, is an abstraction left over from the days when Unix machines had lone physical terminals connected to them; now, it refers to any application that emulates the serial port interface that was used to connect physical terminals. By default, SSH won't allocate a terminal (actually a pseudo-tty, also known as a pty device) if a command to run is specified. Let's say we need to add an entry to the /etc/hosts file using the vi text editor. The vi application requires a terminal to be allocated on some systems, so initially we receive an error:

[james@server1 ~]$ ssh root@server2 'vi /etc/hosts'
unknown: Unknown terminal type
[Using open mode]
Segmentation Fault - core dumped

To circumvent this error, I can use the "-t" switch, which forces the remote SSH server to allocate a terminal to the application:

[james@server1 ~]$ ssh -t root@server2 'vi /etc/hosts'

The above command opens the vi application on the remote host, server2, but displays it in my current window on server1. Closing and saving the file then saves the edited file on server2. The same logic applies to almost any command. Note the single quotation marks around the command in my command line -- those help to ensure that the command isn't misinterpreted by either system.

Redirecting Backups
A common trick for moving an entire directory tree from one place to another is to use the tar command in conjunction with a Unix pipe (the "|" character):

[james@server1 ~]$ tar cvf - mystuff | (cd /usr/local ; tar xvf - )

The logic of the foregoing command is simple:

• tar xvf - mystuff -- Generate a tar (tape archive) file of the mystuff directory, but send the output to standard output rather than to a file.
• | -- Pipe the standard output to the next command, rather than to the screen.
• (cd /usr/local ; -- Change to the /usr/local directory.
• tar xvf - ) -- Expand the archived directory tree in its new location (still on server1)

By using an SSH command as a bridge, we can copy the entire directory tree between two separate machines just as easily:

[james@server1 ~]$ tar cvf - mystuff | ssh james@server2 'cd /usr/local ; tar xvf -'

The preceding command copies the mystuff directory to the /usr/local directory on server2. The reverse is also possible, copying the /usr/local/mystuff directory on server2 to my home directory on server1:

[james@server1 ~]$ ssh james@server2 'cd /usr/local/mystuff ; tar cvf - .' | tar xvf -

Since Unix pipes and output redirection syntax work with SSH commands just as with any other Unix commands, there are any number of ways to "relocate" standard Unix file utilities in this way. Utilities such as bzip and gzip can be used to compress or decompress content on the fly, and archiving tools such as cpio and afio are as compliant as tar. You can even stream MP3s to your favorite MP3 player or burn CDs on a remote machine in this manner.

Create a (Semi-) Secure Dropbox
This isn't as much a SSH trick as it is a generic system administration trick, complicated by the inclusion of SSH. On most Unix systems, you can restrict interactive use of the system by specifying an invalid shell. For instance, the following entry in the /etc/passwd file forces the "logs" user to use the program /bin/false as their login shell, rather than the standard /bin/sh or /bin/bash:

logs:x:99:1:Log Collection:/bin/false

Since /bin/false, on most systems, is either a shell command or executable binary that immediately exits with a false return code (usually a value of "1," but also "255" on some systems), giving the user such a shell prohibits them from logging in to the system -- although the user still exists, and can run programs and own files. An IMAP mail server, for instance, might use entries in the password file like the preceding to allow users to start IMAP sessions with their mail clients, but prevent them from logging in to the system directly.

A similar configuration can be used to allow remote users to copy or obtain files from a system via SFTP, the secure file transfer protocol, while denying them the ability to execute any other commands. To accomplish this, we can use the SFTP server command itself as the user's shell in /etc/passwd:

logs:x:99:1:Log Gathering:/home/logs:/usr/local/libexec/sftp-server

Then, users can open a SFTP session to server2 like this (so long as the SSH daemon's configuration permits SFTP to begin with; see the manual page for sftp-server for more information):

[james@server1 ~]$ sftp logs@server2
Connecting to server2...
james@server2's password:
sftp>

However, attempting to start a normal SSH session will be next to useless (even if the user tries to run an additional command, using the syntax from our first tip), because the sftp-server command, which we specified as our shell, isn't really a shell. Therefore, it doesn't allow other commands to be run -- there's no equivalent to the Bourne shell "-c" switch for sftp-server. You can verify that this is a "safe" configuration by opening a SSH connection to the other machine and seeing what happens:

[james@server1 ~]$ ssh logs@server2
james@server2's password:

At this point the session hangs indefinitely, waiting for input. Any input results in an immediate disconnect and returns us to our original session:

get /etc/passwd
bad message
[james@server1 ~]$

This behavior may seem odd, but is perfectly explicable: when we set the user's shell to /usr/local/libexec/sftp-server in the /etc/passwd file, that's the program that the system runs whenever that user logs in. So, when we open an SSH connection, the remote system runs the sftp-server command rather than an actual shell -- and since we can't talk to the sftp-server as we would to a shell, the sftp-server says that we've sent a "bad message" and closes the connection. We need to use the sftp program to speak the sftp-server's language.

Note that this is merely a convenient hack; that is, we're depending on the behavior of the sftp-server command in the OpenSSH distribution for our security. This works, but it isn't elegant. Also, using sftp-server as the shell doesn't restrict the user to a particular directory, which is often desirable for a FTP server: The way I have this set up, the logs user can download any readable file on the server. Lastly, it opens us up to a denial of service attack: if someone decides to open up numerous SSH connections as the logs user, that could rapidly flood our system with lots of sftp-server processes in the "waiting" state.

For stronger security, we could do any number of things:

• Restrict access using a firewall.
• Rather than using sftp-server as a shell, download one of the many restricted shell programs available on the internet. A program designed for exactly our purpose is available here.
  
• Set up a "jail" for the user, using the chroot command, as described here.

Moving On
When it comes to security, Secure Shell is like the rising tide that lifts all ships -- if you use it, you're already ahead of the game. However, not to strain the metaphor, it's still possible to have leaks, so it helps to pay attention to how and why your SSH installation is performing its duties.

We've barely touched the surface of what SSH can do in this article. Some of the more innovative uses of SSH include:

• Network file systems, similar to NFS, but based on the SSH protocol. Shfs and the more general-purpose Linux Userland File System (lufs) are two examples, both implemented as Linux kernel modules.
• Port forwarding to circumvent firewalls.
• Secure remote management. This site provides a suite of Open Source, SSH-enabled applications, written in Java, that supplement or replace many standard administration tools.
• Secure distributed management. Distributed shells (which I've discussed in a previous column) such as dsh, dcmd or fanout allow you to execute one command across multiple servers simultaneously, and can use SSH as the transport mechanism. Some variants on the distributed shell concept, such as fanterm, even allow you to run interactive commands (such as text editors) across multiple machines simultaneously.

And there's more: This PDF of advanced SSH tricks from gives you some idea of the more useful tricks.

Experiment away!