Attachment 167557 Details for Bug 239656 – Traducción completa

Traducción completa

openssh-key-management-p2.xml (text/plain), 17.93 KB, created by Javier Vecino (Coghan) on 2008-10-07 19:05:47 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Javier Vecino (Coghan)

Created: 2008-10-07 19:05:47 UTC

Size: 17.93 KB

patch

obsolete

><?xml version = '1.0' encoding = 'UTF-8'?>
>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
>
><guide link="/doc/es/articles/openssh-key-management-p2.xml" disclaimer="articles" lang="es">
><title>GestiÃ³n de claves para OpenSSH, Parte 2</title>
>
><author title="Author" >
>  <mail link="drobbins@gentoo.org" >Daniel Robbins</mail>
></author>
><author title="Traductor" >
>  <mail link="coghan@shrekyfiona.cc" >Javier Vecino</mail>
></author>
>
><abstract>
>Muchos desarrolladores usan las excelencias de OpenSSH como sustituto cifrado y
>seguro de los venerables comandos tenet y rsh. Una de las caracterÃsticas que
>mÃ¡s intrigan de OpenSSH es la habilidad para validar usuarios usando los
>protocolos RSA y DSA, que se basan en un par de claves numÃ©ricas
>complementarias. Uno de los principales atractivos de la validaciÃ³n RSA y DSA es
>la promesa de ser capaz de establecer conexiones a sistemas remotos sin
>suministrar una contraseÃ±a. En este segundo artÃculo, Daniel nos introduce en
>ssh-agent (una cachÃ© de claves privadas) y keychain, unos scripts de bash
>especialmente diseÃ±ados para hacer la validaciÃ³n basada en clave increiblemente
>cÃ³moda y flexible.
></abstract>
>
>
>
><version>1.2</version>
><date>2005-10-09</date>
>
><chapter>
><title>Presentando ssh-agent y keychain</title>
><section>
><title>Presentando ssh-agent</title>
><body>
>
><p>
>ssh-agent, incluido con la distribuciÃ³n de OpenSSH, es un programa especialmente
>diseÃ±ado para manejar las claves RSA y DSA de forma agradable y segura (vea
>la Parte 1 de esta serie para una introcucciÃ³n a la validaciÃ³n RSA y DSA.)
>ssh-agent, a diferencia de ssh, es un servicio diseÃ±ado con el Ãºnico objetivo de
>almacenar en cachÃ© el descifrado de sus claves privadas.
></p>
>
><p>
>ssh incluye soporte para comunicarse con ssh-agent, permitiendo a ssh adquirir
>sus claves privadas descifradas sin preguntarle por la contraseÃ±a en cada nueva
>conexiÃ³n. Simplemente utilice ssh-add para aÃ±adir sus claves privadas a la cachÃ©
>de shh-agent. En un Ãºnico proceso; despuÃ©s de utilizar ssh-add, ssh usarÃ¡ su
>clave privada desde ssh-agent, en lugar de preguntarle por una contraseÃ±a.
></p>
>
></body>
></section>
><section>
><title>Uso de ssh-agent</title>
><body>
>
><p>
>Echemos un vistazo a como trabaja todo este sistema de cachÃ© de claves con
>ssh-agent. Al iniciar ssh-agent desde consola, muestra unas variables de entorno
>importantes antes de desconectarse de la consola y continuar su proceso en
>segundo plano. He aquÃ un ejemplo de la salida generada por ssh-agent cuando se
>inicia:
></p>
>
><pre caption="Lanzando el servidio ssh-agent">
>$ <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>
>Como puede ver, la salida de ssh-agent es en realidad una serie de comandos en
>bash; si se ejecutan, estos comandos ajustarÃas un par de variables de entorno,
>SSH_AUTH_SOCK y SSH_AGENT_PID. Debido a la inclusiÃ³n  del comando export, estas
>variables de entorno estarÃ¡n disponibles para cualquier comando adicional que se
>lance posteriormente. Bien, todo pasarÃa si estas lÃneas fueran evaluadas por la
>consola, pero ahora solamente se ha enviado a stdout. Para solucionarlo, podemos
>llamar a ssh-agent como sigue:
></p>
>
><pre caption="Otra manera de llamar a ssh-agent">
>$ <i>eval `ssh-agent`</i>
></pre>
>
><p>
>Este comando le dice a bash que lance ssh-agent y evalÃºe su salida.  Invocando
>de esta forma (con comillas inclinadas, no con comillas simples normales), las
>variables SSH_AGENT_PID y SSH_AUTH_SOCK serÃ¡n ajustadas y exportadas por su
>consola, estando estas variables a disposiciÃ±on de todos los procesos nuevos que
>se puedan iniciar durante su sesiÃ³n.
></p>
>
><p>
>La mejor manera de lanzar ssh-agent es aÃ±adir la lÃnea anterior a su
><path>~/.bash_profile</path>; de esta manera, todos los programas iniciados en
>su sesiÃ³n verÃ¡n las variables de entorno, serÃ¡n capaces de localizar ssh-agent y
>cosultar claves cuando sea necesario. La variable de entorno particularmente
>importante es SHH_AUTH_SOCK; contiene un enlace a un socket UNIX que ssh y scp
>pueden usar para establecer comunicaciÃ³n con ssh-agent.
></p>
>
></body>
></section>
><section>
><title>Usando ssh-add</title>
><body>
>
><p>
>Por supuesto, ssh-agent se inicia con una cachÃ© de claves descifradas vacÃa.
>Antes de que podamos utilizar ssh-agent, en primer lugar hay que aÃ±adir
>nuestra(s) clave(s) privada(s) a la cachÃ© de ssh-agent utilizando el comando
>ssh-add. En el siguiente ejemplo uso ssh.add para aÃ±adir mi clave privada RSA
><path>~/.ssh/identity</path> a la cachÃ© de ssh-agent:
></p>
>
><pre caption="Cargando clave privada RSA a la cachÃ© de ssh-agent's">
>$ <i>ssh-add ~/.ssh/identity</i>
>Need passphrase for /home/drobbins/.ssh/identity
>Enter passphrase for /home/drobbins/.ssh/identity
>(enter passphrase)
></pre>
>
><p>
>Como puede ver, ssh-add pregunta por mi contraseÃ±a a fin de que la clave privada
>pueda ser descifrada y se almacena en la cachÃ© de ssh-agent, lista para usar.
>Una vez que haya usado ssh-add para agregar su clave (o claves) privada a la
>cachÃ© de ssh-agent SSH_AUTH_SOCK se define en su actual consola (debe ser asÃ,
>si lanzÃ³ ssh-agent desde su ~/.bash_profile), entonces ya puede usar ssh y scp
>para establecer conexiones con sistemas remotos sin suministrar su contraseÃ±a.
></p>
>
></body>
></section>
><section>
><title>Limitaciones de ssh-agent</title>
><body>
>
><p>
>ssh-agent es realmente cool, pero su configuraciÃ³n por defecto tiene unos pocos
>inconvenientes. Echemos un vistazo a ellos.
></p>
>
><p>
>Por uno lado, con <c>eval `ssh-agent`</c> en <path>~/.bash_profile</path>, una
>nueva copia de ssh-agent es iniciada cada inicio de sesiÃ³n; no solamente es un
>desperdicio, tambiÃ©n significa que necesita usar ssh-add para aÃ±adir una clave
>privada para cada nueva copia de ssh-agent. Si solo abre una consola en su
>sistema, esto no es mayor problema, pero la mayorÃa de nosotros abrimos un buen
>nÃºmero de terminales y es necesario escribir la contraseÃ±a cada vez que se abre
>una nueva consola. TÃ©cnicamente, no hay razÃ³n por la que debiera ser necesario
>esto mientras un solo proceso ssh-agent fuera suficiente.
></p>
>
><p>
>Otro problema por defecto en ssh-agent es que la instalaciÃ³n no es compatible
>con cron jobs. Los trabajos iniciados por el proceso cron, no heredan la
>variable de entorno SSH_AUTH_SOCK, y por consiguiente no sabrÃ¡n que hay un
>proceso ssh-agent en ejecuciÃ³n ni cÃ³mo ponerse en contacto con Ã©l. Este problema
>tambiÃ©n es corregible.
></p>
>
></body>
></section>
><section>
><title>Introducir keychain</title>
><body>
>
><p>
>Para resolver estos problemas, He escrito un prÃ¡ctico front-end basado en bash
>llamado keychain. Lo que hace especial a keychain es el hecho de que permite
>utilizar un solo proceso ssh-agent por sistema, no sÃ³lo por sesiÃ³n. Esto
>significa que usted sÃ³lo tiene que hacer un ssh-add por clave privada, y punto.
>Como veremos en breve, incluso keychain ayuda a optimizar el proceso ssh-add
>tratando de aÃ±adir solamente las claves privadas que no estÃ©n en ejecuciÃ³n en la
>cachÃ© de ssh-agent.
></p>
>
><p>
>AquÃ hay una muestra de como funciona keychain. Cuando se inicia a partir de su
><path>~/.bash_profile</path>, se comprueba en primer lugar si algÃºn ssh-agent se
>estÃ¡ ejecutando. Si no es asÃ, entonces se iniciarÃ¡ ssh-agent y registrarÃ¡ las
>importantes variables SSH_AUTH_SOCK y SSH_AGENT_PID en el archivo
><path>~/.ssh-agent</path> para su custodia y posterior uso. Esta es la mejor
>manera de iniciar keychain; como hicimos con ssh-agent, es necesario realizar la
>configuraciÃ³n en <path>~/.bash_profile</path>:
></p>
>
><pre caption="ConfiguraciÃ³n de ssh-agent en ~/.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>
>
><p>
>Como puede ver, con keychain suministramos al fichero <path>~/.ssh-agent</path>
>en lugar de evaluar la salida como cuando usamos ssh-agent directamente. Sin
>embargo el resultado es el mismo -- nuestra cada vez mÃ¡s importÃ¡nte variable
>SSH_AUTH_SOCK es definida, y ssh-agent se estÃ¡ ejecutando y listo para usarse.
>Y debido a que se registra SSH_AUTH_SOCK en <path>~/.ssh-agent</path>, nuestros
>propios scripts y cron jobs pueden conectarse fÃ¡cilmente con ssh-agent solo con
>la lectura del archivo <path>~/.ssh-agent</path>. keychain tambiÃ©n se aprovecha
>de este fichero; recuerde cuando keychain se iniciÃ³, este comprueba si ssh-agent
>estÃ¡ ejecutÃ¡ndose. Si es asÃ, se usa el fichero <path>~/.ssh-agent</path> para
>adquirir la configuraciÃ³n apropiada de SSH_AUTH_SOCK, por lo tanto le permite
>utilizar el actual agente en lugar de iniciar uno nuevo. keychain solo iniciarÃ¡
>un nuevo proceso ssh-agent sÃ³lo si el fichero <path>~/.ssh-agent</path> estÃ¡
>rancio (apunta a un ssh-agent inexistente) o si el mismo
><path>~/.ssh-agent</path> no existe.
></p>
>
></body>
></section>
><section>
><title>Instalar keychain</title>
><body>
>
><p>
>La instalaciÃ³n de keychain es fÃ¡cil. En primer lugar, vaya a la
><uri link="http://www.gentoo.org/proj/en/keychain/index.xml">pÃ¡gina del proyecto
>keychain</uri> y descarge la versiÃ³n mÃ¡s reciente disponible de las fuentes de
>keychain o instale usando emerge, de la siguiente manera:
></p>
>
><pre caption="Instalar keychain">
># <i>emerge keychain</i>
></pre>
>
><p>
>Ahora que keychain esta en <path>/usr/bin/</path>, aÃ±ada a su
><path>~/.bash_profile</path>, aÃ±adiendo la ruta de su clave privada como
>argumento. AquÃ hay una buena configuraciÃ³n para habilitar keychain desde
><path>~/.bash_profile</path>:
></p>
>
><pre caption="Activando keychain en ~/.bash_profile">
>#!/bin/bash
>#on this next line, we start keychain and point it to the private keys that
>#we'd like it to cache
>/usr/bin/keychain ~/.ssh/id_rsa ~/.ssh/id_dsa
>source ~/.ssh-agent > /dev/null
>#sourcing ~/.bashrc is a good thing
>source ~/.bashrc
></pre>
>
></body>
></section>
><section>
><title>Keychain en acciÃ³n</title>
><body>
>
><p>
>Una vez configurado su <path>~/.bash_profile</path> para llamar a keychain en
>cada inicio de sesiÃ³n, reinicie su sesiÃ³n, Al hacerlo, keychain iniciarÃ¡
>ssh-agent, registrarÃ¡ la configuraciÃ³n de la variable de entorno del agente en
><path>~/.ssh-agent</path>, y le pedirÃ¡ las contraseÃ±as de las claves privadas
>especificadas en la linea de comandos keychain en <path>~/.bash_profile</path>:
></p>
>
><figure link="/images/docs/l-ssh-1.gif" caption="Keychain se inicia por primera
>vez"/>
>
><p>
>Una vez que introduzca su contraseÃ±a, sus claves privadas se almacenarÃ¡n en
>cachÃ©, y keychain finalizarÃ¡. Entonces, se cargarÃ¡ ~/.ssh-agent, inicializando
>su sesiÃ³n para ser usada con ssh-agent. Ahora, si reinicia su sesiÃ³n nuevamente,
>notarÃ¡ que keychain encontrarÃ¡ ssh-agent como proceso existente; que no finalizÃ³
>cuando cerrÃ³ su sesiÃ³n. AdemÃ¡s, keychain verificarÃ¡ que las claves privadas
>especificadas estÃ¡n listas en la cachÃ© de ssh-agent. Si no es asÃ, entonces le
>pedirÃ¡ la contraseÃ±a, pero si todo va bien, su actual ssh-agent todavÃa
>contendrÃ¡ la clave privada que previamente aÃ±adiÃ³, lo que significa que no se le
>preguntarÃ¡ por una contraseÃ±a:
></p>
>
><figure link="/images/docs/l-ssh-2.gif" caption="Keychain encontrando un
>existente ssh-agent"/>
>
><p>
>Felicidades, acaba de iniciar sesiÃ³n y deberÃa ser capaz de usar ssh y scp en
>sistemas remotos; no necesita usar ssh-add despuÃ©s de iniciar la sesiÃ³n, y ssh y
>scp no le pedirÃ¡n una contraseÃ±a. De hecho, siempre y cuando el proceso inicial
>ssh-agent siga en marcha, podrÃ¡ acceder y establecer conexiones ssh sin
>suministrar una contraseÃ±a. Y es muy probable que su proceso ssh-agent continue
>ejecutandose hasta que la mÃ¡quina sea reiniciada; probablemente lo configure en
>un sistema Linux, Â¡es posible que no sea necesario que introduzca su contraseÃ±a
>en varios meses!. Bienvenido al mundo de la seguridad, conexiones libres de
>contraseÃ±as usando la validaciÃ³n RSA y DSA.
></p>
>
><p>
>Adelante, cree varias sesiones nuevas, y verÃ¡ que keychain "engancharÃ¡"; al
>mismo proceso ssh-agent cada vez. No hay que olvidar que puede enganchar sus
>cron jobs y scripts al proceso ssh-agent en ejecuciÃ³n. Para utilizar los
>comandos ssh o scp desde scripts de consola y cron jobs, asegÃºrese de que
>obtiene su fichero <path>~/.ssh-agent</path> en primer lugar:
></p>
>
><pre caption="Obteniendo el fichero ~/.ssh-agent">
>$ <i>source ~/.ssh-agent</i>
></pre>
>
><p>
>Luego, cualquier comando ssh o scp serÃ¡n capaces de encontrar el actual proceso
>ssh-agent en ejecuciÃ³n y establecer una coneciÃ³n segura libre de contraseÃ±as
>igual que desde la consola.
></p>
>
></body>
></section>
><section>
><title>Opciones de keychain</title>
><body>
>
><p>
>DespuÃ©s de tener funcionando keychain, asegurese de teclear
><c>keychain --help</c> para familiarizarse con todas las opciones de linea de
>comandos de keychain. Vamos a echar un vistazo a uno en partiular: la opciÃ³n
><c>--clear</c>
></p>
>
><p>
>RecordarÃ¡ que en la parte 1, expliquÃ© que el uso de claves privadas sin cifrar
>es una prÃ¡ctica peligrosa, ya que permite a cualquiera robar su clave privada y
>usarla para acceder a sus cuentas remotas de cualquier sistema sin suministrarle
>contraseÃ±a. Bien, mientras que keychain no es vulnerable a este tipo de abuso
>(que es siempre y cuando utilice las claves privadas cifradas), hay una
>debilidad potencialmente explotable directamente relacionada con el hecho que
>keychain se enganche facilmente a un proceso ssh-agent de larga duraciÃ³n.
>Â¿Que pasarÃa, pensÃ©, sin algÃºn intruso consiguiera averiguar mi contraseÃ±a o
>frase de acceso a mi sistema local? Si de alguna manera se pudiera acceder bajo
>mi usuario, keychain les garantizarÃa el acceso instantÃ¡neo a mis claves
>privadas descifradas, por lo que no es obvio para ellos tener acceso a mis otras
>cuentas.
></p>
>
><p>
>Ahora, antes de continuar, vamos a poner este riesgo de seguridad en
>perspectiva. Si algÃºn usuario malintencionado de alguna manera pudiera validarse
>como yo, keychain permitirÃa el acceso a mis cuentas remotas. Sin embargo, aun
>asÃ, serÃa muy difÃcil para el intruso robar mis claves privadas descifradas ya
>que todavÃa estÃ¡n encriptadas en el disco. AdemÃ¡s, para tener acceso a mis
>claves privadas requiere que un usuario realmente se valide como yo. AsÃ que,
>abusar de ssh-agent serÃa mÃ¡s difÃcil que simplemente robar una clave privada
>sin cifrar, que sÃ³lo requiere que un intruso acceda de alguna manera a mis
>ficheros en <path>~/.ssh</path>, ya sea validado como yo o no. Sin embargo, si
>un intruso logrÃ³ acceder en condiciones a validarse como yo, ello supondrÃa que
>podrÃa hacer un poco mÃ¡s de daÃ±o adicional usando mis claves privadas
>descifradas. Por lo tanto, si usted pasase a estar usando keychain en un
>servidor que no se validase a menudo o no activamente para controlar las brechas
>de seguridad, entonces considere utilizar la opciÃ³n <c>--clear</c> para
>proporcionar una capa de seguridad adicional.
></p>
>
><p>
>La opciÃ³n <c>--clear</c> permite decirle a keychain suponer que cada nuevo
>acceso a su cuenta deberÃa ser considerado como una potencial brecha en la
>seguridad hasta que se demuestre lo contrario. Al iniciar keychain con la opciÃ³n
><c>--clear</c> , keychain limpia inmediatamente todas sus claves privadas de la
>cachÃ© de ssh-agent cuando se inicia sesiÃ³n, antes de realizar sus funciones
>normales. Por lo tanto, si usted es un intruso, keychain le pedirÃ¡ las
>contraseÃ±as en lugar de darle acceso a su actual conjunto de claves en cachÃ©.
>Sin embargo, a pesar de que ello aumenta la seguridad, hace las cosas un poco
>mÃ¡s incÃ³modas y muy similar a ejecutar ssh-agent por sÃ solo, sin keychain. En
>este caso, como suele ser, uno puede optar por una mayor seguridad o mayor
>comodidad, pero no ambos.
></p>
>
><p>
>A pesar de ello, utilizando kechain con <c>--clear</c> todavÃa tiene ventajas
>sobre el uso de ssh-agent por sÃ solo; recuerde, cuando se usa keychain
><c>--clear</c>, sus cron jobs y scripts seguirÃ¡n siendo capaces de establecer
>conexiones sin contraseÃ±as; esto es debido a que sus claves privadas son
>limpiadas en el acceso, no al salir. Desde un cierre de sesiÃ³n del sistema no
>constituye una potencial brecha de seguridad, no hay razÃ³n para que keychain
>limpie las claves de ssh-agent. Por lo tanto, la opciÃ³n <c>--clear</c> es ideal
>para los servidores que se acceden con poca frecuencia para llevar a cabo
>ocacionales tareas de copia de seguridad, tales como backup de los servidores,
>cortafuegos y routers.
></p>
>
></body>
></section>
><section>
><title>Â¡Finalizado!</title>
><body>
>
><p>
>Ahora que la gestiÃ³n de claves para OpenSSH esta completa, debe estar
>familiarizado con las claves RSA y DSA y saber como utilizarlas de forma
>conveniente y segura. AsegÃºrese de comprobar los siguientes recursos:
></p>
>
></body>
></section>
></chapter>
>
><chapter id="recursos">
><title>Recursos</title>
><section>
><body>
>
><ul>
>  <li>
>    Leer <uri link="/doc/es/articles/openssh-key-management-p1.xml">Parte
>    1</uri> y <uri link="/doc/en/articles/openssh-key-management-p3.xml">Parte
>    3</uri> de la serie de Daniel en gestiÃ³n de claves para OpenSSH.
>  </li>
>  <li>
>    Visite el <uri link="http://www.openssh.com/">sitio de desarrollo de
>    OpenSSH</uri>
>  </li>
>  <li>
>    Obtenga la <uri link="http://www.gentoo.org/proj/en/keychain/index.xml">
>    versiÃ³n mÃ¡s reciente de keychain</uri>
>  </li>
>  <li>
>    Revise las <uri link="http://www.openssh.com/faq.html">OpenSSH FAQ</uri>
>  </li>
>  <li>
>    <uri link="http://www.chiark.greenend.org.uk/~sgtatham/putty/">PuTTY es un
>    excelente cliente ssh para mÃ¡quinas Windows</uri>
>  </li>
>  <li>
>    Puede encontrar el libro de ayuda de O'Reilly "SSH, The Secure Shell: The
>    Definitive Guide". <uri link="http://www.snailbook.com/">El sitio del Autor
>    </uri> contiene informaciÃ³n acerca del libro, FAQ, noticias, y
>    actualizaciones.
>  </li>
></ul>
>
></body>
></section>
></chapter>
></guide>

Actions: View

Attachments on bug 239656: 167209 | 167557 | 167604