[gentoo-commits] gentoo commit in xml/htdocs/doc/es/articles: openssh-key-management-p3.xml

[John Christian Stoddart (chiguire)]

chiguire    08/10/11 22:33:10

  Modified:             openssh-key-management-p3.xml
  Log:
  revised spanish translation--spellchecking is not an evil practice

Revision  Changes    Path
1.2                  xml/htdocs/doc/es/articles/openssh-key-management-p3.xml

file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p3.xml?rev=1.2&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p3.xml?rev=1.2&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p3.xml?r1=1.1&r2=1.2

Index: openssh-key-management-p3.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p3.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- openssh-key-management-p3.xml	11 Oct 2008 21:58:21 -0000	1.1
+++ openssh-key-management-p3.xml	11 Oct 2008 22:33:10 -0000	1.2
@@ -1,5 +1,5 @@
 <?xml version = '1.0' encoding = 'UTF-8'?>
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p3.xml,v 1.1 2008/10/11 21:58:21 chiguire Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p3.xml,v 1.2 2008/10/11 22:33:10 chiguire Exp $ -->
 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
 
 <guide link="/doc/es/articles/openssh-key-management-p3.xml" disclaimer="articles" lang="es">
@@ -12,9 +12,9 @@
 </author>
 
 <abstract>
-En este tercer artículo de la serie, Daniel Robbins muesta como
-mejorar las conexiones del agente OpenSSH. Así como las recientes
-mejoras en el guión de consola keychain.
+En este tercer artículo de la serie, Daniel Robbins muestra como
+mejorar las conexiones del agente OpenSSH, así como las recientes
+mejoras en el guión keychain.
 </abstract>
 
 <!-- La versión original de este artículo fue publicada por IBM
@@ -48,14 +48,14 @@
 </p>
 
 <p>
