SSH beyond the command line

SSH beyond the command line


If you’re an experienced administrator, you’ve probably used SSH to remotely access a troublesome box or your personal computer. For those who don’t know: SSH it’s a great way to fiddle with a computer from miles away as if you were sitting at its keyboard, but it’s also just about the simplest and most secure way to configure your computer to let you access its files from anywhere. You can use SSH on nearly every operating system to transfer files to and from your computer over the internet or a LAN.

Is SSH for more than commands?

SSH is traditionally used to give you remote access to a computer’s shell (command line terminal). Earlier protocols in this vein, such as telnet and rlogin, did not encrypt their traffic or take other security precautions that are necessary with untrusted networks like the internet. Depending upon the exact server, protocol, and configuration you use, SSH may be the most secure way to access a computer over a network.

If you’re a typical user, however, you may never need to access the command line—or even graphical applications—on a remote computer. Even so, SSH will still be useful in sending your latest batch of photos home from your hotel, retrieving the latest version of a report left sitting on your desktop, or for any other situation requiring a file transfer.

If you’d like to get more in depth, you can use it to load or edit a spreadsheet on another computer or keep documents synchronized between machines. If you’ve seen an experienced user work his magic with SSH, all of this may seem rather complicated. I assure you, though, that setting up an SSH server on GNU/Linux or another Unix-like operating system—and even Microsoft Windows—is as simple as installing any other software, and accessing your server from another machine running nearly any OS is even easier.

Setting up an SSH server is as simple as installing any other software, and accessing your server from another machine is even easier

Installing the server

The SSH protocol has been around for a while and several server packages have sprung up around it. The choice is a bit simpler than KDE vs GNOME, though, because almost everyone you meet will recommend OpenSSH. It’s tried, true, secure, free software developed by the OpenBSD project but made available for nearly every operating system under the sun.

If you’re using a Unix-like system such as GNU/Linux, installation really is as simple as for any other software. If your distribution has a package management utility, OpenSSH is undoubtedly available from it. In Debian and Ubuntu, it’s listed as “openssh-server”. If you normally have to install software from source, you can get the code from the OpenSSH website.

Unfortunately, things are a bit more complicated if you use Windows. You will need to use some software called Cygwin to emulate the GNU/Linux platform on your Windows box. If you are already familiar with Cygwin, you can install OpenSSH as a native package.

Wait, though! If you don’t use Cygwin already—wouldn’t you know it—someone has gone and made the whole process just as easy. The OpenSSH for Windows project has combined OpenSSH with only the absolutely necessary components of Cygwin, rolled it all up into a ball, and released it as free software on Sourceforge. Download and double click the “binary installer” as you would any other Windows setup package.

Some minor tweaking, if desired

Below, I will explore some of the configuration options of OpenSSH. Odds are your distribution has your server setup more or less like this by default, so you may safely skip this section and refer back later on if you experience problems.

OpenSSH for Windows users must also depart from the article here, as configuration on that platform works a little differently. You can refer to the README file, accessible from Start→All Programs→OpenSSH for Windows for configuration instructions. In particular, make sure to setup user passwords using the simple instructions in the readme.

For those continuing on, OpenSSH configuration can easily be done by editing a configuration file (never as scary as it sounds). On most systems, this file will be located at /etc/ssh/sshd_config. Open this file as the root user using your favorite text editor and you will find that your distribution has supplied a long template configuration file.

OpenSSH has a broad range of configuration options that can have serious effects on the security of your system. I will trust that the default settings provided by your distribution are sensible and focus on changing the configuration to serve the specific requirements of file transfer.

You could debate whether a password is more secure than other methods of authentication, but it is undeniably convenient

Password authentication

First, you can configure the SSH server to authenticate users with a password. You could debate whether a password is more secure than other methods of authentication, but it is very convenient when trying to access your machine from an arbitrary remote location where you might not have access to anything but your memory. Make sure the following line is set in your configuration file:

