Eleven SSH Tricks
SSH is the descendant of rsh and rlogin, which are non-encrypted programs for remote shell logins. Rsh and rlogin, like telnet, have a long lineage but now are outdated and insecure. However, these programs evolved a surprising number of nifty features over two decades of UNIX development, and the best of them made their way into SSH. Following are the 11 tricks I have found useful for squeezing the most power out of SSH.
OpenSSH is the most common free version of SSH and is available for virtually all UNIX-like operating systems. It is included by default with Debian, SuSE, Red Hat, Mandrake, Slackware, Caldera and Gentoo Linux, as well as OpenBSD, Cygwin for Windows and Mac OS X. This article is based on OpenSSH, so if you are using some other version, check your documentation before trying these tricks.
You can encrypt X sessions over SSH. Not only is the traffic encrypted, but the DISPLAY environment variable on the remote system is set properly. So, if you are running X on your local computer, your remote X applications magically appear on your local screen.
Turn on X11 forwarding with ssh -X host. You should use X11 forwarding only for remote computers where you trust the administrators. Otherwise, you open yourself up to X11-based attacks.
A nifty trick using X11 forwarding displays images within an xterm window. Run the web browser w3m with the in-line image extension on the remote machine; see the Debian package w3m-img or the RPM w3m-imgdisplay. It uses X11 forwarding to open a borderless window on top of your xterm. If you read your e-mail remotely using SSH and a text-based client, it then is possible to bring up in-line images over the same xterm window.
SSH looks for the user config file in ~/.ssh/config. A sample might look like:
ForwardX11 yes Protocol 2,1
Using ForwardX11 yes is the same as specifying -X on the command line. The Protocol line tells SSH to try SSH2 first and then fall back to SSH1. If you want to use only SSH2, delete the ,1.
The config file can include sections that take effect only for certain remote hosts by using the Host option. Another useful config file option is User, which specifies the remote user name. If you often log in to a machine with ssh -l remoteuser remotehost or ssh remoteuser@remotehost, you can shorten this by placing the following lines in your config file:
Host remotehost ForwardX11 yes User remoteuser Host * ForwardX11 no
Now, you can type ssh remotehost to log on as user remoteuser with the ForwardX11 option turned on. Otherwise, ForwardX11 is turned off, as recommended above. The asterisk matches all hosts, including hosts already matched in a Host section, but only the first matching option is used. Put specific Host sections before generic sections in your config file.
A system-wide SSH config file, /etc/ssh/ssh_config, also is available. SSH obtains configuration data in the following order: command-line options, user's configuration file and system-wide configuration file. All of the options can be explored by browsing man ssh_config.
SSH can use gzip compression on any connection. The default compression level is equivalent to approximately 4× compression for text. Compression is a great idea if you are forwarding X sessions on a dial-up or slow network. Turn on compression with ssh -C or put Compression yes in your config file.
Another speed tweak involves changing your encryption cipher. The default cipher on many older systems is triple DES (3DES), which is slower than Blowfish and AES. New versions of OpenSSH default to Blowfish. You can change the cipher to blowfish with ssh -c blowfish.
Cipher changes to your config file depend on whether you are connecting with SSH1 or SSH2. For SSH1, use Cipher blowfish; for SSH2, use:
Ciphers blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc











This week 5 lucky Members will receive a copy of The Official Ubuntu Server Book by Benjamin Mako Hill and Linux Journal's very own Kyle Rankin. No entry necessary. Check back here early next week to find out who the lucky Online Members are.




