rane 05/09/29 20:59:13
Added: xml/htdocs/doc/en/articles openssh-key-management-p1.xml
openssh-key-management-p2.xml
openssh-key-management-p3.xml
Log:
#99134: three new ssh articles
Revision Changes Path
1.1 xml/htdocs/doc/en/articles/openssh-key-management-p1.xml
file :
http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/openssh-key-management-p1.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/openssh-key-management-p1.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo
Index: openssh-key-management-p1.xml
===================================================================
<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header:
/var/cvsroot/gentoo/xml/htdocs/doc/en/articles/openssh-key-management-p1.xml,v
1.1 2005/09/29 20:59:13 rane Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/en/articles/openssh-key-management-p1.xml">
<title>OpenSSH key management, Part 1</title>
<author title="Author">
<mail link="[EMAIL PROTECTED]">Daniel Robbins</mail>
</author>
<!-- xmlified by Max Lorenz ([EMAIL PROTECTED]) -->
<abstract>
In this series, you'll learn how RSA and DSA authentication work, and see how
to set up passwordless authentication the right way. In the first article of
the series, Daniel Robbins focuses on introducing the RSA and DSA
authentication protocols and showing you how to get them working over the
network.
</abstract>
<!-- The original version of this article was first published on IBM
developerWorks, and is property of Westtech Information Services. This
document is an updated version of the original article, and contains
various improvements made by the Gentoo Linux Documentation team -->
<version>1.0</version>
<date>2005-09-29</date>
<chapter>
<title>Understanding RSA/DSA authentication</title>
<section>
<body>
<p>
Many of us use the excellent OpenSSH (see <uri
link="#resources">Resources</uri> later in this article) as a secure, encrypted
replacement for the venerable <c>telnet</c> and <c>rsh</c> commands. One of
OpenSSH's more intriguing features is its ability to authenticate users using
the RSA and DSA authentication protocols, which are based on a pair of
complementary numerical keys. As one of its main appeals, RSA and DSA
authentication promise the capability of establishing connections to remote
systems <e>without supplying a password</e>. While this is appealing, new
OpenSSH users often configure RSA/DSA the quick and dirty way, resulting in
passwordless logins, but opening up a big security hole in the process.
</p>
</body>
</section>
<section>
<title>What is RSA/DSA authentication?</title>
<body>
<p>
SSH, specifically OpenSSH (a completely free implementation of SSH), is an
incredible tool. Like <c>telnet</c> or <c>rsh</c>, the ssh client can be used
to log in to a remote machine. All that's required is for this remote machine
to be running <c>sshd</c>, the <c>ssh</c> server process. However, unlike
<c>telnet</c>, the ssh protocol is very secure. It uses special algorithms to
encrypt the data stream, ensure data stream integrity and even perform
authentication in a safe and secure way.
</p>
<p>
However, while <c>ssh</c> is really great, there is a certain component of
<c>ssh</c> functionality that is often ignored, dangerously misused, or simply
misunderstood. This component is OpenSSH's RSA/DSA key authentication system,
an alternative to the standard secure password authentication system that
OpenSSH uses by default.
</p>
<p>
OpenSSH's RSA and DSA authentication protocols are based on a pair of specially
generated cryptographic keys, called the <e>private key</e> and the <e>public
key</e>. The advantage of using these key-based authentication systems is that
in many cases, it's possible to establish secure connections without having to
manually type in a password.
</p>
<p>
While the key-based authentication protocols are relatively secure, problems
arise when users take certain shortcuts in the name of convenience, without
fully understanding their security implications. In this article, we'll take a
good look at how to correctly use RSA and DSA authentication protocols without
exposing ourselves to any unnecessary security risks. In my next article, I'll
show you how to use <c>ssh-agent</c> to cache decrypted private keys, and
introduce <c>keychain</c>, an <c>ssh-agent</c> front-end that offers a number
of convenience advantages without sacrificing security. If you've always wanted
to get the hang of the more advanced authentication features of OpenSSH, then
read on.
</p>
</body>
</section>
<section>
<title>How RSA/DSA keys work</title>
<body>
<p>
Here's a quick general overview of how RSA/DSA keys work. Let's start with a
hypothetical scenario where we'd like to use RSA authentication to allow a
local Linux workstation (named <e>localbox</e>) to open a remote shell on
<e>remotebox</e>, a machine at our ISP. Right now, when we try to connect to
<e>remotebox</e> using the <c>ssh</c> client, we get the following prompt:
</p>
<pre caption="Connecting to remotebox">
$ <i>ssh [EMAIL PROTECTED]</i>
[EMAIL PROTECTED]'s password:
</pre>
<p>
Here we see an example of the <c>ssh</c> <e>default</e> way of handling
authentication. Namely, it asks for the password of the <e>drobbins</e> account
on <e>remotebox</e>. If we type in our password for <e>remotebox</e>,
<c>ssh</c> uses its secure password authentication protocol, transmitting our
password over to <e>remotebox</e> for verification. However, unlike what
<c>telnet</c> does, here our password is encrypted so that it can not be
intercepted by anyone sniffing our data connection. Once <e>remotebox</e>
authenticates our supplied password against its password database, if
successful, we're allowed to log on and are greeted with a <e>remotebox</e>
shell prompt. While the <c>ssh</c> default authentication method is quite
secure, RSA and DSA authentication open up some new possibilities.
</p>
<p>
However, unlike the <c>ssh</c> secure password authentication, RSA
authentication requires some initial configuration. We need to perform these
initial configuration steps only once. After that, RSA authentication between
<e>localbox</e> and <e>remotebox</e> will be totally painless. To set up RSA
authentication, we first need to generate a pair of keys, one private and one
public. These two keys have some very interesting properties. The public key
can be used to encrypt a message, and only the holder of the private key can
decrypt it. The public key can only be used for <e>encryption</e>, and the
private key can only be used for <e>decryption</e> of a message encoded by the
matching public key. The RSA (and DSA) authentication protocols use the special
properties of key pairs to perform secure authentication, without needing to
transmit any confidential information over the network.
</p>
<p>
To get RSA or DSA authentication working, we perform a single one-time
configuration step. We copy our <e>public key</e> over to <e>remotebox</e>.
The public key is called "public" for a reason. Since it can only be used to
<e>encrypt</e> messages for us, we don't need to be too concerned about it
falling into the wrong hands. Once our public key has been copied over to
<e>remotebox</e> and placed in a special file
(<path>~/.ssh/authorized_keys</path>) so that <e>remotebox</e>'s <c>sshd</c>
can locate it, we're ready to use RSA authentication to log onto
<e>remotebox</e>.
</p>
<p>
To do this, we simply type <c>ssh [EMAIL PROTECTED]</c> at <e>localbox</e>'s
console, as we always have. However, this time, <c>ssh</c> lets
<e>remotebox</e>'s <c>sshd</c> know that it would like to use the RSA
authentication protocol. What happens next is rather interesting.
<e>Remotebox</e>'s <c>sshd</c> generates a random number, and encrypts it using
our public key that we copied over earlier. Then, it sends this encrypted
random number back to the <c>ssh</c> running on <e>localbox</e>. In turn, our
<c>ssh</c> uses our <e>private key</e> to decrypt this random number, and then
sends it back to <e>remotebox</e>, saying in effect "See, I really <e>do</e>
hold the matching private key; I was able to successfully decrypt your
message!" Finally, <c>sshd</c> concludes that we should be allowed to log in,
since we hold a matching private key. Thus, the fact that we hold a matching
private key grants us access to <e>remotebox</e>.
</p>
</body>
</section>
<section>
<title>Two observations</title>
<body>
<p>
There are two important observations about the RSA and DSA authentication. The
first is that we really only need to generate one pair of keys. We can then
copy our public key to the remote machines that we'd like to access and they
will all happily authenticate against our single private key. In other words,
we don't need a key pair for <e>every</e> system we'd like to access. Just one
pair will suffice.
</p>
<p>
The other observation is that our <e>private key should not fall into the wrong
hands</e>. The private key is the one thing that grants us access to our remote
systems, and anyone that possesses our private key is granted exactly the same
privileges that we are. Just as we wouldn't want strangers to have keys to our
house, we should protect our private key from unauthorized use. In the world of
bits and bytes, this means that no one should be able to read or copy our
private key.
</p>
<p>
Of course, the <c>ssh</c> developers are aware of the private keys' importance,
and have built a few safeguards into <c>ssh</c> and <c>ssh-keygen</c> so that
our private key is not abused. First, <c>ssh</c> is configured to print out a
big warning message if our key has file permissions that would allow it to be
read by anyone but us. Secondly, when we create our public/private key pair
using <c>ssh-keygen</c>, <c>ssh-keygen</c> will ask us to enter a passphrase.
If we do, our private key will be encrypted using this passphrase, so that even
1.1 xml/htdocs/doc/en/articles/openssh-key-management-p2.xml
file :
http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/openssh-key-management-p2.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/openssh-key-management-p2.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo
Index: openssh-key-management-p2.xml
===================================================================
<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header:
/var/cvsroot/gentoo/xml/htdocs/doc/en/articles/openssh-key-management-p2.xml,v
1.1 2005/09/29 20:59:13 rane Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/en/articles/openssh-key-management-p2.xml">
<title>OpenSSH key management, Part 2</title>
<author title="Author">
<mail link="[EMAIL PROTECTED]">Daniel Robbins</mail>
</author>
<abstract>
Many developers use the excellent OpenSSH as a secure, encrypted replacement
for the venerable telnet and rsh commands. One of OpenSSH's more intriguing
features is its ability to authenticate users using the RSA and DSA
authentication protocols, which are based upon a pair of complementary
numerical "keys". One of the main appeals of RSA and DSA authentication is the
promise of being able to establish connections to remote systems without
supplying a password. In this second article, Daniel introduces ssh-agent (a
private key cache) and keychain, a special bash script designed to make
key-based authentication incredibly convenient and flexible.
</abstract>
<!-- The original version of this article was first published on IBM
developerWorks, and is property of Westtech Information Services. This
document is an updated version of the original article, and contains
various improvements made by the Gentoo Linux Documentation team -->
<version>1.0</version>
<date>2005-09-29</date>
<chapter>
<title>Introducing ssh-agent and keychain</title>
<section>
<title>Introducing ssh-agent</title>
<body>
<p>
ssh-agent, included with the OpenSSH distribution, is a special program
designed to make dealing with RSA and DSA keys both pleasant and secure (see
Part 1 of this series for an introduction to RSA and DSA authentication.)
ssh-agent, unlike ssh, is a long-running daemon designed for the sole purpose
of caching your decrypted private keys.
</p>
<p>
ssh includes built-in support that allows it to communicate with ssh-agent,
allowing ssh to acquire your decrypted private keys without prompting you for a
password for every single new connection. With ssh-agent you simply use ssh-add
to add your private keys to ssh-agent's cache. It's a one-time process; after
using ssh-add, ssh will grab your private key from ssh-agent, rather than
bugging you by prompting for a passphrase.
</p>
</body>
</section>
<section>
<title>Using ssh-agent</title>
<body>
<p>
Let's take a look at how this whole ssh-agent key caching system works. When
ssh-agent starts up, it spits out a few important environment variables before
detaching from the shell and continuing to run in the background. Here's some
example output generated by ssh-agent when it begins:
</p>
<pre caption="Running ssh-agent daemon">
$ <i>ssh-agent</i>
SSH_AUTH_SOCK=/tmp/ssh-XX4LkMJS/agent.26916; export SSH_AUTH_SOCK;
SSH_AGENT_PID=26917; export SSH_AGENT_PID;
echo Agent pid 26917;
</pre>
<p>
As you can see, ssh-agent's output is actually a series of bash commands; if
executed, these commands would set a couple of environment variables,
SSH_AUTH_SOCK and SSH_AGENT_PID. Due to the included export commands, these
environment variables would be made available to any additional commands run
later. Well, all that would happen if these lines were actually evaluated by
the shell, but right now they're simply printed to stdout. To fix this, we can
invoke ssh-agent in the following way:
</p>
<pre caption="Different way of invoking ssh-agent">
$ <i>eval `ssh-agent`</i>
</pre>
<p>
This command tells bash to run ssh-agent and then evaluate ssh-agent's output.
Invoked this way (with back-quotes, not normal single quotes), the
SSH_AGENT_PID and SSH_AUTH_SOCK variables get set and exported by your shell,
making these variables available to any new processes you may start during your
login session.
</p>
<p>
The best way to start ssh-agent is to add the above line to your
~/.bash_profile; that way, all programs started in your login shell will see
the environment variables, be able to locate ssh-agent and query it for keys as
needed. The environment variable of particular importance is SSH_AUTH_SOCK; the
SSH_AUTH_SOCK contains a path to a UNIX domain socket that ssh and scp can use
to establish a dialogue with ssh-agent.
</p>
</body>
</section>
<section>
<title>Using ssh-add</title>
<body>
<p>
But of course, ssh-agent starts up with an empty cache of decrypted private
keys. Before we can really use ssh-agent, we first need to add add our private
key(s) to ssh-agent's cache using the ssh-add command. In the following
example, I use ssh-add to add my <path>~/.ssh/identity</path> private RSA key
to ssh-agent's cache:
</p>
<pre caption="Loading private RSA key to ssh-agent's cache">
# <i>ssh-add ~/.ssh/identity</i>
Need passphrase for /home/drobbins/.ssh/identity
Enter passphrase for /home/drobbins/.ssh/identity
(enter passphrase)
</pre>
<p>
As you can see, ssh-add asked for my passphrase so that the private key can be
decrypted and stored in ssh-agent's cache, ready for use. Once you've used
ssh-add to add your private key (or keys) to ssh-agent's cache and
SSH_AUTH_SOCK is defined in your current shell (which it should be, if you
started ssh-agent from your ~/.bash_profile), then you can use scp and ssh to
establish connections with remote systems without supplying your passphrase.
</p>
</body>
</section>
<section>
<title>Limitations of ssh-agent</title>
<body>
<p>
ssh-agent is really cool, but its default configuration still leaves us with a
few minor inconveniences. Let's take a look at them.
</p>
<p>
For one, with <c>eval `ssh-agent`</c> in <path>~/.bash_profile</path>, a new
copy of ssh-agent is launched for every login session; not only is this a tad
bit wasteful, but it also means that you need to use ssh-add to add a private
key to each new copy of ssh-agent. If you only open a single terminal or
console on your system, this is no big deal, but most of us open quite a few
terminals and need to type in our passphrase every single time we open a new
console. Technically, there's no reason why we should need to do this since a
single ssh-agent process really should suffice.
</p>
<p>
Another problem with the default ssh-agent setup is that it's not compatible
with cron jobs. Since cron jobs are started by the cron process, they won't
inherit the SSH_AUTH_SOCK variable from their environment, and thus won't know
that a ssh-agent process is running or how to contact it. It turns out that
this problem is also fixable.
</p>
</body>
</section>
<section>
<title>Enter keychain</title>
<body>
<p>
To solve these problems, I wrote a handy bash-based ssh-agent front-end called
keychain. What makes keychain special is the fact that it allows you to use a
single ssh-agent process per system, not just per login session. This means
that you only need to do one ssh-add per private key, period. As we'll see in a
bit, keychain even helps to optimize the ssh-add process by only trying to add
private keys that aren't already in the running ssh-agent's cache.
</p>
<p>
Here's a run-through of how keychain works. When started from your
<path>~/.bash_profile</path>, it will first check to see whether an ssh-agent
is already running. If not, then it will start ssh-agent and record the
important SSH_AUTH_SOCK and SSH_AGENT_PID variables in the
<path>~/.ssh-agent</path> file for safe keeping and later use. Here's the best
way to start keychain; like using plain old ssh-agent, we perform the necessary
setup inside <path>~/.bash_profile</path>:
</p>
<pre caption="Settings for ssh-agent in ~/.bash_profile">
#!/bin/bash
#example ~/.bash_profile file
/usr/bin/keychain ~/.ssh/id_rsa
#redirect ~/.ssh-agent output to /dev/null to zap the annoying
#"Agent PID" message
source ~/.ssh-agent > /dev/null
</pre>
1.1 xml/htdocs/doc/en/articles/openssh-key-management-p3.xml
file :
http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/openssh-key-management-p3.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/openssh-key-management-p3.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo
Index: openssh-key-management-p3.xml
===================================================================
<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header:
/var/cvsroot/gentoo/xml/htdocs/doc/en/articles/openssh-key-management-p3.xml,v
1.1 2005/09/29 20:59:13 rane Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/en/articles/openssh-key-management-p3.xml">
<title>OpenSSH key management, Part 3</title>
<author title="Author">
<mail link="[EMAIL PROTECTED]">Daniel Robbins</mail>
</author>
<abstract>
In this third article in a series, Daniel Robbins shows you how to take
advantage of OpenSSH agent connection forwarding to enhance security. He also
shares recent improvements to the keychain shell script.
</abstract>
<!-- The original version of this article was first published on IBM
developerWorks, and is property of Westtech Information Services. This
document is an updated version of the original article, and contains
various improvements made by the Gentoo Linux Documentation team -->
<version>1.0</version>
<date>2005-09-29</date>
<chapter>
<title>Agent forwarding and keychain improvements</title>
<section>
<body>
<p>
Many of us use the excellent OpenSSH as a secure, encrypted replacement for the
venerable telnet and rsh commands. One of OpenSSH's more intriguing features is
its ability to authenticate users using the RSA and DSA authentication
protocols, which are based on a pair of complementary numerical "keys." One of
the main appeals of RSA and DSA authentication is the promise of being able to
establish connections to remote systems without supplying a password. For more
background, see the previous installments of this series on OpenSSH key
management, which cover <uri
link="/doc/en/articles/openssh-key-management-p1.xml">RSA/DSA
authentication</uri> (Part 1) and ssh-agent and <uri
link="/doc/en/articles/openssh-key-management-p2.xml">keychain</uri> (Part 2),
respectively.
</p>
<p>
Since Part 2 was published on developerWorks in September 2001, and later
referenced on Slashdot and Freshmeat (see <uri
link="#resources">Resources</uri> later in this article for links to these
sites), a lot of people have started using keychain, and it's undergone a lot
of changes. I've received approximately 20 or so high-quality patches from
developers around the world. I've incorporated many of these patches into the
keychain source, which is now at version 1.8 (see <uri
link="#resources">Resources</uri>). I send my sincere thanks to all those who
submitted patches, bug reports, feature requests, and notes of appreciation.
</p>
</body>
</section>
<section>
<title>Tightening ssh security</title>
<body>
<p>
In my <uri link="/doc/en/articles/openssh-key-management-p2.xml">last
article</uri>, I've spent some time discussing the security benefits and
tradeoffs of running ssh-agent. A few days after the second article appeared on
developerWorks, I received an e-mail from Charles Karney of Sarnoff
Corporation, who politely informed me of OpenSSH's new authentication agent
forwarding abilities, which we'll take a look at in a bit. In addition, Charles
emphasized that running ssh-agent on untrusted machines is quite dangerous: if
someone manages to get root access on the system, then your decrypted keys can
be extracted from ssh-agent. Even though extracting the keys would be somewhat
difficult, it is within the skill of professional crackers. And the mere fact
that private key theft is possible means that we should take steps to guard
against it happening in the first place.
</p>
<p>
To formulate a strategy to protect our private keys, we must first put the
machines we access into one of two categories. If a particular host is
well-secured or isolated -- making successful root exploit against it quite
unlikely -- then that machine should be considered a trusted host. If, however,
a machine is used by many other people or you have some doubts about the
security of the system, then the machine should be considered an untrusted
host. To guard your private keys against extraction, ssh-agent (and thus
keychain) should never be run on an untrusted host. That way, even if the
system's security is compromised, there will be no ssh-agent around for the
intruder to extract keys from in the first place.
</p>
<p>
However, this creates a problem. If you can't run ssh-agent on untrusted hosts,
then how do you establish secure, passwordless ssh connections from these
systems? The answer is to only use ssh-agent and keychain on trusted hosts, and
to use OpenSSH's new authentication forwarding abilities to extend passwordless
authentication to any untrusted hosts. In a nutshell, authentication forwarding
works by allowing remote ssh sessions to contact an ssh-agent running on a
trusted system.
</p>
</body>
</section>
<section>
<title>Authentication agent forwarding</title>
<body>
<p>
To get an idea of how authentication forwarding works, let's first take a look
at a hypothetical situation where user drobbins has a trusted laptop called
lappy, a trusted server called trustbox, and two other untrusted systems that
he must access, called notrust1 and notrust2, respectively. Currently, he uses
ssh-agent along with keychain on all four machines, as follows:
</p>
<figure link="/images/docs/l-ssh-3.jpg" caption="ssh-agent running on trusted
and untrusted machines"/>
<p>
The problem with this approach is that if someone gains root access on notrust1
or notrust2, then it is of course possible for this person to extract keys from
the now vulnerable ssh-agent process. To fix this, drobbins stops running
ssh-agent and keychain on untrusted hosts notrust1 and notrust2. In fact, to be
even more careful, drobbins decides to only use ssh-agent and keychain on
lappy. This limits exposure of his decrypted private keys, protecting him
against private key theft:
</p>
<figure link="/images/docs/l-ssh-4.jpg" caption="ssh-agent running only on
lappy; a more secure configuration"/>
<p>
Of course, the problem with this approach is that drobbins can now only
establish passwordless connections from lappy. Let's see how to enable
authentication forwarding and get around this problem.
</p>
<p>
Assuming that all machines are running recent versions of OpenSSH, we can get
around this problem by using authentication forwarding. Authentication
forwarding allows remote ssh processes to contact the ssh-agent that is running
on your local trusted machine -- rather than requiring a version of ssh-agent
to be running on the same machine that you are sshing out from. This usually
allows you to run ssh-agent (and keychain) on a single machine, and means that
all ssh connections that originate (either directly or indirectly) from this
machine will use your local ssh-agent.
</p>
<p>
To enable authentication forwarding, we add the following line to lappy and
trustbox's <path>/etc/ssh/ssh_config</path>. Note that this is the config file
for ssh (<path>ssh_config</path>), not the ssh daemon sshd
(<path>sshd_config</path>):
</p>
<pre caption="Add this line to your /etc/ssh/ssh_config">
ForwardAgent Yes
</pre>
<p>
Now, to take advantage of authentication forwarding, drobbins can connect from
lappy to trustbox, and then from trustbox to notrust1 without supplying
passphrases for any of the connections. Both ssh processes "tap in" to the
ssh-agent running on lappy:
</p>
<pre caption="Tapping lappy">
$ <i>ssh [EMAIL PROTECTED]</i>
Last login: Wed Sep 26 13:42:08 2001 from lappy
Welcome to trustbox!
$ <i>ssh [EMAIL PROTECTED]</i>
Last login: Tue Sep 25 12:03:40 2001 from trustbox
Welcome to notrust1!
$
</pre>
<p>
If you try a similar configuration and find that agent forwarding isn't
working, try using <c>ssh -A</c> instead of plain old ssh to explicitly enable
authentication forwarding. Here's a diagram of what went on behind the scenes
when we logged in to trustbox and notrust1 using authentication forwarding,
above:
</p>
<figure link="/images/docs/l-ssh-4.jpg" caption="ssh-agent running only on
lappy; a more secure configuration"/>
<p>
Of course, the problem with this approach is that drobbins can now only
establish passwordless connections from lappy. Let's see how to enable
authentication forwarding and get around this problem.
</p>
<p>
Assuming that all machines are running recent versions of OpenSSH, we can get
around this problem by using authentication forwarding. Authentication
forwarding allows remote ssh processes to contact the ssh-agent that is running
on your local trusted machine -- rather than requiring a version of ssh-agent
to be running on the same machine that you are sshing out from. This usually
allows you to run ssh-agent (and keychain) on a single machine, and means that
all ssh connections that originate (either directly or indirectly) from this
--
[email protected] mailing list
