Five handy secure shell tips and tricks
I use secure shell a LOT, every day. So much so that I often take for granted how important this tool is. Not only does it allow me to log into remote machines to handle management of said machine, it can do other things as well - X tunneling being one of the most useful features. But for many users ssh only serves as a means to log in, do a few command-line tasks, and log out. It doesn't (and shouldn't) have to be that way.
With Secure Shell there are a number of ways to use (and configure) this tool to make it more useful and more secure. In this article  you will learn five different (and handy) secure shell tips to make sure your ssh usage is as good as it can be. And for some basic secure shell knowledge, check out my article "Get to know Linux: Secure shell".
Password-less logon
Have have dealt with this before (as a side note), but wanted to re-iterate this process. Because I use ssh so much I get tired of having to enter passwords constantly. Now I will preface this by saying only do this on a network you trust. Yes you will be logging into ssh with a certificate, and that certificate will be on your machine, but you don't want to employ this method on a network that can not be trusted. With that in mind, here are the steps for setting this up.
On the local machine issue the command:
ssh-keygen -t dsa
This command will generate a public key that will be then copied to your server. During this creation process you will be asked for a password - just press enter to use a blank password for this. You will have to verify the password, so hit enter again. )
With the key created you have to copy it to the server you want to ssh into. To do this enter the command:
ssh-copy-id -i .ssh/id_dsa.pub username@destination
Where username is the username you will be logging into on the remote server and destination is the IP address of the remote server.
Now when you go to secure shell into that remote machine you will not have to enter a password.
Block root login
Although secure shell is a secure means of logging into your server, you do not want to allow root access (for obvious reasons). Blocking root access is simple. Open up the /etc/ssh/sshd_config file and look for this line:
PermitRootLogin
and make sure it is set to "no" (no quotes). So the complete line will read:
PermitRootLogin no
Once you have saved that file, restart the ssh daemon with the command:
sudo /etc/init.d/ssh restart
Now the root user can no longer log in remotely via ssh.
Enable X tunneling
Secure shell is made even more powerful when you can run a remote X application on your local machine. And what is better is that it's not difficult at all. In order to allow X tunneling you will first need to open up the /etc/ssh/sshd_config file and search for this line:
X11Forwarding
and make sure it looks like:
X11Forwarding yes
Once that is set save the file, restart sshd, and you are ready to tunnel and X Windows application through ssh. To accomplish this you have to add the -X flag to your secure shell command like this:
ssh -v -l USERNAME IP_ADDRESS -X
Where USERNAME is the username you want to log in with and IP_ADDRESS is the actual IP address of the machine you are logging into.
Final thoughts
There are so many cool tricks and tips with secure shell, but the above three are, in my opinion, the most helpful. Have you come across a helpful ssh tip you'd like to share? Or are you looking for a particular behavior out of secure shell? If so. share with your fellow Ghacks readers.
Advertisement
X tunneling is nice. It’s like Remote Desktop Services of Windows 2008 R2. Going to have to follow your advice sir!
^agreed with Adam.
if you’re on a linux box tryin to remote thru ssh tunnel – i’d suggest to use an app called: GSTM
I find the built-in SOCKS proxy server (-D portnumber) is one of the most useful “extra” features of SSH.
The X tunnelling is great. Applications running over the network seem just as fast as if they were local.
The ssh keys bit isn’t quite right and there’s one important tip to highlight. Ssh needs the id_dsa.pub file to be stored on the distination machine as “$HOME/.ssh/authorized_keys” for it to work. But remember, the ssh daemon on the remote server it will only use the key if it’s sure it hasn’t been compromised. What this means in practice is that if the authorized_keys file OR ANY OF THE PATH TO IT, is writeable by anyone other than the user (and root), it will ignore the authorized_keys file. Too often I have seen people trying to understand why they’re authorized_keys file is not being used. To solve it they make everything permission “777”! Under most circumstances this would work, but with ssh this only makes things worse.
Also, I would recommend, rather than creating a keypair with no password, make use of ssh-agent. If you run everything as a sub process of ssh-agent (which a lot of windowing systems do for you by default) then you can use ssh-add to add the “unlocked” private key that uses a password. Then everything you do from then on won’t require a password each time you make a connection.
More detail could be added, but I’ve written more than most are likely to read.
@Ishan: I also shortchanged you on tips. I will make that up with more secure shell basics in future articles.
I’d like to point out using SSH keys without passwords kind of defeats the purpose. It is convenient, but that’s not what it’s meant for (well maybe it is since OpenSSH devs allow an empty passphrase…).
I have a better suggestion: set up SSH-agent, load your keys when your session starts, and neve rlook back. If I’m not mistaken even with an empty passphrase, if the keys are not cached, you’ll still have to press Enter to get the authentication to continue. Cached keys are even easier – and far more safer than this widespread trick that is in fact bad practice.
I am really short handed in Secure Shell. Would have to first get my basics right, before I am able to use this advanced stuff.