PasswordAuthentication yes

Remember that any line in the configuration file beginning with # is a comment, so delete the hash mark if you want to activate the line.

Allowed users

Next, you may want to assure that you are the only user who can access your computer through SSH. By default, anyone with an account on your computer may be configured to login with OpenSSH. By specifying your user, you can control which files can be accessed remotely, as only the files to which your user has permissions will be accessible. Put the following line in your configuration file:

AllowUsers [my user]

Now only [my user] will be able to log in, using his regular account password. You can do a lot with host and user restrictions with SSH, but this should be enough for our purposes.

Don’t forget to restart!

You will need to restart the SSH server before these changes to the configuration file take effect. The following command (as root) will work on most Unix-like systems:

/etc/init.d/ssh restart

The ssh in the above command may be replaced by, for instance, sshd, depending upon your distribution. You can use your shell’s tab-complete feature to guess at the right syntax. If you’re having a really hard time entering this command, you could just restart your computer—but that shouldn’t be necessary.

To access the server you have just configured, you will need to know the exact address of your system. If you don’t have a domain name configured, just use your IP address. Of course, depending upon your internet service provider, this address could change periodically and you may need to use a dynamic DNS service to make a stable URL.

If you are accessing the machine within a LAN, check your router’s configuration for the address of each machine. If you are dialing into a LAN, make sure the standard SSH port (22) is being forwarded to the machine.

Down to business: trading files

There are a lot of SSH clients out there available for nearly every platform imaginable. I’m going to take a wild guess and assume that the majority of you Free Software Magazine readers are using GNOME, KDE, or Windows at home or at work. Below, I’ll walk you through graphical clients that were made for each of these three platforms and a command-line client that will work almost everywhere else.

The old standby: scp

OpenSSH is distributed with scp, a command line tool for transferring files between computers with very simple syntax. Of course, unlike FTP, scp file transfers are tunneled through SSH encrypted, and are secure out of the box. The GUI programs discussed below are mostly front ends to scp and you should, by all means, use them if they are available. If you can’t get your hands on them though, or if you just want a better understanding of how the file transfers operate, read on about scp.

The syntax of a simple single file transfer with scp is very concise:

scp [source file location] [target file location]

You can make either the source or target location remote and the other local. The syntax for the remote location should include the user name to authenticate as on that machine, and should be formatted as follows:

[user]@[address]:[remote directory]

For example, examine the command used to transfer a file from the Documents directory of my local computer onto the desktop of my laptop over my LAN:

scp /home/nathan/Documents/Document.txt sanders@192.168.0.4:/home/sanders/Desktop/

When executing this command, you will be prompted for the password of the user on the remote machine. If it is the first time you are accessing the machine, you may be asked to verify its RSA host key—it is safe to respond in the affirmative.

The scp tool has many advanced features to limit bandwidth usage, specify particular SSH configurations, copy directories recursively, and more. For a concise listing of these features, consult the scp manual by entering the command man scp.

GNOME: using Nautilus with remote files

You may not have realized it, but GNOME’s default file manager Nautilus ships with capabilities for accessing remote hosts via several different protocols, including SSH, through an easy-to-use dialog.

Open the dialog in Nautilus from File→Connect to Server. Select SSH from the “Service Type” menu and fill in the Server field with the appropriate information. You will be prompted for a username and password. Once entered, a Nautilus window displaying the root directory of the remote machine will be presented.

Figure 1: Nautilus’ remote server dialog is wonderfully simple. The only thing you need to enter here is the server address, but you can specify the other variables if you wishFigure 1: Nautilus’ remote server dialog is wonderfully simple. The only thing you need to enter here is the server address, but you can specify the other variables if you wish

Once you have an open Nautilus window to your remote PC, you can play with its files just as you would local ones. You can even open multiple remote servers through multiple protocols and drag & drop files between them.

