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 the
poweroffcommand 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:
If you have to add it, restart sshd.
A better approach is to set up a
sudouser on the remote computer. Run
visudoas root (on the remote machine) to open the
sudoeditor. Then add a line like
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
poweroffcommand on the server named remote. You can give users more commands in a comma-delimited list, like this:
sudo -lprompts for a password, then shows users what sudo commands they have access to:
Now you can run a remote
poweroffcommand in one step, instead of first opening an SSH session and then running the command:
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:
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:
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:
If you change anything, restart sshd. Now try logging in:
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:
-Coption 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 reads
Next, enter the name of the new private key in /etc/ssh/ssh_config:
Now you can connect to the mailserver with the new key:
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
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 yesis 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:
-Yforwards 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
sshfsto 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.
sshfsis 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:
Then mount a remote directory like this:
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.