| 1 |
yoswink 08/10/08 12:43:48 |
| 2 |
|
| 3 |
Added: openssh-key-management-p2.xml |
| 4 |
Log: |
| 5 |
New translation thanks to Javier Vecino <coghan@×××××××××××.cc> |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/doc/es/articles/openssh-key-management-p2.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p2.xml?rev=1.1&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p2.xml?rev=1.1&content-type=text/plain |
| 12 |
|
| 13 |
Index: openssh-key-management-p2.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version = '1.0' encoding = 'UTF-8'?> |
| 16 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p2.xml,v 1.1 2008/10/08 12:43:48 yoswink Exp $ --> |
| 17 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 18 |
|
| 19 |
<guide link="/doc/es/articles/openssh-key-management-p2.xml" disclaimer="articles" lang="es"> |
| 20 |
<title>Gestión de claves para OpenSSH, Parte 2</title> |
| 21 |
|
| 22 |
<author title="Autor"> |
| 23 |
<mail link="drobbins@g.o">Daniel Robbins</mail> |
| 24 |
</author> |
| 25 |
<author title="Traductor"> |
| 26 |
<mail link="coghan@×××××××××××.cc">Javier Vecino</mail> |
| 27 |
</author> |
| 28 |
|
| 29 |
<abstract> |
| 30 |
Muchos desarrolladores usan las excelencias de OpenSSH como sustituto cifrado y |
| 31 |
seguro de los venerables comandos tenet y rsh. Una de las características que |
| 32 |
más intrigan de OpenSSH es la habilidad para validar usuarios usando los |
| 33 |
protocolos RSA y DSA, que se basan en un par de claves numéricas |
| 34 |
complementarias. Uno de los principales atractivos de la validación RSA y DSA es |
| 35 |
la promesa de ser capaz de establecer conexiones a sistemas remotos sin |
| 36 |
suministrar una contraseña. En este segundo artículo, Daniel nos introduce en |
| 37 |
ssh-agent (una caché de claves privadas) y keychain, unos scripts de bash |
| 38 |
especialmente diseñados para hacer la validación basada en clave increiblemente |
| 39 |
cómoda y flexible. |
| 40 |
</abstract> |
| 41 |
|
| 42 |
<!--La versión original de este artículo fue publicada por IBM developerWorks y |
| 43 |
es propiedad de Westtech Information Services. Este documento es una |
| 44 |
versión actualizada del artículo original y contiene mejoras introducidas |
| 45 |
por el Equipo de Documentación de Gentoo. --> |
| 46 |
|
| 47 |
<version>1.2</version> |
| 48 |
<date>2005-10-09</date> |
| 49 |
|
| 50 |
<chapter> |
| 51 |
<title>Presentando ssh-agent y keychain</title> |
| 52 |
<section> |
| 53 |
<title>Presentando ssh-agent</title> |
| 54 |
<body> |
| 55 |
|
| 56 |
<p> |
| 57 |
ssh-agent, incluido con la distribución de OpenSSH, es un programa especialmente |
| 58 |
diseñado para manejar las claves RSA y DSA de forma agradable y segura (vea |
| 59 |
la Parte 1 de esta serie para una introcucción a la validación RSA y DSA.) |
| 60 |
ssh-agent, a diferencia de ssh, es un servicio diseñado con el único objetivo de |
| 61 |
almacenar en caché el descifrado de sus claves privadas. |
| 62 |
</p> |
| 63 |
|
| 64 |
<p> |
| 65 |
ssh incluye soporte para comunicarse con ssh-agent, permitiendo a ssh adquirir |
| 66 |
sus claves privadas descifradas sin preguntarle por la contraseña en cada nueva |
| 67 |
conexión. Simplemente utilice ssh-add para añadir sus claves privadas a la caché |
| 68 |
de shh-agent. En un único proceso; después de utilizar ssh-add, ssh usará su |
| 69 |
clave privada desde ssh-agent, en lugar de preguntarle por una contraseña. |
| 70 |
</p> |
| 71 |
|
| 72 |
</body> |
| 73 |
</section> |
| 74 |
<section> |
| 75 |
<title>Uso de ssh-agent</title> |
| 76 |
<body> |
| 77 |
|
| 78 |
<p> |
| 79 |
Echemos un vistazo a como trabaja todo este sistema de caché de claves con |
| 80 |
ssh-agent. Al iniciar ssh-agent desde consola, muestra unas variables de entorno |
| 81 |
importantes antes de desconectarse de la consola y continuar su proceso en |
| 82 |
segundo plano. He aquí un ejemplo de la salida generada por ssh-agent cuando se |
| 83 |
inicia: |
| 84 |
</p> |
| 85 |
|
| 86 |
<pre caption="Lanzando el servidio ssh-agent"> |
| 87 |
$ <i>ssh-agent</i> |
| 88 |
SSH_AUTH_SOCK=/tmp/ssh-XX4LkMJS/agent.26916; export SSH_AUTH_SOCK; |
| 89 |
SSH_AGENT_PID=26917; export SSH_AGENT_PID; |
| 90 |
echo Agent pid 26917; |
| 91 |
</pre> |
| 92 |
|
| 93 |
<p> |
| 94 |
Como puede ver, la salida de ssh-agent es en realidad una serie de comandos en |
| 95 |
bash; si se ejecutan, estos comandos ajustarías un par de variables de entorno, |
| 96 |
SSH_AUTH_SOCK y SSH_AGENT_PID. Debido a la inclusión del comando export, estas |
| 97 |
variables de entorno estarán disponibles para cualquier comando adicional que se |
| 98 |
lance posteriormente. Bien, todo pasaría si estas líneas fueran evaluadas por la |
| 99 |
consola, pero ahora solamente se ha enviado a stdout. Para solucionarlo, podemos |
| 100 |
llamar a ssh-agent como sigue: |
| 101 |
</p> |
| 102 |
|
| 103 |
<pre caption="Otra manera de llamar a ssh-agent"> |
| 104 |
$ <i>eval `ssh-agent`</i> |
| 105 |
</pre> |
| 106 |
|
| 107 |
<p> |
| 108 |
Este comando le dice a bash que lance ssh-agent y evalúe su salida. Invocando |
| 109 |
de esta forma (con comillas inclinadas, no con comillas simples normales), las |
| 110 |
variables SSH_AGENT_PID y SSH_AUTH_SOCK serán ajustadas y exportadas por su |
| 111 |
consola, estando estas variables a disposiciñon de todos los procesos nuevos que |
| 112 |
se puedan iniciar durante su sesión. |
| 113 |
</p> |
| 114 |
|
| 115 |
<p> |
| 116 |
La mejor manera de lanzar ssh-agent es añadir la línea anterior a su |
| 117 |
<path>~/.bash_profile</path>; de esta manera, todos los programas iniciados en |
| 118 |
su sesión verán las variables de entorno, serán capaces de localizar ssh-agent y |
| 119 |
cosultar claves cuando sea necesario. La variable de entorno particularmente |
| 120 |
importante es SHH_AUTH_SOCK; contiene un enlace a un socket UNIX que ssh y scp |
| 121 |
pueden usar para establecer comunicación con ssh-agent. |
| 122 |
</p> |
| 123 |
|
| 124 |
</body> |
| 125 |
</section> |
| 126 |
<section> |
| 127 |
<title>Usando ssh-add</title> |
| 128 |
<body> |
| 129 |
|
| 130 |
<p> |
| 131 |
Por supuesto, ssh-agent se inicia con una caché de claves descifradas vacía. |
| 132 |
Antes de que podamos utilizar ssh-agent, en primer lugar hay que añadir |
| 133 |
nuestra(s) clave(s) privada(s) a la caché de ssh-agent utilizando el comando |
| 134 |
ssh-add. En el siguiente ejemplo uso ssh.add para añadir mi clave privada RSA |
| 135 |
<path>~/.ssh/identity</path> a la caché de ssh-agent: |
| 136 |
</p> |
| 137 |
|
| 138 |
<pre caption="Cargando clave privada RSA a la caché de ssh-agent's"> |
| 139 |
$ <i>ssh-add ~/.ssh/identity</i> |
| 140 |
Need passphrase for /home/drobbins/.ssh/identity |
| 141 |
Enter passphrase for /home/drobbins/.ssh/identity |
| 142 |
(enter passphrase) |
| 143 |
</pre> |
| 144 |
|
| 145 |
<p> |
| 146 |
Como puede ver, ssh-add pregunta por mi contraseña a fin de que la clave privada |
| 147 |
pueda ser descifrada y se almacena en la caché de ssh-agent, lista para usar. |
| 148 |
Una vez que haya usado ssh-add para agregar su clave (o claves) privada a la |
| 149 |
caché de ssh-agent SSH_AUTH_SOCK se define en su actual consola (debe ser así, |
| 150 |
si lanzó ssh-agent desde su ~/.bash_profile), entonces ya puede usar ssh y scp |
| 151 |
para establecer conexiones con sistemas remotos sin suministrar su contraseña. |
| 152 |
</p> |
| 153 |
|
| 154 |
</body> |
| 155 |
</section> |
| 156 |
<section> |
| 157 |
<title>Limitaciones de ssh-agent</title> |
| 158 |
<body> |
| 159 |
|
| 160 |
<p> |
| 161 |
ssh-agent es realmente cool, pero su configuración por defecto tiene unos pocos |
| 162 |
inconvenientes. Echemos un vistazo a ellos. |
| 163 |
</p> |
| 164 |
|
| 165 |
<p> |
| 166 |
Por uno lado, con <c>eval `ssh-agent`</c> en <path>~/.bash_profile</path>, una |
| 167 |
nueva copia de ssh-agent es iniciada cada inicio de sesión; no solamente es un |
| 168 |
desperdicio, también significa que necesita usar ssh-add para añadir una clave |
| 169 |
privada para cada nueva copia de ssh-agent. Si solo abre una consola en su |
| 170 |
sistema, esto no es mayor problema, pero la mayoría de nosotros abrimos un buen |
| 171 |
número de terminales y es necesario escribir la contraseña cada vez que se abre |
| 172 |
una nueva consola. Técnicamente, no hay razón por la que debiera ser necesario |
| 173 |
esto mientras un solo proceso ssh-agent fuera suficiente. |
| 174 |
</p> |
| 175 |
|
| 176 |
<p> |
| 177 |
Otro problema por defecto en ssh-agent es que la instalación no es compatible |
| 178 |
con cron jobs. Los trabajos iniciados por el proceso cron, no heredan la |
| 179 |
variable de entorno SSH_AUTH_SOCK, y por consiguiente no sabrán que hay un |
| 180 |
proceso ssh-agent en ejecución ni cómo ponerse en contacto con él. Este problema |
| 181 |
también es corregible. |
| 182 |
</p> |
| 183 |
|
| 184 |
</body> |
| 185 |
</section> |
| 186 |
<section> |
| 187 |
<title>Introducir keychain</title> |
| 188 |
<body> |
| 189 |
|
| 190 |
<p> |
| 191 |
Para resolver estos problemas, He escrito un práctico front-end basado en bash |
| 192 |
llamado keychain. Lo que hace especial a keychain es el hecho de que permite |
| 193 |
utilizar un solo proceso ssh-agent por sistema, no sólo por sesión. Esto |
| 194 |
significa que usted sólo tiene que hacer un ssh-add por clave privada, y punto. |
| 195 |
Como veremos en breve, incluso keychain ayuda a optimizar el proceso ssh-add |
| 196 |
tratando de añadir solamente las claves privadas que no estén en ejecución en la |
| 197 |
caché de ssh-agent. |
| 198 |
</p> |
| 199 |
|
| 200 |
<p> |
| 201 |
Aquí hay una muestra de como funciona keychain. Cuando se inicia a partir de su |
| 202 |
<path>~/.bash_profile</path>, se comprueba en primer lugar si algún ssh-agent se |
| 203 |
está ejecutando. Si no es así, entonces se iniciará ssh-agent y registrará las |
| 204 |
importantes variables SSH_AUTH_SOCK y SSH_AGENT_PID en el archivo |
| 205 |
<path>~/.ssh-agent</path> para su custodia y posterior uso. Esta es la mejor |
| 206 |
manera de iniciar keychain; como hicimos con ssh-agent, es necesario realizar la |
| 207 |
configuración en <path>~/.bash_profile</path>: |
| 208 |
</p> |
| 209 |
|
| 210 |
<pre caption="Configuración de ssh-agent en ~/.bash_profile"> |
| 211 |
#!/bin/bash |
| 212 |
#example ~/.bash_profile file |
| 213 |
/usr/bin/keychain ~/.ssh/id_rsa |
| 214 |
#redirect ~/.ssh-agent output to /dev/null to zap the annoying |
| 215 |
#"Agent PID"; message |
| 216 |
source ~/.ssh-agent > /dev/null |
| 217 |
</pre> |
| 218 |
|
| 219 |
<p> |
| 220 |
Como puede ver, con keychain suministramos al fichero <path>~/.ssh-agent</path> |
| 221 |
en lugar de evaluar la salida como cuando usamos ssh-agent directamente. Sin |
| 222 |
embargo el resultado es el mismo -- nuestra cada vez más importánte variable |
| 223 |
SSH_AUTH_SOCK es definida, y ssh-agent se está ejecutando y listo para usarse. |
| 224 |
Y debido a que se registra SSH_AUTH_SOCK en <path>~/.ssh-agent</path>, nuestros |
| 225 |
propios scripts y cron jobs pueden conectarse fácilmente con ssh-agent solo con |
| 226 |
la lectura del archivo <path>~/.ssh-agent</path>. keychain también se aprovecha |
| 227 |
de este fichero; recuerde cuando keychain se inició, este comprueba si ssh-agent |
| 228 |
está ejecutándose. Si es así, se usa el fichero <path>~/.ssh-agent</path> para |
| 229 |
adquirir la configuración apropiada de SSH_AUTH_SOCK, por lo tanto le permite |
| 230 |
utilizar el actual agente en lugar de iniciar uno nuevo. keychain solo iniciará |
| 231 |
un nuevo proceso ssh-agent sólo si el fichero <path>~/.ssh-agent</path> está |
| 232 |
rancio (apunta a un ssh-agent inexistente) o si el mismo |
| 233 |
<path>~/.ssh-agent</path> no existe. |
| 234 |
</p> |
| 235 |
|
| 236 |
</body> |
| 237 |
</section> |
| 238 |
<section> |
| 239 |
<title>Instalar keychain</title> |
| 240 |
<body> |
| 241 |
|
| 242 |
<p> |
| 243 |
La instalación de keychain es fácil. En primer lugar, vaya a la |
| 244 |
<uri link="http://www.gentoo.org/proj/en/keychain/index.xml">página del proyecto |
| 245 |
keychain</uri> y descarge la versión más reciente disponible de las fuentes de |
| 246 |
keychain o instale usando emerge, de la siguiente manera: |
| 247 |
</p> |
| 248 |
|
| 249 |
<pre caption="Instalar keychain"> |
| 250 |
# <i>emerge keychain</i> |
| 251 |
</pre> |
| 252 |
|
| 253 |
<p> |
| 254 |
Ahora que keychain esta en <path>/usr/bin/</path>, añada a su |
| 255 |
<path>~/.bash_profile</path>, añadiendo la ruta de su clave privada como |
| 256 |
argumento. Aquí hay una buena configuración para habilitar keychain desde |
| 257 |
<path>~/.bash_profile</path>: |
| 258 |
</p> |
| 259 |
|
| 260 |
<pre caption="Activando keychain en ~/.bash_profile"> |
| 261 |
#!/bin/bash |
| 262 |
#on this next line, we start keychain and point it to the private keys that |
| 263 |
#we'd like it to cache |
| 264 |
/usr/bin/keychain ~/.ssh/id_rsa ~/.ssh/id_dsa |
| 265 |
source ~/.ssh-agent > /dev/null |
| 266 |
#sourcing ~/.bashrc is a good thing |
| 267 |
source ~/.bashrc |
| 268 |
</pre> |
| 269 |
|
| 270 |
</body> |
| 271 |
</section> |
| 272 |
<section> |
| 273 |
<title>Keychain en acción</title> |
| 274 |
<body> |
| 275 |
|
| 276 |
<p> |
| 277 |
Una vez configurado su <path>~/.bash_profile</path> para llamar a keychain en |
| 278 |
cada inicio de sesión, reinicie su sesión, Al hacerlo, keychain iniciará |
| 279 |
ssh-agent, registrará la configuración de la variable de entorno del agente en |
| 280 |
<path>~/.ssh-agent</path>, y le pedirá las contraseñas de las claves privadas |
| 281 |
especificadas en la linea de comandos keychain en <path>~/.bash_profile</path>: |
| 282 |
</p> |
| 283 |
|
| 284 |
<figure link="/images/docs/l-ssh-1.gif" caption="Keychain se inicia por primera |
| 285 |
vez"/> |
| 286 |
|
| 287 |
<p> |
| 288 |
Una vez que introduzca su contraseña, sus claves privadas se almacenarán en |
| 289 |
caché, y keychain finalizará. Entonces, se cargará ~/.ssh-agent, inicializando |
| 290 |
su sesión para ser usada con ssh-agent. Ahora, si reinicia su sesión nuevamente, |
| 291 |
notará que keychain encontrará ssh-agent como proceso existente; que no finalizó |
| 292 |
cuando cerró su sesión. Además, keychain verificará que las claves privadas |
| 293 |
especificadas están listas en la caché de ssh-agent. Si no es así, entonces le |
| 294 |
pedirá la contraseña, pero si todo va bien, su actual ssh-agent todavía |
| 295 |
contendrá la clave privada que previamente añadió, lo que significa que no se le |
| 296 |
preguntará por una contraseña: |
| 297 |
</p> |
| 298 |
|
| 299 |
<figure link="/images/docs/l-ssh-2.gif" caption="Keychain encontrando un |
| 300 |
existente ssh-agent"/> |
| 301 |
|
| 302 |
<p> |
| 303 |
Felicidades, acaba de iniciar sesión y debería ser capaz de usar ssh y scp en |
| 304 |
sistemas remotos; no necesita usar ssh-add después de iniciar la sesión, y ssh y |
| 305 |
scp no le pedirán una contraseña. De hecho, siempre y cuando el proceso inicial |
| 306 |
ssh-agent siga en marcha, podrá acceder y establecer conexiones ssh sin |
| 307 |
suministrar una contraseña. Y es muy probable que su proceso ssh-agent continue |
| 308 |
ejecutandose hasta que la máquina sea reiniciada; probablemente lo configure en |
| 309 |
un sistema Linux, ¡es posible que no sea necesario que introduzca su contraseña |
| 310 |
en varios meses!. Bienvenido al mundo de la seguridad, conexiones libres de |
| 311 |
contraseñas usando la validación RSA y DSA. |
| 312 |
</p> |
| 313 |
|
| 314 |
<p> |
| 315 |
Adelante, cree varias sesiones nuevas, y verá que keychain "enganchará"; al |
| 316 |
mismo proceso ssh-agent cada vez. No hay que olvidar que puede enganchar sus |
| 317 |
cron jobs y scripts al proceso ssh-agent en ejecución. Para utilizar los |
| 318 |
comandos ssh o scp desde scripts de consola y cron jobs, asegúrese de que |
| 319 |
obtiene su fichero <path>~/.ssh-agent</path> en primer lugar: |
| 320 |
</p> |
| 321 |
|
| 322 |
<pre caption="Obteniendo el fichero ~/.ssh-agent"> |
| 323 |
$ <i>source ~/.ssh-agent</i> |
| 324 |
</pre> |
| 325 |
|
| 326 |
<p> |
| 327 |
Luego, cualquier comando ssh o scp serán capaces de encontrar el actual proceso |
| 328 |
ssh-agent en ejecución y establecer una coneción segura libre de contraseñas |
| 329 |
igual que desde la consola. |
| 330 |
</p> |
| 331 |
|
| 332 |
</body> |
| 333 |
</section> |
| 334 |
<section> |
| 335 |
<title>Opciones de keychain</title> |
| 336 |
<body> |
| 337 |
|
| 338 |
<p> |
| 339 |
Después de tener funcionando keychain, asegurese de teclear |
| 340 |
<c>keychain --help</c> para familiarizarse con todas las opciones de linea de |
| 341 |
comandos de keychain. Vamos a echar un vistazo a uno en partiular: la opción |
| 342 |
<c>--clear</c> |
| 343 |
</p> |
| 344 |
|
| 345 |
<p> |
| 346 |
Recordará que en la parte 1, expliqué que el uso de claves privadas sin cifrar |
| 347 |
es una práctica peligrosa, ya que permite a cualquiera robar su clave privada y |
| 348 |
usarla para acceder a sus cuentas remotas de cualquier sistema sin suministrarle |
| 349 |
contraseña. Bien, mientras que keychain no es vulnerable a este tipo de abuso |
| 350 |
(que es siempre y cuando utilice las claves privadas cifradas), hay una |
| 351 |
debilidad potencialmente explotable directamente relacionada con el hecho que |
| 352 |
keychain se enganche facilmente a un proceso ssh-agent de larga duración. |
| 353 |
¿Que pasaría, pensé, sin algún intruso consiguiera averiguar mi contraseña o |
| 354 |
frase de acceso a mi sistema local? Si de alguna manera se pudiera acceder bajo |
| 355 |
mi usuario, keychain les garantizaría el acceso instantáneo a mis claves |
| 356 |
privadas descifradas, por lo que no es obvio para ellos tener acceso a mis otras |
| 357 |
cuentas. |
| 358 |
</p> |
| 359 |
|
| 360 |
<p> |
| 361 |
Ahora, antes de continuar, vamos a poner este riesgo de seguridad en |
| 362 |
perspectiva. Si algún usuario malintencionado de alguna manera pudiera validarse |
| 363 |
como yo, keychain permitiría el acceso a mis cuentas remotas. Sin embargo, aun |
| 364 |
así, sería muy difícil para el intruso robar mis claves privadas descifradas ya |
| 365 |
que todavía están encriptadas en el disco. Además, para tener acceso a mis |
| 366 |
claves privadas requiere que un usuario realmente se valide como yo. Así que, |
| 367 |
abusar de ssh-agent sería más difícil que simplemente robar una clave privada |
| 368 |
sin cifrar, que sólo requiere que un intruso acceda de alguna manera a mis |
| 369 |
ficheros en <path>~/.ssh</path>, ya sea validado como yo o no. Sin embargo, si |
| 370 |
un intruso logró acceder en condiciones a validarse como yo, ello supondría que |
| 371 |
podría hacer un poco más de daño adicional usando mis claves privadas |
| 372 |
descifradas. Por lo tanto, si usted pasase a estar usando keychain en un |
| 373 |
servidor que no se validase a menudo o no activamente para controlar las brechas |
| 374 |
de seguridad, entonces considere utilizar la opción <c>--clear</c> para |
| 375 |
proporcionar una capa de seguridad adicional. |
| 376 |
</p> |
| 377 |
|
| 378 |
<p> |
| 379 |
La opción <c>--clear</c> permite decirle a keychain suponer que cada nuevo |
| 380 |
acceso a su cuenta debería ser considerado como una potencial brecha en la |
| 381 |
seguridad hasta que se demuestre lo contrario. Al iniciar keychain con la opción |
| 382 |
<c>--clear</c> , keychain limpia inmediatamente todas sus claves privadas de la |
| 383 |
caché de ssh-agent cuando se inicia sesión, antes de realizar sus funciones |
| 384 |
normales. Por lo tanto, si usted es un intruso, keychain le pedirá las |
| 385 |
contraseñas en lugar de darle acceso a su actual conjunto de claves en caché. |
| 386 |
Sin embargo, a pesar de que ello aumenta la seguridad, hace las cosas un poco |
| 387 |
más incómodas y muy similar a ejecutar ssh-agent por sí solo, sin keychain. En |
| 388 |
este caso, como suele ser, uno puede optar por una mayor seguridad o mayor |
| 389 |
comodidad, pero no ambos. |
| 390 |
</p> |
| 391 |
|
| 392 |
<p> |
| 393 |
A pesar de ello, utilizando kechain con <c>--clear</c> todavía tiene ventajas |
| 394 |
sobre el uso de ssh-agent por sí solo; recuerde, cuando se usa keychain |
| 395 |
<c>--clear</c>, sus cron jobs y scripts seguirán siendo capaces de establecer |
| 396 |
conexiones sin contraseñas; esto es debido a que sus claves privadas son |
| 397 |
limpiadas en el acceso, no al salir. Desde un cierre de sesión del sistema no |
| 398 |
constituye una potencial brecha de seguridad, no hay razón para que keychain |
| 399 |
limpie las claves de ssh-agent. Por lo tanto, la opción <c>--clear</c> es ideal |
| 400 |
para los servidores que se acceden con poca frecuencia para llevar a cabo |
| 401 |
ocacionales tareas de copia de seguridad, tales como backup de los servidores, |
| 402 |
cortafuegos y routers. |
| 403 |
</p> |
| 404 |
|
| 405 |
</body> |
| 406 |
</section> |
| 407 |
<section> |
| 408 |
<title>¡Finalizado!</title> |
| 409 |
<body> |
| 410 |
|
| 411 |
<p> |
| 412 |
Ahora que la gestión de claves para OpenSSH esta completa, debe estar |
| 413 |
familiarizado con las claves RSA y DSA y saber como utilizarlas de forma |
| 414 |
conveniente y segura. Asegúrese de comprobar los siguientes recursos: |
| 415 |
</p> |
| 416 |
|
| 417 |
</body> |
| 418 |
</section> |
| 419 |
</chapter> |
| 420 |
|
| 421 |
<chapter id="recursos"> |
| 422 |
<title>Recursos</title> |
| 423 |
<section> |
| 424 |
<body> |
| 425 |
|
| 426 |
<ul> |
| 427 |
<li> |
| 428 |
Leer <uri link="/doc/es/articles/openssh-key-management-p1.xml">Parte |
| 429 |
1</uri> y <uri link="/doc/en/articles/openssh-key-management-p3.xml">Parte |
| 430 |
3</uri> de la serie de Daniel en gestión de claves para OpenSSH. |
| 431 |
</li> |
| 432 |
<li> |
| 433 |
Visite el <uri link="http://www.openssh.com/">sitio de desarrollo de |
| 434 |
OpenSSH</uri> |
| 435 |
</li> |
| 436 |
<li> |
| 437 |
Obtenga la <uri link="http://www.gentoo.org/proj/en/keychain/index.xml"> |
| 438 |
versión más reciente de keychain</uri> |
| 439 |
</li> |
| 440 |
<li> |
| 441 |
Revise las <uri link="http://www.openssh.com/faq.html">OpenSSH FAQ</uri> |
| 442 |
</li> |
| 443 |
<li> |
| 444 |
<uri link="http://www.chiark.greenend.org.uk/~sgtatham/putty/">PuTTY es un |
| 445 |
excelente cliente ssh para máquinas Windows</uri> |
| 446 |
</li> |
| 447 |
<li> |
| 448 |
Puede encontrar el libro de ayuda de O'Reilly "SSH, The Secure Shell: The |
| 449 |
Definitive Guide". <uri link="http://www.snailbook.com/">El sitio del Autor |
| 450 |
</uri> contiene información acerca del libro, FAQ, noticias, y |
| 451 |
actualizaciones. |
| 452 |
</li> |
| 453 |
</ul> |
| 454 |
|
| 455 |
</body> |
| 456 |
</section> |
| 457 |
</chapter> |
| 458 |
</guide> |
Archives