Once you have an open Nautilus window to your remote PC, you can play with its files just as you would local ones

You may find that certain remote files will not open correctly when clicked in Nautilus. This is because only certain GNOME applications support accessing remote servers. In problematic cases, you may simply copy the file to a local directory before attempting to open it. You can, of course, copy the changed file back over to the remote server when you are done.

gedit is one application that does support remote servers, so if you click on a text file in Nautilus (and gedit is your default editor) you should be again prompted for the remote user name and password and then presented with the document. Changes made with gedit will be saved directly to the remote server.

KDE: learning how to fish

KDE users may access remote servers in a manner similar to Nautilus in GNOME. In Konqueror, open Go→Network Folders to be taken to the remote:/ URL. From there, you can add a remote SSH server with the “Add a Network Folder” link. You will be prompted to choose a protocol, name the remote location, and enter details about the server.

You may specify a specific directory on the remote server if you wish. The remote location will then be forever accessible as a shortcut from remote:/ and can be bookmarked or accessed from other KDE applications as normal. You will be prompted for a password each time you access the server.

Figure 2: Accessing remote directories in Konqueror takes a few more clicks than in Nautilus, but the process is very similarFigure 2: Accessing remote directories in Konqueror takes a few more clicks than in Nautilus, but the process is very similar

When you add a remote location this way, you are be guided through setting up a link using KDE’s fish KIO-slave. KIO lets you use simple URLs to access remote directories in KDE applications. Each “slave” supports a different protocol—fish works with SSH. As with GNOME, some programs will refuse to access remote servers, but most KDE 3.5 applications will play nicely.

You can skip the Add a Network Folder wizard and construct your fish URLs directly without too much difficulty. Use the following format:

fish://[server address]:[port]/[remote directory]

You will be prompted for a username and password upon accessing the URL. Although this prompt is important for security, there may be times when it is inconvenient. For instance, you may want to configure an application to load a remote file upon launch, in which case you wouldn’t want to be bothered with a password prompt. Use the following format to avoid having to input anything interactively:

 
fish://[user]:[password]@[server address]:[port]/[remote directory]

Of course, your password is now stored in that application’s configuration file. At the very least, you may want to make sure the file’s permissions are set to allow read access only to you.

You can do a lot of fun things with network transparency and fish. Right click on a file in Konqueror and select Actions→Print to directly print files from remote machines without having to set up a print server. Some KDE media players will allow you to play music and videos directly from a remote server, but limitations in the KDE 3 KIO system mean you may not be able to seek through the files (fast forward or rewind). Experiment with your own favorite KDE applications to see the extent of what you can do with fish.

Windows: less integration, but just as much fun with WinSCP

Microsoft has not embraced SSH to the extent that the major free software desktop environments have, but you can still perform typical file transferring tasks with SSH from a Windows box using third party clients. Several Windows scp clients exist, but I will focus on WinSCP, a popular, simple, and free tool. WinSCP 4.0 (currently in beta) includes support for FTP, but I will explore the 3.x series and its SSH functionality only. Download the standalone executable or installation file for WinSCP 3.8.2.

Figure 3: The scheme for logging into an SSH server from a GUI front end should be clear by now, and WinSCP calls for no exceptionsFigure 3: The scheme for logging into an SSH server from a GUI front end should be clear by now, and WinSCP calls for no exceptions

WinSCP’s GUI can look like either a complicated Windows Explorer window or the old Norton Commander two-pane interface, depending upon your preference. You may also select Icon, List, and Details views as you would in Explorer. Either way, navigating within directories works as in other file managers and you can drag & drop files around as you please.

WinSCP has some advanced features for synchronizing remote directories and managing remote server sessions that will not be addressed here. You may also execute commands on files on the remote server using the File→Custom Commands menu. WinSCP’s Preferences dialog is filled with dozens of settings to configure the way it uses the SSH protocol.

