Eleven SSH Tricks

Run remote GUI applications and tunnel any Net connection securely using a free utility that's probably already installed on your system.
Authentication Agent Forwarding

If you connect from one server to another using public key authentication, you don't need to run an authentication agent on both. SSH automatically can pass any authentication requests coming from other servers, back to the agent running on your own computer. This way, it never passes your secret key to the remote computer; rather, it performs authentication on your computer and sends the results back to the remote computer.

To set up authentication agent forwarding, simply run ssh -A or add the following line to your config file:

ForwardAgent yes

You should use authentication agent forwarding only if you trust the administrators of the remote computer; you risk them using your keys as if they were you. Otherwise, it is quite secure.

Traveling with SSH Java Applet

Many people carry a floppy with PuTTY or another Windows SSH program, in case they need to use an unsecured computer while traveling. This method works if you have the ability to run programs from the floppy drive. You also can download PuTTY from the web site and run it.

Another alternative is putting an SSH Java applet on a web page that you can use from a browser. An excellent Java SSH client is Mindterm, which is free for noncommercial use. You can find it at www.appgate.com/mindterm.


An SSH configuration can go wrong in a few places if you are using these various tricks. You can catch many problems by using ssh -v and watching the output. Of course, none of these tricks is essential to using SSH. Eventually, though, you may encounter situations where you're glad you know them. So give a few of them a try.

Daniel R. Allen (da@coder.com) discovered UNIX courtesy of a 1,200-baud modem, a free local dial-up and a guest account at MIT, back when those things existed. He has been an enthusiastic Linux user since 1995. He is president of Prescient Code Solutions, a software consulting company in Kitchener, Ontario and Ithaca, New York.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

SOCKS proxy

dermoth's picture

This article misses one very useful trick; in addition to port-forwarding and tunneling, the ssh daemon supports SOCKS proxy functions, which means you can use any ssh-enabled hosts as a web proxy. Very useful when you need to test a page from a different country you have a server in, or when you want to access a restricted web administration interfaces by first logging into an inside server.

All you need to activate the SOCKS proxy function is to use the "-D [bind_addr:]port" switch. Ex:

$ ssh -D 8881 some-host.example.com

Then pointing your browser's SOCKS proxy config to localhost:8881 will let you proxy trough some-host.example.com.


willc's picture

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

Anonymous's picture

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.


when i connect a system

Anonymous's picture

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

Anonymous's picture

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"


Need help

Anonymous's picture


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

dturvene's picture

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


Mark Weste's picture

Thank you. I found your article very useful. Practical tips I can use right away.

Great article

Mario Zigliotto's picture

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

keyle's picture

thanks, this is great article base to start with.

Re: Eleven SSH Tricks

Anonymous's picture

> 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):

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:


-Daniel Allen

I keep seeing vague

Anonymous's picture

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

Andy Key's picture

show how how to tunnel through
ssh (even if AllowTcpForwarding no)
telnet (even though it has no forwarding feature)

{{{ Andy

Re: Eleven SSH Tricks

Anonymous's picture

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...

benizi's picture

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?

Adam Thomas's picture

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
for i in {1..12}; do ssh server$i "w" < /dev/null; done

Solution given works, fine your solution is unnecessary.

Mike MacCana's picture

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

Anonymous's picture

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

Anonymous's picture

How to make Postfix use a tunnel

Re: Eleven SSH Tricks

Anonymous's picture

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
alias "${host}=ssh ${host}"


Re: Eleven SSH Tricks

Anonymous's picture

Use the bash-completion package, it already does this.

Re: Eleven SSH Tricks

Anonymous's picture

I just wanted to say thanks for a great article which taught me several really useful new things.