-Desde la Parte 2 publicada en developWorks en Septiembre de 2001, y
-más tarde referenciados en Slashdot y Freshmeat (vease <uri
+Desde la Parte 2 publicada en developerWorks en Septiembre de 2001, y
+más tarde referenciados en Slashdot y Freshmeat (véase <uri
 link="#recursos">Recursos</uri> más adelante en este artículo los
 enlaces a estos sitios), muchas personas han empezado a usar keychain,
 y le han realizado algunos cambios, he recibido sobre unos 20 parches
 de gran calidad de desarrolladores de todo el mundo. He incorporado
 muchos de estos parches al código de keychain, que está ahora en la
-versión 1.8 (vea <uri link="#recursos">Recursos</uri>).  Envío mis más
+versión 1.8 (vea <uri link="#recursos">Recursos</uri>). Envío mis más
 sincero agradecimiento a todos aquellos que enviaron parches, informes
 de errores, y notas de agradecimiento.
 </p>
@@ -75,10 +75,10 @@
 recibí un e-mail de Charles Karney de Sharnof Corporation, que
 amablemente me informó de las nuevas habilidades del nuevo agente
 intermedio de validación de OpenSSH, le echaremos un vistazo en
-breve. Además, Charles hizo incapié que la ejecución de ssh-agent en
+breve. Además, Charles hizo hincapié que la ejecución de ssh-agent en
 máquinas poco fiables es muy peligroso: si alguien logra acceso como
-root en el sistema, entonces sus claves descifradas puedes ser
-extraidas desde ssh-agent. Aunque la extracción de las claves sería
+superusuario en el sistema, entonces sus claves descifradas puedes ser
+extraídas desde ssh-agent. Aunque la extracción de las claves sería
 algo difícil, está dentro de las habilidades de los crackers
 profesionales. Y ante mero hecho de que el robo de la clave privada
 sea medianamente posible deberemos tomar medidas en primer lugar para
@@ -88,24 +88,24 @@
 <p>
 Para formular una estrategia para proteger nuestras claves privadas,
 debemos primero poner las máquinas a las que accedemos dentro de una
-de dos categorías.  Si un host particular está bien asegurado o
-aislado -- siendo poco probable el acceso con éxito del root por medio
-de una vulnerabilidad -- entonces la máquina debe ser considerada un
-host de confianza. Sin embargo, si una máquina es usada por muchas
-personas o si tiene alguna duda acerca de la seguridad del sistema,
-entonces la máquina debería ser considerada como un host no
-confiable. De esta manera, incluso si la seguridad del sistema se ve
-comprometida, en primer lugar no habrá un ssh-agent a mano del intruso
-para extraer las claves.
+de dos categorías. Si un anfitrión particular está bien asegurado o
+aislado -- siendo poco probable el acceso con éxito del superusuario
+por medio de una vulnerabilidad -- entonces la máquina debe ser
+considerada un anfitrión de confianza. Sin embargo, si una máquina es
+usada por muchas personas o si tiene alguna duda acerca de la
+seguridad del sistema, entonces la máquina debería ser considerada
+como un anfitrión no confiable. De esta manera, incluso si la
+seguridad del sistema se ve comprometida, en primer lugar no habrá un
+ssh-agent a mano del intruso para extraer las claves.
 </p>
 
 <p>
 Sin embargo, esto crea un problema, si no se puede ejecutar ssh-agent
-en hosts no confiables, entonces ¿como podemos establecer conexiónes
+en anfitriones no confiables, entonces ¿como podemos establecer conexiones
 ssh, sin contraseñas y seguras en estos sistemas? La respuesta es usar
-solamente ssh-agent y keychain en hosts confiables, y usar la nueva
+solamente ssh-agent y keychain en anfitriones confiables, y usar la nueva
 capacidad de OpenSSH de validación intermedia para extender la
-validación sin contraseña en los hosts inseguros. En pocas palabras,
+validación sin contraseña en los anfitriones inseguros. En pocas palabras,
 el trabajo de la validación intermedia es permitir a las sesiones ssh
 remotas contactar con un ssh-agent que esté ejecutándose en un sistema
 confiable.
@@ -114,7 +114,7 @@
 </section>
 
 <section>
-<title>Agente de vaiidación intermedia</title>
+<title>Agente de validación intermedia</title>
 <body>
 
 <p>
@@ -131,14 +131,15 @@
 máquinas confiables y no confiables"/>
 
 <p>
-El problema con este enfoque es que si alguien consigue acceso de root
-en notrust1 o notrust2, entonces, por supuesto, es posible que estas
-personas extraigan las claves desde el ahora vulnerable proceso
-ssh-agent. Para solucionar este problema, drobbins para la ejecución
-de ssh-agent y keychain en los inseguros hosts notrust1 y notrust2. De
-hecho, es incluso más cuidadoso, drobbins decide usar solamente
-ssh-agent y keychain en lappy. Esto limita la exposición de sus claves
-privadas descifradas, protegiéndolas contra el robo.
+El problema con este enfoque es que si alguien consigue acceso de
+superusuario en notrust1 o notrust2, entonces, por supuesto, es
+posible que estas personas extraigan las claves desde el ahora
+vulnerable proceso ssh-agent. Para solucionar este problema, drobbins
+para la ejecución de ssh-agent y keychain en los inseguros anfitriones
+notrust1 y notrust2. De hecho, es incluso más cuidadoso, drobbins
+decide usar solamente ssh-agent y keychain en lappy. Esto limita la
+exposición de sus claves privadas descifradas, protegiéndolas contra
+el robo.
 </p>
 
 <figure link="/images/docs/l-ssh-4.jpg" caption="ssh-agent ejecutándose
@@ -147,7 +148,7 @@
 <p>
 Por supuesto, el problema con este enfoque es que drobbins solamente
 puede establecer conexiones sin contraseña desde lappy. Veamos como
-habilitar la validacion intermedia y solucionar este problema.
+habilitar la validación intermedia y solucionar este problema.
 </p>
 
 <p>
@@ -198,19 +199,19 @@
 Si intenta una configuración similar y se da cuenta que la transmisión
 no funciona, pruebe utilizando <c>ssh -A</c> en lugar del anterior ssh
 a secas para habilitar explícitamente la validación intermedia. Aquí
-hay un driagrama sobre lo que sucede detrás del escenario cuando
+hay un diagrama sobre lo que sucede detrás del escenario cuando
 accedemos a trustbox y notrust1 usando la validación intermedia:
 </p>
 
 <figure link="/images/docs/l-ssh-5.jpg" caption="Agente intemedio en acción"/>
 
 <p>
-Como puede ver, cuando ssh conecta a trustbox, mantuiene una conexión
+Como puede ver, cuando ssh conecta a trustbox, mantiene una conexión
 con el ssh-agent ejecutado en lappy. Cuando una conexión ssh se
-realiza desde trustbox hacia notrust1, este nuevo proceso ssh mantenie
+realiza desde trustbox hacia notrust1, este nuevo proceso ssh mantiene
 la conexión validada por el anterior ssh, extendiendo la cadena de
-manera efectiva. Si esta cadena de validacion puede ser extendida más
-allá de notrust1 a otros hosts depende de como
+manera efectiva. Si esta cadena de validación puede ser extendida más
+allá de notrust1 a otros anfitriones depende de como
 <path>/etc/ssh/ssh_config</path> en notrust1 esté configurado. Mientas
 el agente intermedio este habilitado, todas las partes de la cadena
 serán capaces de validarse usando el ssh-agent ejecutado en el seguro
@@ -225,7 +226,7 @@
 
 <p>
 La validación intermedia ofrece una serie de ventajas de seguridad no
-mostradas.  Para convencerme de la importancia del agente de conexión
+mostradas. Para convencerme de la importancia del agente de conexión
 intermedia, Charles Karney ha compartido conmigo estas tres conceptos
 de seguridad:
 </p>
@@ -238,7 +239,7 @@
   </li>
   <li>
     ssh-agent sólo se ejecuta en la máquina de confianza. Esto evita
-    que un intruso reealice un volcado de memoria de un proceso
+    que un intruso realice un volcado de memoria de un proceso
     ssh-agent remoto y entonces extraiga su clave descifrada desde el
     volcado.
   </li>
@@ -250,7 +251,7 @@
 </ol>
 
 <p>
-El incoveniente de confiar en el agente de validación intermedio es
+El inconveniente de confiar en el agente de validación intermedio es
 que no resuelve el problema que permita a los cron jobs aprovechar la
 validación RSA/DSA. Una solución a este problema es crear todos los
 cron jobs que necesiten la validación RSA/DSA para que sean ejecutados
@@ -280,32 +281,32 @@
 fichero <path>~/.ssh-agent</path>; el nombre de este fichero ha
 cambiado a <path>~/.ssh-agent-[hostname]</path> de modo que keychain
 puede trabajar con los directorios home montados por NFS para que se
-puedan acceder desde varios hosts físicos. Además del fichero
+puedan acceder desde varios anfitriones físicos. Además del fichero
 <path>~/.ssh-agent-[hostname]</path>, ahora hay un fichero
 <path>~/.ssh-agent-csh-[hostname]</path> que puede ser leído por
-consolas csh y compatibles. Po último, una nueva opción
+consolas csh y compatibles. Por último, una nueva opción
 <c>--nocolor</c> ha sido añadida a fin de que la característica
 coloración pueda ser desactivada en caso de que se utilice un terminal
-no compatilble vt100.
+no compatible vt100.
 </p>
 </body>
 </section>
 
 <section>
-<title>Correcciones de compatibilidas de la consola</title>
+<title>Correcciones de compatibilidades de la consola</title>
 <body>
 
 <p>
 Si bien la funcionalidad de las mejoras han sido importantes, la gran
-mayoría de las correciones se han ocupado de los problemas de
-compatibilidad de la consola.  Verá, mientras keychain 1.0 requiere de
+mayoría de las correcciones se han ocupado de los problemas de
+compatibilidad de la consola. Verá, mientras keychain 1.0 requiere de
 bash, versiones posteriores fueron cambiadas para trabajar con
 cualquier consola compatible con sh. Este cambio permite a keychain
 trabajar "de forma poco común" en casi cualquier sistema UNIX,
 incluyendo Linux, BSD, Solaris, IRIX, y AIX así como de otras
 plataformas UNIX. Si bien la transición a sh y a la compatibilidad
 general UNIX ha sido un camino lleno de baches, también ha sido una
-tremenda experiencia de aprendizaje.  La creación de un único guión
+tremenda experiencia de aprendizaje. La creación de un único guión
 que funcione en todas estas plataformas ha sido muy difícil,
 principalmanete por mi, ¡sencillamente no tengo acceso a la mayoría de
 estos sistemas operativos!. Afortunadamente, lo hicieron los usuarios
@@ -320,9 +321,9 @@
 integraba expresiones y operadores que estuvieran plenamente
 soportados bajos todas las implementaciones de sh, incluyendo todas
 las consolas sh populares libres y las comerciales UNIX, zsh (en modo
-compatible sh), y las versiones 1 y 2 de bash.  Estos son algunas de
-las correciones de compatilibilidad de consola enviadas por los
-usuarios que fueron aplicadas al código funete de keychain:
+compatible sh), y las versiones 1 y 2 de bash. Estos son algunas de
+las correcciones de compatibilidad de consola enviadas por los
+usuarios que fueron aplicadas al código fuente de keychain:
 </p>
 
 <p>