While WinSCP is definitely less integrated than the GNOME and KDE solutions discussed, the developers have made a valiant effort to establish their application’s functionality within Explorer. Upon installation, or from the Preferences dialog, you may register WinSCP to handle SSH protocol addresses and add WinSCP to Explorer’s context menus. There are also options for integrating WinSCP with the PuTTY Windows SSH client.

Don’t stop there!

You have just been introduced to a very limited set of features made possible by the SSH protocol. I think you will find that configuring an OpenSSH server for transferring files is easier than setting up an NFS, SAMBA, or FTP server—achieving a level of security comparable to what an encrypted SSH session can provide. If you find yourself in agreement and using SSH regularly, explore some of its other uses.

You will find that configuring an OpenSSH server for transferring files is easier than setting up an NFS, SAMBA, or FTP server

With just a little bit more reading, you could learn how to execute commands on your remote server or tunnel arbitrary network tasks through the secure piping of SSH. The web is filled with tutorials for these common SSH tasks.

Read Free Software Magazine issue 20 (the next issue!) to learn how to run GUI GNU/Linux applications remotely on a Microsoft Windows host.

Category: 
License: 

Comments

Andrew Min's picture
Submitted by Andrew Min on

Love it! Informative, easy-to-use, and includes instructions for KDE as well as Gnome! Looking forward to the next article.

--
Andrew Min
http://andrew.timstown.net/dock.htm

ukh's picture
Submitted by ukh on

Thanks for a nice article!

I find going through Nautilus annoying since, at least in my environment, it defaults to the root, rather than my home directory. For those needing a GUI frontend in Gtk+ that doesn't involve digging for your $HOME, I'd suggest looking at gFTP, http://www.gftp.org/.

FOSS SFTP frontends on Mac OS X include Fugu, http://rsug.itd.umich.edu/software/fugu/ and Cyberduck http://cyberduck.ch/.

Also, being a GPL SFTP client on Windows, I think FileZilla, http://filezilla.sourceforge.net/, deserves to be mentioned.

undefined's picture
Submitted by undefined on

the benefit to ssh-gnome integration (gnomevfs) is not necessarily nautilus supporting ssh, but most (all?) gnome applications supporting ssh.

correct me if i'm wrong (it might have been smb, not ssh, that i recently exercised, but i've done something similar with ssh-access under gnome), but recently my wife needed to edit a document (not a plain text file) on a remote server with openoffice. it just worked. later we needed to open a remote file with a non-gnome application which required copying the file locally with nautilus, editing it, and copying it back. my wife didn't care for the multi-step process.

so yeah, though nautilus might not be the best ssh/sftp/scp client, it's just the tip of the gnomevfs iceberg.

(btw, to be desktop-agnostic, kde w/ kio slaves is smiliar, if not identical.)

undefined's picture
Submitted by undefined on

first, "openssh for windows" appears to be unmaintained with no releases since 2004 and with a statement claiming such on http://www.openssh.com/windows.html. i don't recommend unmaintained security software. that page lists an alternative: copSSH. not that i care much for cygwin, especially application-specific cygwin installations, as it was (is?) troublesome (cygwin applications interact poorly with cmd, native applications interact poorly with bash, different versions of cygwin dll conflict with one another due to versioning of shared memory, etc) and slower than native. granted, my experience is dated (2004), but was extensive at the time, and i finally gave up in frustration and decided "when in rome, do as the romans".

second, i never found ssh to be that useful on windows. most (all) meaningful windows applications require a gui which means rdp. for administration, windows is nearly impossible to interactively administrate without the control panel and mmc. just about every windows application installer assumes a gui, too. yes, there are ways to administrate and install without a gui, but if you are "in bed" that much with windows, you're probably using wsus, login scripts, psexec, etc. for file transfers? never had that big of a need as i usually tunnel to a linux box and get it by way of that machine (port forwarding vnc and/or rdp, remote x-windows file manager, or just smbfs).

