SSH (secure shell) is a program enabling secure access to remote file systems. Not everyone is aware of other powerful SSH capabilities, such as password less login, automatic execution of commands on a remote system or even mounting a remote folder using SSH! In this article we'll cover these features and much more.
SSH works in a client-server mode. It means that there must be an SSH daemon running on the server we want to connect to from our workstation. The SSH server is usually installed by default in modern Linux distributions. The server is started with a command like /etc/init.d/ssh start. It uses the communication port 22 by default, so if we have an active firewall, the port needs to be opened. After installing and starting the SSH server, we should be able to access it remotely. A simple command to log in as user1 to the remote_server (identified by a domain name or an IP address) looks like this:
ssh user1@remote_server
After entering the password to access the remote machine, a changed command prompt should appear, looking similar to user1@remote_server:~$. If this is the case, it means that the login was successful and we're working in a remote server environment now. Any command we run from this point on, will be executed on the remote server, with the rights of the user we logged in with.
SCP - secure file copying
SCP is an integral part of the OpenSSH package. It is a simple command allowing to copy any file or folder to or from a remote machine using the SSH protocol. The SSH+SCP duo is a great replacement of the non-secure FTP protocol which is widely used by the Internet users nowadays. Not everyone is aware of the fact though, that all the passwords sent while using the FTP protocol are transferred over the network in a plain text format (making it dead easy for crackers to take over) - SCP is a much more reliable alternative. The simplest usage of SCP looks like on the following example:
scp file.txt user1@remote_server:~/
This will copy the local file.txt to the remote server and put it in the home folder of user1. Instead of ~/, a different path can be supplied, i.e. /tmp, /home/public, and any other path we have write access to.
In order to copy a file from a remote server to the local computer, we can use another SCP syntax:
scp user1@remote_server:~/file.txt .
This will copy a file file.txt located in a home folder of user user1 of a remote system to the local folder (the one we are currently in).
Other interesting SCP options:
- -r - to copy folders recursively (including subfolders),
- -P port - to use a non-standard port (the default is 22) - of course this option should be used if the server listens on a non-standard port. The option can be helpful when connecting from a firewall-protected network. Setting the SSH server to listen on 443 port (used for secure HTTP connections) is the best way to by-pass the administrator's restrictions.
GUIs for SCP
If we do not like the console and we prefer GUI (graphical user interface), we can use a graphical (or pseudo-graphical) SCP client. Midnight Commander is one of the programs that provides an SCP client (option shell link). Nautilus and Konqueror are the SCP-capable file managers as well. Entering ssh://user1@remote_server:~/ in the URI field results in a secure shell connection to the remote system. The files can be then copied just as they were available locally.
In the MS Windows environment, we have a great app called WinSCP. The interface of this program looks very much like Total Commander. By the way, there is a plug-in allowing for SCP connections from TC as well.
SSH without passwords - generating keys
Entering passwords upon every SSH connection can be annoying. On the other hand, unprotected remote connection is a huge security risk. The solution to this problem is authorization using the private-public key-pair.
The pair of keys is usually generated using the ssh-keygen command. Below, there is a sample effect of such key generation. RSA or DSA keys can be used.
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key
(/home/user1/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
/home/user1/.ssh/id_rsa.
Your public key has been saved in
/home/user1/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
When the program asks for the key password, we should just press ENTER - this way, a passwordless key will be created. Remember that this is always a security hole to have a passwordless key (in simple words, doing that downgrades your remote system security to the security of your local system) so do it on your own risk. As the ssh-keygen finishes its work, you can see that two keys have been generated. The private key landed in /home/user1/.ssh/id_rsa and we should never make this public. The second public key appeared in /home/user1/.ssh/id_rsa.pub and this is the one we can show the entire world.
Now, if we want to access a remote system from our local computer without passwords (only using the keys), we have to add the information about our public key to the authorized_keys file located in ~/.ssh folder on the remote system. This can be done using the following commands:
$ scp /home/user1/.ssh/id_rsa.pub \
user1@remote_server:~/
$ ssh user1@remote_server
$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
The third command will be obviously executed on a remote server. After this operation, all actions performed on the remote server with SSH will not need any password whatsoever. This will certainly make our work easier.
Notice that if you need password less access from the remote server to the local one, the similar procedure has to be performed from the remote server. Authorization using keys is a one-way process. The private key can verify the public one, not vice-versa.
Executing commands on a remote system
Well, now when we can already log into remote OS without the password, why wouldn't we want to execute some command remotely? There can be multiple useful appliances of this, especially when we have to execute some command on a daily basis, and it could not be automated before, because of the need to enter the password manually (or enter it as plain text which is not very secure).
One interesting case is a “remote alert”. Let's say that we have some crucial process running on the remote system, i.e. a website running on Apache server. We want be be warned when the system gets out of resources (i.e. the disk space is getting short or the system load is too high). We could obviously send an e-mail in such cases. But additionally, we can execute a remote command which plays a warning sound on our local OS! The code for such event would look something like that:
ssh user1@local_server 'play \
/usr/share/sounds/gaim/arrive.wav'
This command, executed in a script from the remote server would cause a passwordless login of user1 to the local_server (the one we're usually working on) and play a wave file with the play command (which is usually available in Linux). The actual case in which we execute this remote command should obviously be specified in a script, but we're not going to provide a scripting course here, but a way to execute remote commands with password less SSH :).
X11 forwarding - running graphical apps remotely
One of the least known functions of SSH is X protocol forwarding. This enables us to run almost every X application remotely! It's enough to connect to the remote server using the -X option:
ssh -X user1@remote_serwer
and the display of every X application executed from now on will be forwarded to our local X server. We can configure the X11 Forwarding permanently by editing the /etc/ssh/ssh_config file (relevant option is ForwardX11 yes). Of course for the option to work, the remote SSH server needs to support X11 forwarding as well. The /etc/ssh/sshd_config file is responsible for that. This option is however configured by default in most of the Linux distros.
If we just need to execute one single command, we can use the syntax we learned before:
ssh -X user1@remote_serwer 'psi'
- this will execute PSI instant messenger on the remote server, passing the display to the local screen.
Of course the speed of applications executed remotely depends mostly on the network connection speed. It works almost flawlessly in local networks (even things like forwarding Totem playing a DivX movie). In case of Internet connection, a DSL seems reasonable to get apps like Skype or Thunderbird work quite well with a remote call.
Notice that it's also possible to connect to the remote server without the X11 forwarding enabled, export the DISPLAY variable to point to the local machine and then run the X application. This way, the application would be executed with a remote display, using the generic X server functionality. SSH security would not be applied in such case since this kind of configuration has nothing to do with SSH. Depending on the configuration of the local X server, it may be that the authorization of the remote X applications needs to be turned on in such case. This is usually done by the command xhost. For example, xhost + hostname accepts all the remote applications from the specified hostname for a while. If we plan to use this option regularly, a more secure X server configuration is recommended.
SSHFS - mounting a remote folder
Working on a file located on some remote server via SSH can be quite annoying especially when we need often copy different files in both directions. Using a the fish:// protocol in Midnight Commander or Konqueror is a partly solution - fish tends to be much slower than pure SSH and it often slows down even more while copying files. The ideal solution would be a possibility to mount a remote resource available through SSH only. The good news is that… this option exists for a while already, thanks to sshfs and the fuse project.
Fuse is a kernel module (recently it has been adopted in the official 2.6 series) allowing for mounting different file systems by an unprivileged user. SSHFS is a program created by the author of fuse himself which enables to mount remote folders/file systems using SSH. The idea is very simple - a remote SSH folder is mounted as a local folder in the file system. Since then, almost all operations on this folder work exactly as if this was a normal local folder. The difference is that the files are silently transferred though SSH in the background.
Installing fuse and sshfs in Ubuntu is as easy as entering (as root):
# apt-get install sshfs
The only remaining action is adding the user that we want to give the permission to mount SSH folders to the fuse group (using a command like usermod -G -a fuse user1 or manually editing the /etc/group file). Eventually, the fuse module needs to be loaded:
# modprobe fuse
And then, after logging in, we can try to mount a remote folder using sshfs:
mkdir ~/remote_folder
sshfs user1@remote_server:/tmp ~/remote_folder
The command above will cause the folder /tmp on the remote server to be mounted as ~/remote_folder on the local machine. Copying any file to this folder will result in transparent copying over the network using SCP. Same concerns direct file editing, creating or removing.
When we're done working with the remote filesystem, we can unmount the remote folder by issuing:
fusermount -u ~/remote_folder
If we work on this folder on a daily basis, it is wise to add it to the /etc/fstab table. This way is can be automatically mounted upon system boot or mounted manually (if noauto option is chosen) without the need to specify the remote location each time. Here is a sample entry in the table:
sshfs#user1@remote_server:/tmp \
/home/user1/remote_folder/ fuse defaults,auto 0 0
If we want to use fuse and sshfs regularly, we need to edit the /etc/modules file adding the fuse entry. In other case we would have to load the module manually each time we want to use it.
Summary
As you can see, SSH is a powerful remote access tool. If we need to work with remote UNIX file systems often, it's really worth to learn a few powerful features of SSH and use them in practice. SSH can really make your daily work much more effective and pleasant at the same time. In the following article (to be published later this month) we're going to cover another great feature of SSH: making different kinds of tunnels with port forwarding using transparent socks and a corkscrew
The original article was written by Borys Musielak. I've placed the article here for archiving purposes. I've also made some amendments to the original article.
|