@@ -338,8 +339,8 @@
 </pre>
 
 <p>
-A continuaciòn, todas las referencias al código fuente fueron
-cambiadas por un .  para asegurar la compatibilidad con la purista
+A continuación, todas las referencias al código fuente fueron
+cambiadas por un . para asegurar la compatibilidad con la purista
 /bin/sh de NetBSD, que no es compatible con el comando source:
 </p>
 
@@ -366,11 +367,11 @@
 <p>
 Sobre la base de usar la sintaxis interna de la consola en lugar de un
 binario externo, un fork() es evitado y el guión se convierte en algo
-más eficiente.  > foo debería trabajar con cualquier consola
-compatible sh; sin embargo, no parece estar soportado por ash. Esto no
-debería ser un problema para la mayoría de la gente, ya que ash es una
-consola para un disco de recuperación en lugar de algo que la gente
-use en el día a día básico.
+más eficiente. > foo debería trabajar con cualquier consola compatible
+sh; sin embargo, no parece estar soportado por ash. Esto no debería
+ser un problema para la mayoría de la gente, ya que ash es una consola
+para un disco de recuperación en lugar de algo que la gente use en el
+día a día básico.
 </p>
 </body>
 </section>
@@ -381,7 +382,7 @@
 
 <p>
 Obtener un guión que trabaje en múltiples sistemas operativos UNIX
