Shh! OpenSSH Secrets Here

If you routinely use multiple computers, it can be a challenge to keep your data files organized and to manage multiple login IDs. OpenSSH can help you with those tasks. It’s a powerful, secure tool that lets you share files without having to set up a file server, run applications remotely, and perform remote administration chores quickly and securely. You probably already know how to use OpenSSH for file transfers. Here we’ll uncover some less well-known OpenSSH tricks that can make life easier for roaming computer users.

To use the software, you should have the OpenSSH server and client installed and working on all the computers you need to access. In this article I use local for the computer we’re launching an OpenSSH session from, andremote to refer to the computer we’re logging into.

One-Line Login and Command

Sometimes you just want to run a single command on a remote computer – for instance, to power it off. But thepoweroff command needs root privileges, and it’s bad security practice to allow remote root logins. With that in mind, check the /etc/ssh/sshd_config file on the remote machine and make sure this line exists:

PermitRootLogin no

If you have to add it, restart sshd.

A better approach is to set up a sudo user on the remote computer. Run visudo as root (on the remote machine) to open the sudo editor. Then add a line like

terry remote = /sbin/poweroff

using your own username and hostname, of course, in place of terry and remote. Save and close the file, and you’re done.

This example restricts user terry to running the poweroff command on the server named remote. You can give users more commands in a comma-delimited list, like this:

terry remote = /sbin/poweroff, /sbin/shutdown, /usr/sbin/ntpdate

sudo -l prompts for a password, then shows users what sudo commands they have access to:

$ sudo -l
[sudo] password for terry:
Matching Defaults entries for terry on this host:
    env_reset

User terry may run the following commands on this host:
    (root) /sbin/poweroff, (root) /sbin/shutdown, (root) /usr/sbin/ntpdate

Now you can run a remote poweroff command in one step, instead of first opening an SSH session and then running the command:

carla@local:~$ ssh terry@remote sudo poweroff

This technique works for any command or script.

Password-less SSH Logins

The above approach asks for a login password. An alternative security strategy, using password-less public key authentication, is more script-friendly, and as long as you protect your private key, it provides a high degree of security. If you enable public key authentication and disable password logins, you have immunity from brute-force password attacks.

To get started, first generate a new key pair on your local PC:

$ ssh-keygen -t rsa

Do not create a passphrase. By default this command creates two files in your ~/.ssh/ directory: id_rsa, your new private key, and id_rsa.pub, your new public key. Never ever share your private key! Copy your public key to the computer you will be logging into:

carla@local:~$ ssh-copy-id -i .ssh/id_rsa.pub terry@remote

ssh-copy-id copies your public key in the correct format into the correct file on the remote computer: either ~/.ssh/authorized_keys or ~/.ssh/authorized_keys2, depending on your Linux distribution, as defined in /etc/ssh/sshd_config.

Edit /etc/ssh/sshd_config on the remote computer and add this line if it’s not already there:

PubkeyAuthentication yes

If you change anything, restart sshd. Now try logging in:

carla@local:~$ ssh terry@remote

It should whisk you in without asking for a password.

You can create different keys for different computers; for example, this key is for a mailserver:

carla@local:~$ ssh-keygen -t rsa -C mailserver -f .ssh/mail-admin
carla@local:~$ ssh-copy-id -i .ssh/mail-admin.pub admin@mailserver

The -C option creates a comment inside the key, which is helpful for identifying it after it is copied to the authorized_keys file. Keys are in plain text, so you can see that the last part of the new mail-admin.pub key reads6rBQQf7 mailserver.

Next, enter the name of the new private key in /etc/ssh/ssh_config:

IdentityFile ~/.ssh/mail-admin

Now you can connect to the mailserver with the new key:

carla@local:~$ ssh -i mail-admin.pub admin@mailserver

Once you’ve tested your public key and ensured it’s working, you can disable password logins. Go back into /etc/ssh/sshd_config on the remote computer and change PasswordAuthentication yes toPasswordAuthentication no.

This technique lets you give users access to your computer without giving them a system account. If you give users unique keys labeled with comments to identify who they belong to, you can easily revoke access by deleting someone’s public key from the authorized_keys file.

Roaming Without Scattering Your Data

Flitting from laptop to tablet to desktop to server like free birds is convenient and fun, but having your data files scattered all over like birdseed is messy and inconvenient. One way to keep your data in one place is to have a single master computer, and use your other machines as remote terminals. With OpenSSH you can do this securely.

First make sure that X11Forwarding yes is enabled in /etc/ssh/sshd_config on any computer you want to access remotely. As long as that’s set you can run graphical applications remotely and securely through OpenSSH’s built-in X Windows proxy. For example, suppose you keep your email client (such as Kmail) and message store on your master computer. You can access it from any of your remote PCs with one command. Let’s suppose your master computer is a desktop PC, and you’re logging in to it from your laptop:

carla@laptop:~$ ssh -Y carla@desktop kmail

-Y forwards your X session, which you need to do in order to run graphical applications. The X Windows System and Kmail must be installed on your master PC, but do not need to be running. Now you can check and write email, and your email stays on your desktop computer, which is handy for those of us who prefer the speed and simplicity of POP mail. You can do this with any application that is installed on your master computer, graphical or console.

Sometimes this trick doesn’t work very well because your application is not network-friendly. For example, I useMoneydance for my personal finances, but it’s unusable over a network because it has killer lag, and screens take forever to redraw. Instead of trying to stuff Moneydance over the network when it obviously does not want to go there, I use sshfs to access its files on the master computer remotely. sshfs mounts remote directories over the network so you can access them just as though they were local directories. sshfs is perfect for anyone with multiple computers; using it is quicker and easier than setting up Samba or NFS, and your network transmissions are encrypted like any SSH session.

Once again let’s say you’re using a laptop and your files are on a desktop machine. First create a mountpoint on the laptop. I call mine sshfs:

carla@laptop:~$ mkdir sshfs

Then mount a remote directory like this:

carla@laptop:~$ sshfs carla@desktop:/home/carla/stuff sshfs/

You’ll need to enter your remote password (unless you’ve set up public key authentication), and then poof! Your remote files are now as good as local. You can do your work with local applications, and your data files are all in one place on your master PC. When you’re finished, unmount the remote directory with fusermount -u sshfs, replacing sshfs with your own mountpoint.