nimiux 14/08/08 15:27:13 Modified: openssh-key-management-p2.xml Log: Fix typos and format. No version bump
Revision Changes Path 1.6 xml/htdocs/doc/es/articles/openssh-key-management-p2.xml file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p2.xml?rev=1.6&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p2.xml?rev=1.6&content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p2.xml?r1=1.5&r2=1.6 Index: openssh-key-management-p2.xml =================================================================== RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p2.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- openssh-key-management-p2.xml 15 Aug 2011 15:36:40 -0000 1.5 +++ openssh-key-management-p2.xml 8 Aug 2014 15:27:13 -0000 1.6 @@ -1,5 +1,5 @@ <?xml version = '1.0' encoding = 'UTF-8'?> -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p2.xml,v 1.5 2011/08/15 15:36:40 nimiux Exp $ --> +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p2.xml,v 1.6 2014/08/08 15:27:13 nimiux Exp $ --> <!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> <guide disclaimer="articles" lang="es"> @@ -20,7 +20,7 @@ <abstract> Muchos desarrolladores usan las excelencias de OpenSSH como sustituto -cifrado y seguro de los venerables comandos telnet y rsh. Una de las +cifrado y seguro de los venerables órdenes telnet 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 @@ -87,10 +87,10 @@ <p> Como puede ver, la salida de ssh-agent es en realidad una serie de -comandos en bash; si se ejecutan, estos comandos ajustarían un par de +órdenes en bash; si se ejecutan, estas órdenes ajustarían 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 +inclusión de la orden export, estas variables de entorno estarán +disponibles para cualquier orden adicional que se lance posteriormente. Bueno, todo esto 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: @@ -101,7 +101,7 @@ </pre> <p> -Este comando le dice a bash que lance ssh-agent y evalúe su +Esta orden le dice a bash que lance ssh-agent y evalúe su salida. Invocando de esta forma (con comillas inclinadas hacia atrás, no con comillas simples normales), las variables SSH_AGENT_PID y SSH_AUTH_SOCK serán ajustadas y exportadas por su consola, estando a @@ -129,7 +129,7 @@ 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 +utilizando la orden 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> @@ -167,7 +167,7 @@ <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 sólo abre una consola en su sistema, +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 @@ -193,7 +193,7 @@ 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 único proceso ssh-agent por sistema, -no sólo por sesión. Esto significa que usted sólo tiene que hacer un +no solo por sesión. Esto significa que solo 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 @@ -225,7 +225,7 @@ <comment># las variables de entorno se almacenan usando un fichero # nombredeservidor-sh, por lo tanto, reemplace <nombredeservidor> # por el nombre de su servidor y el "sh" estándar por "csh" o "fish" -# si usa alguna de éstas shells</comment> +# si usa alguno de estos intérpretes de comandos</comment> </pre> <p> @@ -236,14 +236,14 @@ SSH_AUTH_SOCK es definida, y ssh-agent se está ejecutando y listo para usarse. Debido a que se registra SSH_AUTH_SOCK en <path>~/.keychain/</path>, nuestros propios guiones y tareas cron pueden -conectar fácilmente con ssh-agent sólo con la lectura del archivo +conectar fácilmente con ssh-agent solo con la lectura del archivo <path>~/.keychain/<nombredeservidor>-sh</path>. keychain también aprovecha este fichero; recuerde cuando keychain se inició, este comprueba si ssh-agent está ejecutándose. Si es así, se usa el fichero <path>~/.keychain/</path> apropiado para adquirir la configuración correcta de SSH_AUTH_SOCK, por lo tanto le permite utilizar el actual agente en lugar de iniciar uno nuevo. keychain iniciará un nuevo -proceso ssh-agent sólo si el fichero <path>~/.keychain/</path> no está +proceso ssh-agent solo si el fichero <path>~/.keychain/</path> no está en condiciones (esto es, apunta a un ssh-agent inexistente) o si el propio <path>~/.keychain/</path> no existe. </p> @@ -277,9 +277,9 @@ /usr/bin/keychain ~/.ssh/id_rsa ~/.ssh/id_dsa <comment># las variables de entorno se almacenan usando un fichero -# nombredeservidor-shell, por lo tanto, reemplace, +# nombredeservidor-interpretedecomandos, por lo tanto, reemplace, # <nombredeservidor> por el nombre de su servidor, y el "sh" -# estándar por "csh" o "fish" si usa alguna de éstas shells</comment> +# estándar por "csh" o "fish" si usa alguno de estos intérpretes de comandos</comment> source ~/.keychain/<hostname>-sh > /dev/null <comment># es recomendable hacer source de ~/.bashrc</comment> @@ -337,25 +337,26 @@ <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 +que puede enganchar sus trabajos cron y guiones al proceso ssh-agent +en ejecución. Para utilizar las órdenes ssh o scp desde guiones de consola y trabajos cron, asegúrese de que obtiene su fichero -<path>~/.keychain/<nombredeservidor>-shell</path> en -primer lugar: +<path>~/.keychain/<nombredeservidor>-interpretedecomandos</path> +en primer lugar: </p> <pre caption="Haciendo source del fichero ~/.keychain/ apropiado"> <comment>(Las variables de entorno se almacenan usando un fichero -nombredeservidor-shell, por lo tanto reemplace <nombredeservidor> -por el nombre de su servidor, y el "sh" estándar por "csh" o "fish" -si usa alguna de éstas shells)</comment> +nombredeservidor-interpretedecomandos, por lo tanto reemplace +<nombredeservidor> por el nombre de su servidor, y el "sh" +estándar por "csh" o "fish" si usa alguno de estos intérpretes de +comandos)</comment> $ <i>source ~/.keychain/<nombredeservidor>-sh</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 conexión segura -libre de contraseñas igual que desde la consola. +Luego, cualquier orden ssh o scp podrán encontrar el proceso actual +ssh-agent en ejecución y establecer una conexión segura libre de +contraseñas igual que desde la consola. </p> </body> </section> @@ -392,15 +393,15 @@ 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 +mis claves privadas descifradas ya que todavía están cifradas 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 +que solo 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 +usando mis claves privadas descifradas. Por lo tanto, si 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 @@ -414,7 +415,7 @@ 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 +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 si solo, sin @@ -425,7 +426,7 @@ <p> A pesar de ello, utilizando kechain con <c>--clear</c> todavía tiene ventajas sobre el uso de ssh-agent por si solo; recuerde, cuando se -usa keychain <c>--clear</c>, sus cron jobs y scripts seguirán siendo +usa keychain <c>--clear</c>, sus trabajos cron y guiones 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