-requiere algo más que ceñirse a la sintaxix pura de sh. Recuerde que,
+requiere algo más que ceñirse a la sintaxis pura de sh. Recuerde que,
 la mayoría de los guiones también hacen llamadas a comandos externos,
 tales como grep, awk, ps, y otros, y estos comandos deben ser llamados
 de una manera compatible en la medida de lo posible. Por ejemplo,
@@ -422,7 +423,7 @@
 <p>
 Probablemente, la más significativa revisión de compatibilidad ha
 implicado cambios en como keychain detecta los actuales procesos
-ssh-agent en ejecución.  Anteriormente yo estaba usando el comando
+ssh-agent en ejecución. Anteriormente yo estaba usando el comando
 pidof para hacerlo, pero he tenido que eliminarlo desde que varios
 sistemas no tienen un pidof. Realmente, pidof no es la mejor solución
 de todos modos, ya que lista todos los procesos ssh-agent ejecutándose
@@ -432,7 +433,7 @@
 </p>
 
 <p>
-Así que, en lugar de depender de pidof, pasamos sobre las tuberias de
+Así que, en lugar de depender de pidof, pasamos sobre las tuberías de
 la salida ps a grep y awk con el fin de extraer el proceso ids
 necesario. Esto es un arreglo enviado por un usuario:
 </p>
@@ -534,10 +535,10 @@
 <body>
 
 <p>
-Con este artículo concluye mi covertura de OpenSSH. Afortunadamente,
+Con este artículo concluye mi cobertura de OpenSSH. Afortunadamente,
 ha aprendido lo suficiente para empezar a utilizar OpenSSH para
 asegurar sus sistemas. El próximo mes continuaré con la serie de
-articulos con la "Guía avanzada de implementación de ficheros"
+artículos con la "Guía avanzada de implementación de ficheros"
 </p>
 </body>
 </section>