thirdly, "run GUI GNU/Linux applications remotely on a Microsoft Windows host"? xming?

skypjack's picture
Submitted by skypjack on

Really an easy-to-use, good article!
Thanks so much ...

Chris G.'s picture

This is an overly complicated process that can be solved with two small, simple, and free programs:
1) Simon Tatham's PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/)
2) FileZilla (http://filezilla-project.org/)

FileZilla has some notable features (quoted here from their site):
* Easy to use
* Supports FTP, FTP over SSL/TLS (FTPS) and SSH File Transfer Protocol (SFTP)
* Cross-platform. Runs on Windows, Linux, *BSD, OSX and more
* Available in many languages
* Supports resume and transfer of large files >4GB
* Powerful Site Manager and transfer queue
* Drag & drop support
* Configurable Speed limits
* Filename filters
* Network configuration wizard

My organization manages over 8000 machines and have found FileZilla so useful and simple, we have replaced the aging WS_FTP with it in our base image. PuTTY is also part of our base image. Why? Because it's free, simple and versatile. If you like command lines, then it also has utilities to work from the command line, especially for SCP.

As I stated in the subject line, this article is too much work for the benefit. Use easier, supported solutions.

undefined's picture
Submitted by undefined on

overly complicated process? solved with two small, simple, and free programs?

you seemed to have forgotten about the server? half of the article (1.5 pages) was about configuring sshd, but without that "work" and "complicated process" your clients are useless.

and the rest of the article was about linux: openssh's scp, gnome's nautilus, and kde's konqueror. oh yeah, there was an itty-bitty bit about windows (which you are definitely coming from with comments about putty & ws_ftp).

so the relatively small mention of windows support, really only winscp, is "too much work" and part of "an overly complicated process"? yeah, introducing TWO applications (filezilla & putty) is so much easier and simpler than just one (winscp).

anyways, i think the article is laid out well and progresses logically:
- intro
- sshd configuration (because ssh requires a server and configuration is important for security)
- scp (the original, basic, & default file client for ssh)
- nautilus (gnome integration)
- konqueror (kde integration)
- winscp (windows-specific client)

i may question the utility of sshd on windows, but that's a very small part of the article, and i wouldn't make general comments about the whole article based on that one paragraph.

mind's picture
Submitted by mind (not verified) on

no need for gnome vfs or kde proprietary filesystem wrapper paths. fuse is in the kernel, and sshfs is in my apt tree on ubuntu.

% sudo apt-get install sshfs
% sshfs server: ~/remote

will mount your home directory on server under ~/remote on the local machine, using only the sftp server on the remote end.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Hello Nathan and Hello World,

I'm new to ssh and want to ask you a question:

I have signed up for a dedicated server.
Now I want to check if the memory really is 2 GB
and that the cpu really is a pentium 4 and not a celeron.
Do you know the ssh commands for that?
Maybe diskspace and bandwidth can be checked also?

CuteFTP Pro seems to handle ssh: www.globalscape.com
It should be debian, similar to freeBSD installed on an apache server.

Thanks a lot,

Customer911

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

assuming it's a linux machine, log on your server and run these commands:

cat /proc/cpuinfo
and
cat /proc/meminfo
and
df -h

checking bandwidth would be tricky, but you can keep an eye on
cat /proc/net/dev
to monitor how much data is going through your network interface...

[]'s

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

and let's not forget about beautiful multimedia streaming over ssh with elegant commands like:

ssh xoxota cat /data/1/mp3/ChicoBuarque/O_Grande_Circo_Mistico/08-Ciranda_da_bailarina.mp3 | mpg321 -

( where i log on my remote machine "xoxota", and execute a "cat" of a file, piping it to the mp3 player "mpg321" running locally on my laptop )

Author information

Nathan Sanders's picture

Biography

Nathan Sanders is an experienced free-software user and frequent contributor to publications concerning open-source software.