This way, if you type ssh forwardpop you receive the same
result as in the first example. This example uses the Host
command described above and the HostName command, which
specifies a real hostname with which to connect.

Finally, a command similar to LocalForward, called
RemoteForward, forwards a port from the computer to which you are
connected, to your computer. Please read the ssh_config man pages to
find out how.

The first example pipes myfile to lpr running on the machine named
desktop. The second example creates a tar file and writes it to the
terminal (because the tar file name is specified as dash), which is then piped
to the machine named desktop and redirected to a file.

Running Remote Shell Commands

With SSH, you don't need to open an interactive shell if you simply want
some output from a remote command, such as:

ssh user@host w

This command runs the command w on host as user and
displays the result. It can be used to automate commands, such as:

perl -e 'foreach $i (1 .. 12) \
{print `ssh server$i "w"`}'

Notice the back-ticks around the SSH command. This uses Perl to call SSH
12 times, each time running the command w on a
different remote host, server1 through server12.
In addition, you need to enter your password each time SSH
makes a connection. However, read on for a way to eliminate the password
requirement without sacrificing security.

Authentication

How does SSH authenticate that you should be allowed to connect?
Here are some options:

By hostnames only: uses .rhosts file; insecure; disabled by default.

By hostnames and host-key checking.

The S/Key one-time password system.

Kerberos: private-key encryption with time-expired
“tickets”.

Smart card.

Password prompt.

Public key.

The most common authentication method is by password prompt, which is
how most SSH installations are run out of the box.

However, public key encryption is worth investigating; it is considerably
more secure than passwords, and by using it you can do away with all
or most of your password typing.

Briefly, public key encryption relies on two keys: a public key
to encrypt, which you don't keep secret, and a private key to
decrypt, which is kept private on your local computer.
The general idea is to run ssh-keygen to generate your keys.
Press Return when it asks you for a passphrase. Then copy your public
key to the remote computer's authorized_keys file.

The details depend on whether the computer to which you are connecting uses
SSH1 or SSH2. For SSH1 type ssh-keygen -t rsa1,
and copy ~/.ssh/identity.pub to the end of the file
~/.ssh/authorized_keys on the remote computer. For SSH2, type
ssh-keygen -t rsa,
and copy ~/.ssh/id_rsa.pub to the end of the file
~/.ssh/authorized_keys on the remote computer. This file
might be called ~/.ssh/authorized_keys2, depending on your
OpenSSH version. If the first one doesn't work, try the second.
The payoff is you can log in without typing a password.

You can use a passphrase that keeps
the private key secret on your local computer. The passphrase encrypts
the private key using 3DES. At no time is your passphrase or any secret
information sent over the network. You still have to enter the passphrase
when connecting to a remote computer.

Authentication Agent

You might wonder: if we want to use a passphrase, are we stuck back
where we started, typing in a passphrase every time we log in? No.
Instead, you can use a passphrase, but type it only once instead of every time
you use the private key. To set up this passphrase, execute
ssh-agent when you first start
your session. Then execute ssh-add, which prompts
for your passphrase and stores it in memory, not on disk. From then on,
all connections authenticating with your private key use the version
in memory, and you won't be asked for a password.

Your distribution may be set up to start ssh-agent
when you start X. To see if it's already running, enter
ssh-add -L.
If the agent is not running already, you need to
start it, which you can do by adding it to your
.bash_login, logging out and logging back in again.

Comments

Comment viewing options

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:

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.

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.

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.

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

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

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

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.