Comments
Headings
While very useful, this article is in dire need of some styled headings to define each of the 11 tips visually. Some headline tags (h1, h2, etc) or even a little bold text would be very helpful!
Traveling, Insecure Computers
Using your own copy of ssh when using a computer you don't trust doesn't accomplish much. A keylogger that records what you type will record the password you type.
Another idea would be to carry a bootable CD or memory stick with a complete OS that you trust. Knoppix is a good example. This will foil (nearly) any software based keylogger, but you can still be caught by a physical keylogger.
I carry a complete computer that I trust (therefore one not running Windows?) and I type my passwords on it. I also don't recycle passwords from one account on another account.
-kb
when i connect a system
when i connect a system using ssh it will display message are you sure you want to continue connecting?but i want to go without this message display
UNwelcome banner
You will need root access to the ssh server, open /etc/sshd_config with your favourite editor and comment out the line containing "Banner /etc/issue.net"
Done
Need help
Hi
I am facing some problem with cywin.
I installed cygwin and the installation was successful
I developed a .Net program exe and put it under /cygwin/home/username folder
Now while I am making a ssh call from cygwin command line to that exe application , I get the response as required.
But the same call from the web console is not getting any response.
Its seems like the web console is not making a call the that application.
I got stuck now at this position. Do I need to do some configuration on Cywin to make it accept web request.
Or do i need anything else.
Any help will be highly appreciated.
Good reference article
SSH is one of those things I use intensively for a little bit and then go months without thinking about - which means I forget everything between uses. This article is a good reference/checkpoint. Thanks!
One more tip:
GSSAPIAuthentication takes time during initial connection. Set it to "no" in the sshd_config and connections will speed up some.
Dave T.
Dave Turvene
Article
Thank you. I found your article very useful. Practical tips I can use right away.
Great article
Daniel, i have had to deal with clients who have their mail port blocked and this is a great work around. Thank you very much for a very well written and informative article.
Great article/tuto
thanks, this is great article base to start with.
Re: Eleven SSH Tricks
> Hello.
>
>
> In the article "Eleven SSH Tricks" for Linux Journal, you mention:
>
> >You can configure the OpenSSH daemon to refuse port forwarding with
> >AllowTcpForwarding no, but a determined user can forward anyway.
>
> How can this be done?
from 'man sshd_config' (on debian linux):
AllowTcpForwarding
Specifies whether TCP forwarding is permitted. The default is
``yes''. Note that disabling TCP forwarding does not improve
security unless users are also denied shell access, as they can
always install their own forwarders.
If you trust a user enough to give them ssh access, they
may have the means to forward (at least high-numbered) ports elsewhere.
The converse, allowing ssh but denying shell access, is an issue for
anonymous ssh connections, as with AnonCVS- in this case, turning off
AloowTcpForwarding is a very good idea:
http://seclists.org/lists/bugtraq/2004/Sep/0019.html
-Daniel Allen
I keep seeing vague
I keep seeing vague references to AllowTcpForwarding being an incomplete solution, but no specific examples of what that means. What does "they can always install their own forwarders" mean? Is it a SSH specific risk or a risk inherent to any shell access (like telnet)? i.e. is there still some way to tunnel traffic through the SSH connection or do they just mean that the user can fire up other processes on the server to do there funny business?
If it's just a risk inherent to giving shell access, then IMHO it's pretty irresponsible to suggest in the man page that "disabling TCP forwarding does not improve security". Does it prevent any and all connectivity to hosts other than the SSH server...of course not. That's a far cry from "does not improve security".
Shell access implies can tunnel
http://www.nyangau.fsnet.co.uk/tunnel/tunnel.htm
http://www.nyangau.fsnet.co.uk/tunnel/tunnel.zip
show how how to tunnel through
ssh (even if AllowTcpForwarding no)
telnet (even though it has no forwarding feature)
{{{ Andy
Re: Eleven SSH Tricks
In the section Running Remote Shell Commands, perl seems a little overkill for running those consecutive ssh commands. You can replace the little perl code by straight bash:
for i in `seq 1 12`; do ssh server$i "w"; done
Even better...
Why use backticks? This is also equivalent:
for i in {1..12} ; do ssh server$i "w" ; done
(or, in zsh)
for i in {1..12} ; ssh server$i "w"
Aren't you forgetting something?
SSH sends STDIN to the remote machine when it is run. Which will restult in you SSHing to server$1 and sending {2..12} to the STDIN on the remote connection clearing the STDIN on the local machine.
The fix is simple though:
for i in {1..12}; do ssh -n server$i "w"; done
or
for i in {1..12}; do ssh server$i "w" < /dev/null; done
Solution given works, fine your solution is unnecessary.
There's nothing being sent to stdin on the remote machine. {2..12} is expanded by the shell to the numbers 1 through 12 as part of a command. It doesn't become stdin. Your solution is unnecessary.
Correction re: Tunnelled Connections
I believe I made a mistake in the "Tunnelled Connections" example- In the fourth paragraph, "tell your mail transport agent" should read "tell your mail user agent". In other words, change the settings in your email program.
The other situation, where you're running your own sendmail/postfix/exim and want to send out mail to the world, punching though an ISP firewall, is only possible if you have access to a mail relay running a ssh server to relay all your outgoing email, which is nearly the same as the above situation with a remote SMTP server.
Since there needs to be a server receiving the SSH connection at the other end, you'd otherwise need to figure out how to set up your mail server to establish a SSH connection to every server you emailed to, which isn't possible with regular SMTP.
Perhaps ultimately we should be happy for that, since if a way to transparently send SMTP over SSH were available, most ISPs would then be compelled to block all ports to prevent SSH connections, instead of only blocking SMTP ports to block spammers, and we'd all have yet another reason to hate spammers...
-Daniel Allen
Good Postfix tunnel instructions
How to make Postfix use a tunnel
Re: Eleven SSH Tricks
One trick I use a lot: set up aliases based on your known_hosts file so you get proper hostname completion. Try sticking this in ~/.bashrc:
if [ -f ~/.ssh/known_hosts ] ; then
while read host junk
do
host=${host%%,*}
alias "${host}=ssh ${host}"
done
fi
-Dom
Re: Eleven SSH Tricks
Use the bash-completion package, it already does this.
Re: Eleven SSH Tricks
I just wanted to say thanks for a great article which taught me several really useful new things.
ZB
Post new comment