| 1 |
rane 05/09/29 20:59:13 |
| 2 |
|
| 3 |
Added: xml/htdocs/doc/en/articles openssh-key-management-p1.xml |
| 4 |
openssh-key-management-p2.xml |
| 5 |
openssh-key-management-p3.xml |
| 6 |
Log: |
| 7 |
#99134: three new ssh articles |
| 8 |
|
| 9 |
Revision Changes Path |
| 10 |
1.1 xml/htdocs/doc/en/articles/openssh-key-management-p1.xml |
| 11 |
|
| 12 |
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 |
| 13 |
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 |
| 14 |
|
| 15 |
Index: openssh-key-management-p1.xml |
| 16 |
=================================================================== |
| 17 |
<?xml version='1.0' encoding="UTF-8"?> |
| 18 |
<!-- $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 $ --> |
| 19 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 20 |
|
| 21 |
<guide link="/doc/en/articles/openssh-key-management-p1.xml"> |
| 22 |
<title>OpenSSH key management, Part 1</title> |
| 23 |
<author title="Author"> |
| 24 |
<mail link="drobbins@g.o">Daniel Robbins</mail> |
| 25 |
</author> |
| 26 |
<!-- xmlified by Max Lorenz (anarchyisgoodforthee@×××××.com) --> |
| 27 |
|
| 28 |
<abstract> |
| 29 |
In this series, you'll learn how RSA and DSA authentication work, and see how |
| 30 |
to set up passwordless authentication the right way. In the first article of |
| 31 |
the series, Daniel Robbins focuses on introducing the RSA and DSA |
| 32 |
authentication protocols and showing you how to get them working over the |
| 33 |
network. |
| 34 |
</abstract> |
| 35 |
|
| 36 |
<!-- The original version of this article was first published on IBM |
| 37 |
developerWorks, and is property of Westtech Information Services. This |
| 38 |
document is an updated version of the original article, and contains |
| 39 |
various improvements made by the Gentoo Linux Documentation team --> |
| 40 |
|
| 41 |
<version>1.0</version> |
| 42 |
<date>2005-09-29</date> |
| 43 |
|
| 44 |
<chapter> |
| 45 |
<title>Understanding RSA/DSA authentication</title> |
| 46 |
<section> |
| 47 |
<body> |
| 48 |
|
| 49 |
<p> |
| 50 |
Many of us use the excellent OpenSSH (see <uri |
| 51 |
link="#resources">Resources</uri> later in this article) as a secure, encrypted |
| 52 |
replacement for the venerable <c>telnet</c> and <c>rsh</c> commands. One of |
| 53 |
OpenSSH's more intriguing features is its ability to authenticate users using |
| 54 |
the RSA and DSA authentication protocols, which are based on a pair of |
| 55 |
complementary numerical keys. As one of its main appeals, RSA and DSA |
| 56 |
authentication promise the capability of establishing connections to remote |
| 57 |
systems <e>without supplying a password</e>. While this is appealing, new |
| 58 |
OpenSSH users often configure RSA/DSA the quick and dirty way, resulting in |
| 59 |
passwordless logins, but opening up a big security hole in the process. |
| 60 |
</p> |
| 61 |
|
| 62 |
</body> |
| 63 |
</section> |
| 64 |
<section> |
| 65 |
<title>What is RSA/DSA authentication?</title> |
| 66 |
<body> |
| 67 |
|
| 68 |
<p> |
| 69 |
SSH, specifically OpenSSH (a completely free implementation of SSH), is an |
| 70 |
incredible tool. Like <c>telnet</c> or <c>rsh</c>, the ssh client can be used |
| 71 |
to log in to a remote machine. All that's required is for this remote machine |
| 72 |
to be running <c>sshd</c>, the <c>ssh</c> server process. However, unlike |
| 73 |
<c>telnet</c>, the ssh protocol is very secure. It uses special algorithms to |
| 74 |
encrypt the data stream, ensure data stream integrity and even perform |
| 75 |
authentication in a safe and secure way. |
| 76 |
</p> |
| 77 |
|
| 78 |
<p> |
| 79 |
However, while <c>ssh</c> is really great, there is a certain component of |
| 80 |
<c>ssh</c> functionality that is often ignored, dangerously misused, or simply |
| 81 |
misunderstood. This component is OpenSSH's RSA/DSA key authentication system, |
| 82 |
an alternative to the standard secure password authentication system that |
| 83 |
OpenSSH uses by default. |
| 84 |
</p> |
| 85 |
|
| 86 |
<p> |
| 87 |
OpenSSH's RSA and DSA authentication protocols are based on a pair of specially |
| 88 |
generated cryptographic keys, called the <e>private key</e> and the <e>public |
| 89 |
key</e>. The advantage of using these key-based authentication systems is that |
| 90 |
in many cases, it's possible to establish secure connections without having to |
| 91 |
manually type in a password. |
| 92 |
</p> |
| 93 |
|
| 94 |
<p> |
| 95 |
While the key-based authentication protocols are relatively secure, problems |
| 96 |
arise when users take certain shortcuts in the name of convenience, without |
| 97 |
fully understanding their security implications. In this article, we'll take a |
| 98 |
good look at how to correctly use RSA and DSA authentication protocols without |
| 99 |
exposing ourselves to any unnecessary security risks. In my next article, I'll |
| 100 |
show you how to use <c>ssh-agent</c> to cache decrypted private keys, and |
| 101 |
introduce <c>keychain</c>, an <c>ssh-agent</c> front-end that offers a number |
| 102 |
of convenience advantages without sacrificing security. If you've always wanted |
| 103 |
to get the hang of the more advanced authentication features of OpenSSH, then |
| 104 |
read on. |
| 105 |
</p> |
| 106 |
|
| 107 |
</body> |
| 108 |
</section> |
| 109 |
<section> |
| 110 |
<title>How RSA/DSA keys work</title> |
| 111 |
<body> |
| 112 |
|
| 113 |
<p> |
| 114 |
Here's a quick general overview of how RSA/DSA keys work. Let's start with a |
| 115 |
hypothetical scenario where we'd like to use RSA authentication to allow a |
| 116 |
local Linux workstation (named <e>localbox</e>) to open a remote shell on |
| 117 |
<e>remotebox</e>, a machine at our ISP. Right now, when we try to connect to |
| 118 |
<e>remotebox</e> using the <c>ssh</c> client, we get the following prompt: |
| 119 |
</p> |
| 120 |
|
| 121 |
<pre caption="Connecting to remotebox"> |
| 122 |
$ <i>ssh drobbins@remotebox</i> |
| 123 |
drobbins@remotebox's password: |
| 124 |
</pre> |
| 125 |
|
| 126 |
<p> |
| 127 |
Here we see an example of the <c>ssh</c> <e>default</e> way of handling |
| 128 |
authentication. Namely, it asks for the password of the <e>drobbins</e> account |
| 129 |
on <e>remotebox</e>. If we type in our password for <e>remotebox</e>, |
| 130 |
<c>ssh</c> uses its secure password authentication protocol, transmitting our |
| 131 |
password over to <e>remotebox</e> for verification. However, unlike what |
| 132 |
<c>telnet</c> does, here our password is encrypted so that it can not be |
| 133 |
intercepted by anyone sniffing our data connection. Once <e>remotebox</e> |
| 134 |
authenticates our supplied password against its password database, if |
| 135 |
successful, we're allowed to log on and are greeted with a <e>remotebox</e> |
| 136 |
shell prompt. While the <c>ssh</c> default authentication method is quite |
| 137 |
secure, RSA and DSA authentication open up some new possibilities. |
| 138 |
</p> |
| 139 |
|
| 140 |
<p> |
| 141 |
However, unlike the <c>ssh</c> secure password authentication, RSA |
| 142 |
authentication requires some initial configuration. We need to perform these |
| 143 |
initial configuration steps only once. After that, RSA authentication between |
| 144 |
<e>localbox</e> and <e>remotebox</e> will be totally painless. To set up RSA |
| 145 |
authentication, we first need to generate a pair of keys, one private and one |
| 146 |
public. These two keys have some very interesting properties. The public key |
| 147 |
can be used to encrypt a message, and only the holder of the private key can |
| 148 |
decrypt it. The public key can only be used for <e>encryption</e>, and the |
| 149 |
private key can only be used for <e>decryption</e> of a message encoded by the |
| 150 |
matching public key. The RSA (and DSA) authentication protocols use the special |
| 151 |
properties of key pairs to perform secure authentication, without needing to |
| 152 |
transmit any confidential information over the network. |
| 153 |
</p> |
| 154 |
|
| 155 |
<p> |
| 156 |
To get RSA or DSA authentication working, we perform a single one-time |
| 157 |
configuration step. We copy our <e>public key</e> over to <e>remotebox</e>. |
| 158 |
The public key is called "public" for a reason. Since it can only be used to |
| 159 |
<e>encrypt</e> messages for us, we don't need to be too concerned about it |
| 160 |
falling into the wrong hands. Once our public key has been copied over to |
| 161 |
<e>remotebox</e> and placed in a special file |
| 162 |
(<path>~/.ssh/authorized_keys</path>) so that <e>remotebox</e>'s <c>sshd</c> |
| 163 |
can locate it, we're ready to use RSA authentication to log onto |
| 164 |
<e>remotebox</e>. |
| 165 |
</p> |
| 166 |
|
| 167 |
<p> |
| 168 |
To do this, we simply type <c>ssh drobbins@remotebox</c> at <e>localbox</e>'s |
| 169 |
console, as we always have. However, this time, <c>ssh</c> lets |
| 170 |
<e>remotebox</e>'s <c>sshd</c> know that it would like to use the RSA |
| 171 |
authentication protocol. What happens next is rather interesting. |
| 172 |
<e>Remotebox</e>'s <c>sshd</c> generates a random number, and encrypts it using |
| 173 |
our public key that we copied over earlier. Then, it sends this encrypted |
| 174 |
random number back to the <c>ssh</c> running on <e>localbox</e>. In turn, our |
| 175 |
<c>ssh</c> uses our <e>private key</e> to decrypt this random number, and then |
| 176 |
sends it back to <e>remotebox</e>, saying in effect "See, I really <e>do</e> |
| 177 |
hold the matching private key; I was able to successfully decrypt your |
| 178 |
message!" Finally, <c>sshd</c> concludes that we should be allowed to log in, |
| 179 |
since we hold a matching private key. Thus, the fact that we hold a matching |
| 180 |
private key grants us access to <e>remotebox</e>. |
| 181 |
</p> |
| 182 |
|
| 183 |
</body> |
| 184 |
</section> |
| 185 |
<section> |
| 186 |
<title>Two observations</title> |
| 187 |
<body> |
| 188 |
|
| 189 |
<p> |
| 190 |
There are two important observations about the RSA and DSA authentication. The |
| 191 |
first is that we really only need to generate one pair of keys. We can then |
| 192 |
copy our public key to the remote machines that we'd like to access and they |
| 193 |
will all happily authenticate against our single private key. In other words, |
| 194 |
we don't need a key pair for <e>every</e> system we'd like to access. Just one |
| 195 |
pair will suffice. |
| 196 |
</p> |
| 197 |
|
| 198 |
<p> |
| 199 |
The other observation is that our <e>private key should not fall into the wrong |
| 200 |
hands</e>. The private key is the one thing that grants us access to our remote |
| 201 |
systems, and anyone that possesses our private key is granted exactly the same |
| 202 |
privileges that we are. Just as we wouldn't want strangers to have keys to our |
| 203 |
house, we should protect our private key from unauthorized use. In the world of |
| 204 |
bits and bytes, this means that no one should be able to read or copy our |
| 205 |
private key. |
| 206 |
</p> |
| 207 |
|
| 208 |
<p> |
| 209 |
Of course, the <c>ssh</c> developers are aware of the private keys' importance, |
| 210 |
and have built a few safeguards into <c>ssh</c> and <c>ssh-keygen</c> so that |
| 211 |
our private key is not abused. First, <c>ssh</c> is configured to print out a |
| 212 |
big warning message if our key has file permissions that would allow it to be |
| 213 |
read by anyone but us. Secondly, when we create our public/private key pair |
| 214 |
using <c>ssh-keygen</c>, <c>ssh-keygen</c> will ask us to enter a passphrase. |
| 215 |
If we do, our private key will be encrypted using this passphrase, so that even |
| 216 |
|
| 217 |
|
| 218 |
|
| 219 |
1.1 xml/htdocs/doc/en/articles/openssh-key-management-p2.xml |
| 220 |
|
| 221 |
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 |
| 222 |
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 |
| 223 |
|
| 224 |
Index: openssh-key-management-p2.xml |
| 225 |
=================================================================== |
| 226 |
<?xml version='1.0' encoding="UTF-8"?> |
| 227 |
<!-- $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 $ --> |
| 228 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 229 |
|
| 230 |
<guide link="/doc/en/articles/openssh-key-management-p2.xml"> |
| 231 |
<title>OpenSSH key management, Part 2</title> |
| 232 |
|
| 233 |
<author title="Author"> |
| 234 |
<mail link="drobbins@g.o">Daniel Robbins</mail> |
| 235 |
</author> |
| 236 |
|
| 237 |
<abstract> |
| 238 |
Many developers use the excellent OpenSSH as a secure, encrypted replacement |
| 239 |
for the venerable telnet and rsh commands. One of OpenSSH's more intriguing |
| 240 |
features is its ability to authenticate users using the RSA and DSA |
| 241 |
authentication protocols, which are based upon a pair of complementary |
| 242 |
numerical "keys". One of the main appeals of RSA and DSA authentication is the |
| 243 |
promise of being able to establish connections to remote systems without |
| 244 |
supplying a password. In this second article, Daniel introduces ssh-agent (a |
| 245 |
private key cache) and keychain, a special bash script designed to make |
| 246 |
key-based authentication incredibly convenient and flexible. |
| 247 |
</abstract> |
| 248 |
|
| 249 |
<!-- The original version of this article was first published on IBM |
| 250 |
developerWorks, and is property of Westtech Information Services. This |
| 251 |
document is an updated version of the original article, and contains |
| 252 |
various improvements made by the Gentoo Linux Documentation team --> |
| 253 |
|
| 254 |
<version>1.0</version> |
| 255 |
<date>2005-09-29</date> |
| 256 |
|
| 257 |
<chapter> |
| 258 |
<title>Introducing ssh-agent and keychain</title> |
| 259 |
<section> |
| 260 |
<title>Introducing ssh-agent</title> |
| 261 |
<body> |
| 262 |
|
| 263 |
<p> |
| 264 |
ssh-agent, included with the OpenSSH distribution, is a special program |
| 265 |
designed to make dealing with RSA and DSA keys both pleasant and secure (see |
| 266 |
Part 1 of this series for an introduction to RSA and DSA authentication.) |
| 267 |
ssh-agent, unlike ssh, is a long-running daemon designed for the sole purpose |
| 268 |
of caching your decrypted private keys. |
| 269 |
</p> |
| 270 |
|
| 271 |
<p> |
| 272 |
ssh includes built-in support that allows it to communicate with ssh-agent, |
| 273 |
allowing ssh to acquire your decrypted private keys without prompting you for a |
| 274 |
password for every single new connection. With ssh-agent you simply use ssh-add |
| 275 |
to add your private keys to ssh-agent's cache. It's a one-time process; after |
| 276 |
using ssh-add, ssh will grab your private key from ssh-agent, rather than |
| 277 |
bugging you by prompting for a passphrase. |
| 278 |
</p> |
| 279 |
|
| 280 |
</body> |
| 281 |
</section> |
| 282 |
<section> |
| 283 |
<title>Using ssh-agent</title> |
| 284 |
<body> |
| 285 |
|
| 286 |
<p> |
| 287 |
Let's take a look at how this whole ssh-agent key caching system works. When |
| 288 |
ssh-agent starts up, it spits out a few important environment variables before |
| 289 |
detaching from the shell and continuing to run in the background. Here's some |
| 290 |
example output generated by ssh-agent when it begins: |
| 291 |
</p> |
| 292 |
|
| 293 |
<pre caption="Running ssh-agent daemon"> |
| 294 |
$ <i>ssh-agent</i> |
| 295 |
SSH_AUTH_SOCK=/tmp/ssh-XX4LkMJS/agent.26916; export SSH_AUTH_SOCK; |
| 296 |
SSH_AGENT_PID=26917; export SSH_AGENT_PID; |
| 297 |
echo Agent pid 26917; |
| 298 |
</pre> |
| 299 |
|
| 300 |
<p> |
| 301 |
As you can see, ssh-agent's output is actually a series of bash commands; if |
| 302 |
executed, these commands would set a couple of environment variables, |
| 303 |
SSH_AUTH_SOCK and SSH_AGENT_PID. Due to the included export commands, these |
| 304 |
environment variables would be made available to any additional commands run |
| 305 |
later. Well, all that would happen if these lines were actually evaluated by |
| 306 |
the shell, but right now they're simply printed to stdout. To fix this, we can |
| 307 |
invoke ssh-agent in the following way: |
| 308 |
</p> |
| 309 |
|
| 310 |
<pre caption="Different way of invoking ssh-agent"> |
| 311 |
$ <i>eval `ssh-agent`</i> |
| 312 |
</pre> |
| 313 |
|
| 314 |
<p> |
| 315 |
This command tells bash to run ssh-agent and then evaluate ssh-agent's output. |
| 316 |
Invoked this way (with back-quotes, not normal single quotes), the |
| 317 |
SSH_AGENT_PID and SSH_AUTH_SOCK variables get set and exported by your shell, |
| 318 |
making these variables available to any new processes you may start during your |
| 319 |
login session. |
| 320 |
</p> |
| 321 |
|
| 322 |
<p> |
| 323 |
The best way to start ssh-agent is to add the above line to your |
| 324 |
~/.bash_profile; that way, all programs started in your login shell will see |
| 325 |
the environment variables, be able to locate ssh-agent and query it for keys as |
| 326 |
needed. The environment variable of particular importance is SSH_AUTH_SOCK; the |
| 327 |
SSH_AUTH_SOCK contains a path to a UNIX domain socket that ssh and scp can use |
| 328 |
to establish a dialogue with ssh-agent. |
| 329 |
</p> |
| 330 |
|
| 331 |
</body> |
| 332 |
</section> |
| 333 |
<section> |
| 334 |
<title>Using ssh-add</title> |
| 335 |
<body> |
| 336 |
|
| 337 |
<p> |
| 338 |
But of course, ssh-agent starts up with an empty cache of decrypted private |
| 339 |
keys. Before we can really use ssh-agent, we first need to add add our private |
| 340 |
key(s) to ssh-agent's cache using the ssh-add command. In the following |
| 341 |
example, I use ssh-add to add my <path>~/.ssh/identity</path> private RSA key |
| 342 |
to ssh-agent's cache: |
| 343 |
</p> |
| 344 |
|
| 345 |
<pre caption="Loading private RSA key to ssh-agent's cache"> |
| 346 |
# <i>ssh-add ~/.ssh/identity</i> |
| 347 |
Need passphrase for /home/drobbins/.ssh/identity |
| 348 |
Enter passphrase for /home/drobbins/.ssh/identity |
| 349 |
(enter passphrase) |
| 350 |
</pre> |
| 351 |
|
| 352 |
<p> |
| 353 |
As you can see, ssh-add asked for my passphrase so that the private key can be |
| 354 |
decrypted and stored in ssh-agent's cache, ready for use. Once you've used |
| 355 |
ssh-add to add your private key (or keys) to ssh-agent's cache and |
| 356 |
SSH_AUTH_SOCK is defined in your current shell (which it should be, if you |
| 357 |
started ssh-agent from your ~/.bash_profile), then you can use scp and ssh to |
| 358 |
establish connections with remote systems without supplying your passphrase. |
| 359 |
</p> |
| 360 |
|
| 361 |
</body> |
| 362 |
</section> |
| 363 |
<section> |
| 364 |
<title>Limitations of ssh-agent</title> |
| 365 |
<body> |
| 366 |
|
| 367 |
<p> |
| 368 |
ssh-agent is really cool, but its default configuration still leaves us with a |
| 369 |
few minor inconveniences. Let's take a look at them. |
| 370 |
</p> |
| 371 |
|
| 372 |
<p> |
| 373 |
For one, with <c>eval `ssh-agent`</c> in <path>~/.bash_profile</path>, a new |
| 374 |
copy of ssh-agent is launched for every login session; not only is this a tad |
| 375 |
bit wasteful, but it also means that you need to use ssh-add to add a private |
| 376 |
key to each new copy of ssh-agent. If you only open a single terminal or |
| 377 |
console on your system, this is no big deal, but most of us open quite a few |
| 378 |
terminals and need to type in our passphrase every single time we open a new |
| 379 |
console. Technically, there's no reason why we should need to do this since a |
| 380 |
single ssh-agent process really should suffice. |
| 381 |
</p> |
| 382 |
|
| 383 |
<p> |
| 384 |
Another problem with the default ssh-agent setup is that it's not compatible |
| 385 |
with cron jobs. Since cron jobs are started by the cron process, they won't |
| 386 |
inherit the SSH_AUTH_SOCK variable from their environment, and thus won't know |
| 387 |
that a ssh-agent process is running or how to contact it. It turns out that |
| 388 |
this problem is also fixable. |
| 389 |
</p> |
| 390 |
|
| 391 |
</body> |
| 392 |
</section> |
| 393 |
<section> |
| 394 |
<title>Enter keychain</title> |
| 395 |
<body> |
| 396 |
|
| 397 |
<p> |
| 398 |
To solve these problems, I wrote a handy bash-based ssh-agent front-end called |
| 399 |
keychain. What makes keychain special is the fact that it allows you to use a |
| 400 |
single ssh-agent process per system, not just per login session. This means |
| 401 |
that you only need to do one ssh-add per private key, period. As we'll see in a |
| 402 |
bit, keychain even helps to optimize the ssh-add process by only trying to add |
| 403 |
private keys that aren't already in the running ssh-agent's cache. |
| 404 |
</p> |
| 405 |
|
| 406 |
<p> |
| 407 |
Here's a run-through of how keychain works. When started from your |
| 408 |
<path>~/.bash_profile</path>, it will first check to see whether an ssh-agent |
| 409 |
is already running. If not, then it will start ssh-agent and record the |
| 410 |
important SSH_AUTH_SOCK and SSH_AGENT_PID variables in the |
| 411 |
<path>~/.ssh-agent</path> file for safe keeping and later use. Here's the best |
| 412 |
way to start keychain; like using plain old ssh-agent, we perform the necessary |
| 413 |
setup inside <path>~/.bash_profile</path>: |
| 414 |
</p> |
| 415 |
|
| 416 |
<pre caption="Settings for ssh-agent in ~/.bash_profile"> |
| 417 |
#!/bin/bash |
| 418 |
#example ~/.bash_profile file |
| 419 |
/usr/bin/keychain ~/.ssh/id_rsa |
| 420 |
#redirect ~/.ssh-agent output to /dev/null to zap the annoying |
| 421 |
#"Agent PID" message |
| 422 |
source ~/.ssh-agent > /dev/null |
| 423 |
</pre> |
| 424 |
|
| 425 |
|
| 426 |
|
| 427 |
|
| 428 |
1.1 xml/htdocs/doc/en/articles/openssh-key-management-p3.xml |
| 429 |
|
| 430 |
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 |
| 431 |
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 |
| 432 |
|
| 433 |
Index: openssh-key-management-p3.xml |
| 434 |
=================================================================== |
| 435 |
<?xml version='1.0' encoding="UTF-8"?> |
| 436 |
<!-- $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 $ --> |
| 437 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 438 |
|
| 439 |
<guide link="/doc/en/articles/openssh-key-management-p3.xml"> |
| 440 |
<title>OpenSSH key management, Part 3</title> |
| 441 |
<author title="Author"> |
| 442 |
<mail link="drobbins@g.o">Daniel Robbins</mail> |
| 443 |
</author> |
| 444 |
|
| 445 |
<abstract> |
| 446 |
In this third article in a series, Daniel Robbins shows you how to take |
| 447 |
advantage of OpenSSH agent connection forwarding to enhance security. He also |
| 448 |
shares recent improvements to the keychain shell script. |
| 449 |
</abstract> |
| 450 |
|
| 451 |
<!-- The original version of this article was first published on IBM |
| 452 |
developerWorks, and is property of Westtech Information Services. This |
| 453 |
document is an updated version of the original article, and contains |
| 454 |
various improvements made by the Gentoo Linux Documentation team --> |
| 455 |
|
| 456 |
<version>1.0</version> |
| 457 |
<date>2005-09-29</date> |
| 458 |
|
| 459 |
<chapter> |
| 460 |
<title>Agent forwarding and keychain improvements</title> |
| 461 |
<section> |
| 462 |
<body> |
| 463 |
|
| 464 |
<p> |
| 465 |
Many of us use the excellent OpenSSH as a secure, encrypted replacement for the |
| 466 |
venerable telnet and rsh commands. One of OpenSSH's more intriguing features is |
| 467 |
its ability to authenticate users using the RSA and DSA authentication |
| 468 |
protocols, which are based on a pair of complementary numerical "keys." One of |
| 469 |
the main appeals of RSA and DSA authentication is the promise of being able to |
| 470 |
establish connections to remote systems without supplying a password. For more |
| 471 |
background, see the previous installments of this series on OpenSSH key |
| 472 |
management, which cover <uri |
| 473 |
link="/doc/en/articles/openssh-key-management-p1.xml">RSA/DSA |
| 474 |
authentication</uri> (Part 1) and ssh-agent and <uri |
| 475 |
link="/doc/en/articles/openssh-key-management-p2.xml">keychain</uri> (Part 2), |
| 476 |
respectively. |
| 477 |
</p> |
| 478 |
|
| 479 |
<p> |
| 480 |
Since Part 2 was published on developerWorks in September 2001, and later |
| 481 |
referenced on Slashdot and Freshmeat (see <uri |
| 482 |
link="#resources">Resources</uri> later in this article for links to these |
| 483 |
sites), a lot of people have started using keychain, and it's undergone a lot |
| 484 |
of changes. I've received approximately 20 or so high-quality patches from |
| 485 |
developers around the world. I've incorporated many of these patches into the |
| 486 |
keychain source, which is now at version 1.8 (see <uri |
| 487 |
link="#resources">Resources</uri>). I send my sincere thanks to all those who |
| 488 |
submitted patches, bug reports, feature requests, and notes of appreciation. |
| 489 |
</p> |
| 490 |
|
| 491 |
</body> |
| 492 |
</section> |
| 493 |
<section> |
| 494 |
<title>Tightening ssh security</title> |
| 495 |
<body> |
| 496 |
|
| 497 |
<p> |
| 498 |
In my <uri link="/doc/en/articles/openssh-key-management-p2.xml">last |
| 499 |
article</uri>, I've spent some time discussing the security benefits and |
| 500 |
tradeoffs of running ssh-agent. A few days after the second article appeared on |
| 501 |
developerWorks, I received an e-mail from Charles Karney of Sarnoff |
| 502 |
Corporation, who politely informed me of OpenSSH's new authentication agent |
| 503 |
forwarding abilities, which we'll take a look at in a bit. In addition, Charles |
| 504 |
emphasized that running ssh-agent on untrusted machines is quite dangerous: if |
| 505 |
someone manages to get root access on the system, then your decrypted keys can |
| 506 |
be extracted from ssh-agent. Even though extracting the keys would be somewhat |
| 507 |
difficult, it is within the skill of professional crackers. And the mere fact |
| 508 |
that private key theft is possible means that we should take steps to guard |
| 509 |
against it happening in the first place. |
| 510 |
</p> |
| 511 |
|
| 512 |
<p> |
| 513 |
To formulate a strategy to protect our private keys, we must first put the |
| 514 |
machines we access into one of two categories. If a particular host is |
| 515 |
well-secured or isolated -- making successful root exploit against it quite |
| 516 |
unlikely -- then that machine should be considered a trusted host. If, however, |
| 517 |
a machine is used by many other people or you have some doubts about the |
| 518 |
security of the system, then the machine should be considered an untrusted |
| 519 |
host. To guard your private keys against extraction, ssh-agent (and thus |
| 520 |
keychain) should never be run on an untrusted host. That way, even if the |
| 521 |
system's security is compromised, there will be no ssh-agent around for the |
| 522 |
intruder to extract keys from in the first place. |
| 523 |
</p> |
| 524 |
|
| 525 |
<p> |
| 526 |
However, this creates a problem. If you can't run ssh-agent on untrusted hosts, |
| 527 |
then how do you establish secure, passwordless ssh connections from these |
| 528 |
systems? The answer is to only use ssh-agent and keychain on trusted hosts, and |
| 529 |
to use OpenSSH's new authentication forwarding abilities to extend passwordless |
| 530 |
authentication to any untrusted hosts. In a nutshell, authentication forwarding |
| 531 |
works by allowing remote ssh sessions to contact an ssh-agent running on a |
| 532 |
trusted system. |
| 533 |
</p> |
| 534 |
|
| 535 |
</body> |
| 536 |
</section> |
| 537 |
<section> |
| 538 |
<title>Authentication agent forwarding</title> |
| 539 |
<body> |
| 540 |
|
| 541 |
<p> |
| 542 |
To get an idea of how authentication forwarding works, let's first take a look |
| 543 |
at a hypothetical situation where user drobbins has a trusted laptop called |
| 544 |
lappy, a trusted server called trustbox, and two other untrusted systems that |
| 545 |
he must access, called notrust1 and notrust2, respectively. Currently, he uses |
| 546 |
ssh-agent along with keychain on all four machines, as follows: |
| 547 |
</p> |
| 548 |
|
| 549 |
<figure link="/images/docs/l-ssh-3.jpg" caption="ssh-agent running on trusted and untrusted machines"/> |
| 550 |
|
| 551 |
<p> |
| 552 |
The problem with this approach is that if someone gains root access on notrust1 |
| 553 |
or notrust2, then it is of course possible for this person to extract keys from |
| 554 |
the now vulnerable ssh-agent process. To fix this, drobbins stops running |
| 555 |
ssh-agent and keychain on untrusted hosts notrust1 and notrust2. In fact, to be |
| 556 |
even more careful, drobbins decides to only use ssh-agent and keychain on |
| 557 |
lappy. This limits exposure of his decrypted private keys, protecting him |
| 558 |
against private key theft: |
| 559 |
</p> |
| 560 |
|
| 561 |
<figure link="/images/docs/l-ssh-4.jpg" caption="ssh-agent running only on lappy; a more secure configuration"/> |
| 562 |
|
| 563 |
<p> |
| 564 |
Of course, the problem with this approach is that drobbins can now only |
| 565 |
establish passwordless connections from lappy. Let's see how to enable |
| 566 |
authentication forwarding and get around this problem. |
| 567 |
</p> |
| 568 |
|
| 569 |
<p> |
| 570 |
Assuming that all machines are running recent versions of OpenSSH, we can get |
| 571 |
around this problem by using authentication forwarding. Authentication |
| 572 |
forwarding allows remote ssh processes to contact the ssh-agent that is running |
| 573 |
on your local trusted machine -- rather than requiring a version of ssh-agent |
| 574 |
to be running on the same machine that you are sshing out from. This usually |
| 575 |
allows you to run ssh-agent (and keychain) on a single machine, and means that |
| 576 |
all ssh connections that originate (either directly or indirectly) from this |
| 577 |
machine will use your local ssh-agent. |
| 578 |
</p> |
| 579 |
|
| 580 |
<p> |
| 581 |
To enable authentication forwarding, we add the following line to lappy and |
| 582 |
trustbox's <path>/etc/ssh/ssh_config</path>. Note that this is the config file |
| 583 |
for ssh (<path>ssh_config</path>), not the ssh daemon sshd |
| 584 |
(<path>sshd_config</path>): |
| 585 |
</p> |
| 586 |
|
| 587 |
<pre caption="Add this line to your /etc/ssh/ssh_config"> |
| 588 |
ForwardAgent Yes |
| 589 |
</pre> |
| 590 |
|
| 591 |
<p> |
| 592 |
Now, to take advantage of authentication forwarding, drobbins can connect from |
| 593 |
lappy to trustbox, and then from trustbox to notrust1 without supplying |
| 594 |
passphrases for any of the connections. Both ssh processes "tap in" to the |
| 595 |
ssh-agent running on lappy: |
| 596 |
</p> |
| 597 |
|
| 598 |
<pre caption="Tapping lappy"> |
| 599 |
$ <i>ssh drobbins@trustbox</i> |
| 600 |
Last login: Wed Sep 26 13:42:08 2001 from lappy |
| 601 |
|
| 602 |
Welcome to trustbox! |
| 603 |
$ <i>ssh drobbins@notrust1</i> |
| 604 |
Last login: Tue Sep 25 12:03:40 2001 from trustbox |
| 605 |
|
| 606 |
Welcome to notrust1! |
| 607 |
$ |
| 608 |
</pre> |
| 609 |
|
| 610 |
<p> |
| 611 |
If you try a similar configuration and find that agent forwarding isn't |
| 612 |
working, try using <c>ssh -A</c> instead of plain old ssh to explicitly enable |
| 613 |
authentication forwarding. Here's a diagram of what went on behind the scenes |
| 614 |
when we logged in to trustbox and notrust1 using authentication forwarding, |
| 615 |
above: |
| 616 |
</p> |
| 617 |
|
| 618 |
<figure link="/images/docs/l-ssh-4.jpg" caption="ssh-agent running only on lappy; a more secure configuration"/> |
| 619 |
|
| 620 |
<p> |
| 621 |
Of course, the problem with this approach is that drobbins can now only |
| 622 |
establish passwordless connections from lappy. Let's see how to enable |
| 623 |
authentication forwarding and get around this problem. |
| 624 |
</p> |
| 625 |
|
| 626 |
<p> |
| 627 |
Assuming that all machines are running recent versions of OpenSSH, we can get |
| 628 |
around this problem by using authentication forwarding. Authentication |
| 629 |
forwarding allows remote ssh processes to contact the ssh-agent that is running |
| 630 |
on your local trusted machine -- rather than requiring a version of ssh-agent |
| 631 |
to be running on the same machine that you are sshing out from. This usually |
| 632 |
allows you to run ssh-agent (and keychain) on a single machine, and means that |
| 633 |
all ssh connections that originate (either directly or indirectly) from this |
| 634 |
|
| 635 |
|
| 636 |
|
| 637 |
-- |
| 638 |
gentoo-doc-cvs@g.o mailing list |
Archives