| 1 |
chiguire 08/10/11 21:58:21 |
| 2 |
|
| 3 |
Added: openssh-key-management-p3.xml |
| 4 |
Log: |
| 5 |
new spanish translation (javier vecino) |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/doc/es/articles/openssh-key-management-p3.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p3.xml?rev=1.1&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/es/articles/openssh-key-management-p3.xml?rev=1.1&content-type=text/plain |
| 12 |
|
| 13 |
Index: openssh-key-management-p3.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version = '1.0' encoding = 'UTF-8'?> |
| 16 |
<!-- $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 $ --> |
| 17 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 18 |
|
| 19 |
<guide link="/doc/es/articles/openssh-key-management-p3.xml" disclaimer="articles" lang="es"> |
| 20 |
<title>Gestión de claves para OpenSSH, Parte 3</title> |
| 21 |
<author title="Autor"> |
| 22 |
<mail link="drobbins@g.o">Daniel Robbins</mail> |
| 23 |
</author> |
| 24 |
<author title="Traductor"> |
| 25 |
<mail link="coghan@×××××××××××.cc">Javier Vecino</mail> |
| 26 |
</author> |
| 27 |
|
| 28 |
<abstract> |
| 29 |
En este tercer artículo de la serie, Daniel Robbins muesta como |
| 30 |
mejorar las conexiones del agente OpenSSH. Así como las recientes |
| 31 |
mejoras en el guión de consola keychain. |
| 32 |
</abstract> |
| 33 |
|
| 34 |
<!-- La versión original de este artículo fue publicada por IBM |
| 35 |
developerWorks y es propiedad de Westtech Information |
| 36 |
Services. Este documento es una versión actualizada del artículo |
| 37 |
original y contiene mejoras introducidas por el Equipo de |
| 38 |
Documentación de Gentoo. --> |
| 39 |
|
| 40 |
<version>1.2</version> |
| 41 |
<date>2005-10-21</date> |
| 42 |
|
| 43 |
<chapter> |
| 44 |
<title>Agente intermedio y mejoras de keychain</title> |
| 45 |
<section> |
| 46 |
<body> |
| 47 |
|
| 48 |
<p> |
| 49 |
Muchos de nosotros usamos las excelencias de OpenSSH como sustituto |
| 50 |
cifrado y seguro de los venerables comandos telnet y rsh. Una de las |
| 51 |
características que más intrigan de OpenSSH es la habilidad para |
| 52 |
validar usuarios usando los protocolos RSA y DSA, que se basan en un |
| 53 |
par de claves numéricas complementarias. Uno de los principales |
| 54 |
atractivos de la validación RSA y DSA es la promesa de ser capaz de |
| 55 |
establecer conexiones a sistemas remotos sin suministrar una |
| 56 |
contraseña. Para más antecedentes, vea las entregas anteriores de esta |
| 57 |
serie sobre gestión de claves para OpenSSH, que cubren <uri |
| 58 |
link="/doc/es/articles/openssh-key-management-p1.xml">validación |
| 59 |
RSA/DSA</uri> (Parte 1) y ssh-agent y <uri |
| 60 |
link="/doc/es/articles/openssh-key-management-p2.xml" >keychain</uri> |
| 61 |
(Parte 2), respectivamente. |
| 62 |
</p> |
| 63 |
|
| 64 |
<p> |
| 65 |
Desde la Parte 2 publicada en developWorks en Septiembre de 2001, y |
| 66 |
más tarde referenciados en Slashdot y Freshmeat (vease <uri |
| 67 |
link="#recursos">Recursos</uri> más adelante en este artículo los |
| 68 |
enlaces a estos sitios), muchas personas han empezado a usar keychain, |
| 69 |
y le han realizado algunos cambios, he recibido sobre unos 20 parches |
| 70 |
de gran calidad de desarrolladores de todo el mundo. He incorporado |
| 71 |
muchos de estos parches al código de keychain, que está ahora en la |
| 72 |
versión 1.8 (vea <uri link="#recursos">Recursos</uri>). Envío mis más |
| 73 |
sincero agradecimiento a todos aquellos que enviaron parches, informes |
| 74 |
de errores, y notas de agradecimiento. |
| 75 |
</p> |
| 76 |
</body> |
| 77 |
</section> |
| 78 |
|
| 79 |
<section> |
| 80 |
<title>Ajustando la seguridad de ssh</title> |
| 81 |
<body> |
| 82 |
|
| 83 |
<p> |
| 84 |
En mi <uri |
| 85 |
link="/doc/es/articles/openssh-key-management-p2.xml">último |
| 86 |
artículo</uri>, he pasado algún tiempo comentando los beneficios de |
| 87 |
seguridad y las ventajas del funcionamiento de ssh-agent. Pocos días |
| 88 |
después de que el segundo artículo apareciera en developerWorks, |
| 89 |
recibí un e-mail de Charles Karney de Sharnof Corporation, que |
| 90 |
amablemente me informó de las nuevas habilidades del nuevo agente |
| 91 |
intermedio de validación de OpenSSH, le echaremos un vistazo en |
| 92 |
breve. Además, Charles hizo incapié que la ejecución de ssh-agent en |
| 93 |
máquinas poco fiables es muy peligroso: si alguien logra acceso como |
| 94 |
root en el sistema, entonces sus claves descifradas puedes ser |
| 95 |
extraidas desde ssh-agent. Aunque la extracción de las claves sería |
| 96 |
algo difícil, está dentro de las habilidades de los crackers |
| 97 |
profesionales. Y ante mero hecho de que el robo de la clave privada |
| 98 |
sea medianamente posible deberemos tomar medidas en primer lugar para |
| 99 |
evitar que suceda. |
| 100 |
</p> |
| 101 |
|
| 102 |
<p> |
| 103 |
Para formular una estrategia para proteger nuestras claves privadas, |
| 104 |
debemos primero poner las máquinas a las que accedemos dentro de una |
| 105 |
de dos categorías. Si un host particular está bien asegurado o |
| 106 |
aislado -- siendo poco probable el acceso con éxito del root por medio |
| 107 |
de una vulnerabilidad -- entonces la máquina debe ser considerada un |
| 108 |
host de confianza. Sin embargo, si una máquina es usada por muchas |
| 109 |
personas o si tiene alguna duda acerca de la seguridad del sistema, |
| 110 |
entonces la máquina debería ser considerada como un host no |
| 111 |
confiable. De esta manera, incluso si la seguridad del sistema se ve |
| 112 |
comprometida, en primer lugar no habrá un ssh-agent a mano del intruso |
| 113 |
para extraer las claves. |
| 114 |
</p> |
| 115 |
|
| 116 |
<p> |
| 117 |
Sin embargo, esto crea un problema, si no se puede ejecutar ssh-agent |
| 118 |
en hosts no confiables, entonces ¿como podemos establecer conexiónes |
| 119 |
ssh, sin contraseñas y seguras en estos sistemas? La respuesta es usar |
| 120 |
solamente ssh-agent y keychain en hosts confiables, y usar la nueva |
| 121 |
capacidad de OpenSSH de validación intermedia para extender la |
| 122 |
validación sin contraseña en los hosts inseguros. En pocas palabras, |
| 123 |
el trabajo de la validación intermedia es permitir a las sesiones ssh |
| 124 |
remotas contactar con un ssh-agent que esté ejecutándose en un sistema |
| 125 |
confiable. |
| 126 |
</p> |
| 127 |
</body> |
| 128 |
</section> |
| 129 |
|
| 130 |
<section> |
| 131 |
<title>Agente de vaiidación intermedia</title> |
| 132 |
<body> |
| 133 |
|
| 134 |
<p> |
| 135 |
Para tener una idea de cómo funciona la validación intermedia, primero |
| 136 |
deje que veamos una hipotética situación donde el usuario drobbins |
| 137 |
tiene un ordenador portátil llamado lappy, un servidor de confianza |
| 138 |
llamado trustbox, y otros dos sistemas inseguros a los que debe tener |
| 139 |
acceso, llamados notrust1 y notrust2, respectivamente. Actualmente, |
| 140 |
utiliza ssh-agent junto con keychain en las cuatro máquinas, de la |
| 141 |
siguiente manera: |
| 142 |
</p> |
| 143 |
|
| 144 |
<figure link="/images/docs/l-ssh-3.jpg" caption="ssh-agent ejecutandose en |
| 145 |
máquinas confiables y no confiables"/> |
| 146 |
|
| 147 |
<p> |
| 148 |
El problema con este enfoque es que si alguien consigue acceso de root |
| 149 |
en notrust1 o notrust2, entonces, por supuesto, es posible que estas |
| 150 |
personas extraigan las claves desde el ahora vulnerable proceso |
| 151 |
ssh-agent. Para solucionar este problema, drobbins para la ejecución |
| 152 |
de ssh-agent y keychain en los inseguros hosts notrust1 y notrust2. De |
| 153 |
hecho, es incluso más cuidadoso, drobbins decide usar solamente |
| 154 |
ssh-agent y keychain en lappy. Esto limita la exposición de sus claves |
| 155 |
privadas descifradas, protegiéndolas contra el robo. |
| 156 |
</p> |
| 157 |
|
| 158 |
<figure link="/images/docs/l-ssh-4.jpg" caption="ssh-agent ejecutándose |
| 159 |
solamente en lappy; una configuración muy segura"/> |
| 160 |
|
| 161 |
<p> |
| 162 |
Por supuesto, el problema con este enfoque es que drobbins solamente |
| 163 |
puede establecer conexiones sin contraseña desde lappy. Veamos como |
| 164 |
habilitar la validacion intermedia y solucionar este problema. |
| 165 |
</p> |
| 166 |
|
| 167 |
<p> |
| 168 |
Suponiendo que todas las máquinas están ejecutando la versión más |
| 169 |
reciente de OpenSSH, podemos solucionar este problema mediante el uso |
| 170 |
de la validación intermedia. la validación intermedia permite a los |
| 171 |
procesos ssh remotos contactar con el ssh-agent que esté en ejecución |
| 172 |
en su máquina local segura -- en lugar de requerir que una versión de |
| 173 |
ssh-agent sea ejecutada en la misma máquina desde la que salga por |
| 174 |
ssh. Esto por lo general le permite ejecutar ssh-agent (y keychain) en |
| 175 |
una sola máquina, y significa que todas las conexiones ssh que |
| 176 |
procedan (ya sea directa o indirectamente) desde esta máquina van a |
| 177 |
utilizar su ssh-agent local. |
| 178 |
</p> |
| 179 |
|
| 180 |
<p> |
| 181 |
Para habilitar la validación intermedia, añadimos la siguiente línea |
| 182 |
en <path>/etc/ssh/ssh_config</path> de lappy y trustbox. Tenga en |
| 183 |
cuenta que este es el archivo de configuración de ssh |
| 184 |
(<path>ssh_config</path>), no del servicio sshd |
| 185 |
(<path>sshd_config</path>): |
| 186 |
</p> |
| 187 |
|
| 188 |
<pre caption="Añada esta línea a su /etc/ssh/ssh_config"> |
| 189 |
ForwardAgent Yes |
| 190 |
</pre> |
| 191 |
|
| 192 |
<p> |
| 193 |
Ahora, para sacar ventaja de la validación intermedia, drobbins se |
| 194 |
puede conectar desde lappy a trustbox, y a continuación desde trustbox |
| 195 |
hacia notrust1 sin suministrar contraseña desde ninguna |
| 196 |
conexión. Ambos procesos ssh "llaman" a ssh-agent ejecutado en lappy: |
| 197 |
</p> |
| 198 |
|
| 199 |
<pre caption="Aprovechando lappy"> |
| 200 |
$ <i>ssh drobbins@trustbox</i> |
| 201 |
Last login: Wed Sep 26 13:42:08 2001 from lappy |
| 202 |
|
| 203 |
Welcome to trustbox! |
| 204 |
$ <i>ssh drobbins@notrust1</i> |
| 205 |
Last login: Tue Sep 25 12:03:40 2001 from trustbox |
| 206 |
|
| 207 |
Welcome to notrust1! |
| 208 |
$ |
| 209 |
</pre> |
| 210 |
|
| 211 |
<p> |
| 212 |
Si intenta una configuración similar y se da cuenta que la transmisión |
| 213 |
no funciona, pruebe utilizando <c>ssh -A</c> en lugar del anterior ssh |
| 214 |
a secas para habilitar explícitamente la validación intermedia. Aquí |
| 215 |
hay un driagrama sobre lo que sucede detrás del escenario cuando |
| 216 |
accedemos a trustbox y notrust1 usando la validación intermedia: |
| 217 |
</p> |
| 218 |
|
| 219 |
<figure link="/images/docs/l-ssh-5.jpg" caption="Agente intemedio en acción"/> |
| 220 |
|
| 221 |
<p> |
| 222 |
Como puede ver, cuando ssh conecta a trustbox, mantuiene una conexión |
| 223 |
con el ssh-agent ejecutado en lappy. Cuando una conexión ssh se |
| 224 |
realiza desde trustbox hacia notrust1, este nuevo proceso ssh mantenie |
| 225 |
la conexión validada por el anterior ssh, extendiendo la cadena de |
| 226 |
manera efectiva. Si esta cadena de validacion puede ser extendida más |
| 227 |
allá de notrust1 a otros hosts depende de como |
| 228 |
<path>/etc/ssh/ssh_config</path> en notrust1 esté configurado. Mientas |
| 229 |
el agente intermedio este habilitado, todas las partes de la cadena |
| 230 |
serán capaces de validarse usando el ssh-agent ejecutado en el seguro |
| 231 |
lappy, |
| 232 |
</p> |
| 233 |
</body> |
| 234 |
</section> |
| 235 |
|
| 236 |
<section> |
| 237 |
<title>Ventajas del agente de conexión intermedia</title> |
| 238 |
<body> |
| 239 |
|
| 240 |
<p> |
| 241 |
La validación intermedia ofrece una serie de ventajas de seguridad no |
| 242 |
mostradas. Para convencerme de la importancia del agente de conexión |
| 243 |
intermedia, Charles Karney ha compartido conmigo estas tres conceptos |
| 244 |
de seguridad: |
| 245 |
</p> |
| 246 |
|
| 247 |
<ol> |
| 248 |
<li> |
| 249 |
La clave privada se guarda sólo en la máquina de confianza. Esto |
| 250 |
evita que usuarios malintencionados recolecten su clave encriptada |
| 251 |
desde el disco y traten de romper la encriptación. |
| 252 |
</li> |
| 253 |
<li> |
| 254 |
ssh-agent sólo se ejecuta en la máquina de confianza. Esto evita |
| 255 |
que un intruso reealice un volcado de memoria de un proceso |
| 256 |
ssh-agent remoto y entonces extraiga su clave descifrada desde el |
| 257 |
volcado. |
| 258 |
</li> |
| 259 |
<li> |
| 260 |
Dado que sólo tendrá que teclear su contraseña desde su máquina de |
| 261 |
confianza, evita cualquier furtivo logeador de pulsaciones del |
| 262 |
teclado que pueda capturar su contraseña cuando es introducida. |
| 263 |
</li> |
| 264 |
</ol> |
| 265 |
|
| 266 |
<p> |
| 267 |
El incoveniente de confiar en el agente de validación intermedio es |
| 268 |
que no resuelve el problema que permita a los cron jobs aprovechar la |
| 269 |
validación RSA/DSA. Una solución a este problema es crear todos los |
| 270 |
cron jobs que necesiten la validación RSA/DSA para que sean ejecutados |
| 271 |
en una máquina de confianza de su LAN. Si es necesario, estos cron |
| 272 |
jobs pueden utilizar ssh para conectarse a sistemas remotos para |
| 273 |
automatizar copias de seguridad, sincronizar ficheros, y así |
| 274 |
sucesivamente. |
| 275 |
</p> |
| 276 |
|
| 277 |
<p> |
| 278 |
Ahora que hemos visto la conexión del agente de validación intermedia, |
| 279 |
es el turno de las mejoras recientemente introducidas en el propio |
| 280 |
guión keychain. |
| 281 |
</p> |
| 282 |
</body> |
| 283 |
</section> |
| 284 |
|
| 285 |
<section> |
| 286 |
<title>Mejoras en el funcionamiento de keychain</title> |
| 287 |
<body> |
| 288 |
|
| 289 |
<p> |
| 290 |
Gracias a los parches enviados por los usuarios, muchas mejoras |
| 291 |
importantes se han introducido en el código fuente de keychain. Varios |
| 292 |
de los parches enviados por usuarios fueron en relación a la |
| 293 |
funcionalidad. Por ejemplo, recordará que keychain ha creado un |
| 294 |
fichero <path>~/.ssh-agent</path>; el nombre de este fichero ha |
| 295 |
cambiado a <path>~/.ssh-agent-[hostname]</path> de modo que keychain |
| 296 |
puede trabajar con los directorios home montados por NFS para que se |
| 297 |
puedan acceder desde varios hosts físicos. Además del fichero |
| 298 |
<path>~/.ssh-agent-[hostname]</path>, ahora hay un fichero |
| 299 |
<path>~/.ssh-agent-csh-[hostname]</path> que puede ser leído por |
| 300 |
consolas csh y compatibles. Po último, una nueva opción |
| 301 |
<c>--nocolor</c> ha sido añadida a fin de que la característica |
| 302 |
coloración pueda ser desactivada en caso de que se utilice un terminal |
| 303 |
no compatilble vt100. |
| 304 |
</p> |
| 305 |
</body> |
| 306 |
</section> |
| 307 |
|
| 308 |
<section> |
| 309 |
<title>Correcciones de compatibilidas de la consola</title> |
| 310 |
<body> |
| 311 |
|
| 312 |
<p> |
| 313 |
Si bien la funcionalidad de las mejoras han sido importantes, la gran |
| 314 |
mayoría de las correciones se han ocupado de los problemas de |
| 315 |
compatibilidad de la consola. Verá, mientras keychain 1.0 requiere de |
| 316 |
bash, versiones posteriores fueron cambiadas para trabajar con |
| 317 |
cualquier consola compatible con sh. Este cambio permite a keychain |
| 318 |
trabajar "de forma poco común" en casi cualquier sistema UNIX, |
| 319 |
incluyendo Linux, BSD, Solaris, IRIX, y AIX así como de otras |
| 320 |
plataformas UNIX. Si bien la transición a sh y a la compatibilidad |
| 321 |
general UNIX ha sido un camino lleno de baches, también ha sido una |
| 322 |
tremenda experiencia de aprendizaje. La creación de un único guión |
| 323 |
que funcione en todas estas plataformas ha sido muy difícil, |
| 324 |
principalmanete por mi, ¡sencillamente no tengo acceso a la mayoría de |
| 325 |
estos sistemas operativos!. Afortunadamente, lo hicieron los usuarios |
| 326 |
de keychain de todo mundo, y muchos han proporcionado gran ayuda en la |
| 327 |
identificación de problemas de compatibilidad y presentando parches |
| 328 |
para solucionarlos. |
| 329 |
</p> |
| 330 |
|
| 331 |
<p> |
| 332 |
Realmente hay dos tipos de problemas de compatibilidad que tenían que |
| 333 |
ser solucionados. Primeramente, necesitaba asegurar que keychain, |
| 334 |
integraba expresiones y operadores que estuvieran plenamente |
| 335 |
soportados bajos todas las implementaciones de sh, incluyendo todas |
| 336 |
las consolas sh populares libres y las comerciales UNIX, zsh (en modo |
| 337 |
compatible sh), y las versiones 1 y 2 de bash. Estos son algunas de |
| 338 |
las correciones de compatilibilidad de consola enviadas por los |
| 339 |
usuarios que fueron aplicadas al código funete de keychain: |
| 340 |
</p> |
| 341 |
|
| 342 |
<p> |
| 343 |
Dado que las antiguas consolas sh no soportan el convenio ~ para |
| 344 |
referirse al directorio home del usuario, las líneas que usaban ~ |
| 345 |
fueron cambiadas para usar <c>$HOME</c> en su lugar: |
| 346 |
</p> |
| 347 |
|
| 348 |
<pre caption="cambiando a $HOME"> |
| 349 |
hostname=`uname -n` |
| 350 |
pidf=${HOME}/.ssh-agent-${hostname} |
| 351 |
cshpidf=${HOME}/.ssh-agent-csh-${hostname} |
| 352 |
</pre> |
| 353 |
|
| 354 |
<p> |
| 355 |
A continuaciòn, todas las referencias al código fuente fueron |
| 356 |
cambiadas por un . para asegurar la compatibilidad con la purista |
| 357 |
/bin/sh de NetBSD, que no es compatible con el comando source: |
| 358 |
</p> |
| 359 |
|
| 360 |
<pre caption="Alegrando NetBSD"> |
| 361 |
if [ -f $pidf ] |
| 362 |
then |
| 363 |
. $pidf |
| 364 |
else |
| 365 |
SSH_AGENT_PID="NULL" |
| 366 |
fi |
| 367 |
</pre> |
| 368 |
|
| 369 |
<p> |
| 370 |
A lo largo del camino, también he ido aplicando algunos parches |
| 371 |
relacionados con el rendimiento. Un experimentado programador de |
| 372 |
guiones de consola me informó que en lugar de "crear" un fichero |
| 373 |
tecleando touch foo, tu puedes hacer esto en su lugar: |
| 374 |
</p> |
| 375 |
|
| 376 |
<pre caption="Creando ficheros"> |
| 377 |
> <i>foo</i> |
| 378 |
</pre> |
| 379 |
|
| 380 |
<p> |
| 381 |
Sobre la base de usar la sintaxis interna de la consola en lugar de un |
| 382 |
binario externo, un fork() es evitado y el guión se convierte en algo |
| 383 |
más eficiente. > foo debería trabajar con cualquier consola |
| 384 |
compatible sh; sin embargo, no parece estar soportado por ash. Esto no |
| 385 |
debería ser un problema para la mayoría de la gente, ya que ash es una |
| 386 |
consola para un disco de recuperación en lugar de algo que la gente |
| 387 |
use en el día a día básico. |
| 388 |
</p> |
| 389 |
</body> |
| 390 |
</section> |
| 391 |
|
| 392 |
<section> |
| 393 |
<title>Preguntando a la plataforma por los ejecutables</title> |
| 394 |
<body> |
| 395 |
|
| 396 |
<p> |
| 397 |
Obtener un guión que trabaje en múltiples sistemas operativos UNIX |
| 398 |
requiere algo más que ceñirse a la sintaxix pura de sh. Recuerde que, |
| 399 |
la mayoría de los guiones también hacen llamadas a comandos externos, |
| 400 |
tales como grep, awk, ps, y otros, y estos comandos deben ser llamados |
| 401 |
de una manera compatible en la medida de lo posible. Por ejemplo, |
| 402 |
mientras el comando echo incluido en la mayoría de los UNIX reconoce |
| 403 |
la opción <c>-e</c>, Solaris no -- simplemente imprime <c>-e</c> hacia |
| 404 |
stdout cuando se utiliza. Por lo tanto ,con el fin de tratar con |
| 405 |
Solaris, keychain ahora autodetecta si <c>echo -e</c> funciona: |
| 406 |
</p> |
| 407 |
|
| 408 |
<pre caption="Analizando la salida de Solaris"> |
| 409 |
if [ -z "`echo -e`" ] |
| 410 |
then |
| 411 |
E="-e" |
| 412 |
fi |
| 413 |
</pre> |
| 414 |
|
| 415 |
<p> |
| 416 |
Arriba, E se establece en <c>-e</c> si -e es soportada, entonces, echo |
| 417 |
se puede llamar de la siguiente manera: |
| 418 |
</p> |
| 419 |
|
| 420 |
<pre caption="Mejorar echo"> |
| 421 |
echo $E Usage: ${CYAN}${0}${OFF} [ ${GREEN}options${OFF} ] ${CYAN}sshkey${OFF} ... |
| 422 |
</pre> |
| 423 |
|
| 424 |
<p> |
| 425 |
Mediante el uso de <c>echo $E</c> en lugar de <c>echo -e</c>, la |
| 426 |
opción -e puede ser dinámicamente activada o desactivada según sea |
| 427 |
necesario. |
| 428 |
</p> |
| 429 |
</body> |
| 430 |
</section> |
| 431 |
|
| 432 |
<section> |
| 433 |
<title>pidof, ps</title> |
| 434 |
<body> |
| 435 |
|
| 436 |
<p> |
| 437 |
Probablemente, la más significativa revisión de compatibilidad ha |
| 438 |
implicado cambios en como keychain detecta los actuales procesos |
| 439 |
ssh-agent en ejecución. Anteriormente yo estaba usando el comando |
| 440 |
pidof para hacerlo, pero he tenido que eliminarlo desde que varios |
| 441 |
sistemas no tienen un pidof. Realmente, pidof no es la mejor solución |
| 442 |
de todos modos, ya que lista todos los procesos ssh-agent ejecutándose |
| 443 |
en el sistema, independientemente del usuario, cuando realmente |
| 444 |
estamos interesados en todos los procesos ssh-agent propiedad del |
| 445 |
actual UID. |
| 446 |
</p> |
| 447 |
|
| 448 |
<p> |
| 449 |
Así que, en lugar de depender de pidof, pasamos sobre las tuberias de |
| 450 |
la salida ps a grep y awk con el fin de extraer el proceso ids |
| 451 |
necesario. Esto es un arreglo enviado por un usuario: |
| 452 |
</p> |
| 453 |
|
| 454 |
<pre caption="Tuberías mejor que pidof"> |
| 455 |
mypids=`ps uxw | grep ssh-agent | grep -v grep | awk '{print $2}'` |
| 456 |
</pre> |
| 457 |
|
| 458 |
<p> |
| 459 |
La tubería establecerá la variable mypids a los valores de todos los |
| 460 |
procesos ssh-agent propiedad del actual usuario. El comando grep -v |
| 461 |
grep es parte de la tubería para garantizar que el procesos grep |
| 462 |
ssh-agent no se convierta en parte de nuestra lista de PID. |
| 463 |
</p> |
| 464 |
|
| 465 |
<p> |
| 466 |
Si bien este enfoque es un buen concepto, usando ps se abrió toda una |
| 467 |
nueva lata de gusanos ya que las opciones de ps no están |
| 468 |
estandarizadas a través de las diferentes BSD y System V derivados de |
| 469 |
UNIX. He aquí un ejemplo: mientras ps uxw trabaja bajo Linux, no |
| 470 |
funciona bajo IRIX. Y mientras <c>ps -u username -f</c> trabaja bajo |
| 471 |
Linux, IRIX y Solaris, no funciona bajo BSD, que sólo entiende el |
| 472 |
estilo BSD de opciones ps. Para evitar este problema, keychain |
| 473 |
autodetecta si el ps del sistema actual trabaja con la sintaxis BSD o |
| 474 |
System V antes de ejecutar la tubería ps: |
| 475 |
</p> |
| 476 |
|
| 477 |
<pre caption="Detectando BSD vs. System V"> |
| 478 |
psopts="FAIL" |
| 479 |
ps uxw >/dev/null 2>&1 |
| 480 |
if [ $? -eq 0 ] |
| 481 |
then |
| 482 |
psopts="uxw" |
| 483 |
else |
| 484 |
ps -u `whoami` -f >/dev/null 2>&1 |
| 485 |
if [ $? -eq 0 ] |
| 486 |
then |
| 487 |
psopts="-u `whoami` -f" |
| 488 |
fi |
| 489 |
fi |
| 490 |
if [ "$psopts" = "FAIL" ] |
| 491 |
then |
| 492 |
echo $0: unable to use \"ps\" to scan for ssh-agent processes. |
| 493 |
Report KeyChain version and echo system configuration to drobbins@g.o. |
| 494 |
exit 1 |
| 495 |
fi |
| 496 |
|
| 497 |
mypids=`ps $psopts 2>/dev/null | grep "[s]sh-agent" | awk '{print $2}'` > /dev/null 2>&1 |
| 498 |
</pre> |
| 499 |
|
| 500 |
<p> |
| 501 |
Para asegurar que el comando ps trabaja con ambos System V y estilo |
| 502 |
BSD, el guión hace un "simulacro" de ps uxw, mostrando alguna salida, |
| 503 |
si el código de error de este comando es igual a cero, sabemos que ps |
| 504 |
uxw trabaja y ajustamos el valor psopts adecuadamente. Sin embargo, si |
| 505 |
ps uxw devuelve un código de error distinto de cero (lo que indica que |
| 506 |
tenemos que usar las opciones del estilo BSD), haremos una prueba de |
| 507 |
<c>ps -u `whoami` -f</c>, nuevamente mostrando toda la salida. En este |
| 508 |
punto, esperamos haber encontrado una variante BSD o System V de ps |
| 509 |
que podamos usar. Si no, mostramos un error y salimos. Pero es muy |
| 510 |
probable que uno de los dos comandos ps trabaje, en cuyo caso se |
| 511 |
ejecutará la línea final del anterior fragmento de código, nuestra |
| 512 |
tubería ps. Mediante el uso de la variable $psopts expandida |
| 513 |
inmediatamente después de ps, estamos en condiciones de pasar las |
| 514 |
opciones correctas al comando ps. |
| 515 |
</p> |
| 516 |
|
| 517 |
<p> |
| 518 |
La tubería ps también contiene una verdadera joya grep, que me fue |
| 519 |
amablemente enviada por Hans Peter Verne. Observe que <c>grep -v |
| 520 |
grep</c> ya no es parte de la tubería; en su lugar, se ha eliminado y |
| 521 |
<c>grep "ssh-agent"</c> ha sido cambiado por grep |
| 522 |
<c>"[s]sh-agent"</c>. Este único comando grep termina haciendo lo |
| 523 |
mismo que <c>grep ssh-agent | grep -v grep</c>; ¿se puede figurar por |
| 524 |
qué?. |
| 525 |
</p> |
| 526 |
|
| 527 |
<pre caption="Ligero truco con grep"> |
| 528 |
mypids=`ps $psopts 2>/dev/null | grep "[s]sh-agent" | awk '{print $2}'` > /dev/null 2>&1 |
| 529 |
</pre> |
| 530 |
|
| 531 |
<p> |
| 532 |
¿Perplejo? Si ha decidido que un <c>grep "ssh-agent"</c> y <c>grep |
| 533 |
"[s]sh-agent"</c> deberían coincidir con las mismas líneas de texto, |
| 534 |
está en lo cierto. ¿Entonces porqué hacer que generen resultados |
| 535 |
diferentes cuando la salida de ps es entubada hacia ellos? He aquí |
| 536 |
como funciona: cuando se utiliza grep "[s]sh-agent", cambia la forma |
| 537 |
en que el comando grep aparece en el listado de procesos ps. De esta |
| 538 |
manera, prevenimos que grep coincida consigo mismo, ya que la cadena |
| 539 |
[s]sh-agent no coincide con la expresión regular [s]sh-agent. ¿No es |
| 540 |
brillante? Si todavía no lo pilla, juegue con grep un poco más y lo |
| 541 |
logrará pronto. |
| 542 |
</p> |
| 543 |
</body> |
| 544 |
</section> |
| 545 |
|
| 546 |
<section> |
| 547 |
<title>Conclusión</title> |
| 548 |
<body> |
| 549 |
|
| 550 |
<p> |
| 551 |
Con este artículo concluye mi covertura de OpenSSH. Afortunadamente, |
| 552 |
ha aprendido lo suficiente para empezar a utilizar OpenSSH para |
| 553 |
asegurar sus sistemas. El próximo mes continuaré con la serie de |
| 554 |
articulos con la "Guía avanzada de implementación de ficheros" |
| 555 |
</p> |
| 556 |
</body> |
| 557 |
</section> |
| 558 |
</chapter> |
| 559 |
|
| 560 |
<chapter id="recursos"> |
| 561 |
<title>Recursos</title> |
| 562 |
<section> |
| 563 |
<body> |
| 564 |
|
| 565 |
<ul> |
| 566 |
<li> |
| 567 |
Lea los otros dos artículos de Daniel de esta serie, <uri |
| 568 |
link="/doc/es/articles/openssh-key-management-p1.xml">Gestión de |
| 569 |
claves para OpenSSH, Parte 1</uri> y <uri |
| 570 |
link="/doc/es/articles/openssh-key-management-p2.xml">Gestión de |
| 571 |
claves para OpenSSH, Parte 2</uri> |
| 572 |
</li> |
| 573 |
<li> |
| 574 |
La versión más reciente de keychain está disponible en la página |
| 575 |
de<uri |
| 576 |
link="http://www.gentoo.org/proj/en/keychain/index.xml">Gentoo |
| 577 |
Linux Keychain</uri> |
| 578 |
</li> |
| 579 |
<li> |
| 580 |
Asegúrese de visitar el<uri link="http://www.openssh.com/">sitio |
| 581 |
de desarrollo de OpenSSH</uri>, y revise las<uri |
| 582 |
link="http://www.openssh.com/faq.html" >FAQ de OpenSSH</uri> |
| 583 |
</li> |
| 584 |
<li> |
| 585 |
<uri |
| 586 |
link="http://www.chiark.greenend.org.uk/~sgtatham/putty/">PuTTY</uri> |
| 587 |
es un excelente cliente ssh para máquinas Windows |
| 588 |
</li> |
| 589 |
<li> |
| 590 |
El libro "SSH, The Secure Shell: The Definitive Guide" (O'Reilly |
| 591 |
& Associates, 2001) puede ayudarle. El <uri |
| 592 |
link="http://www.snailbook.com/" >sitio de los autores</uri> |
| 593 |
contiene información acerca del libro, FAQ, noticias, y |
| 594 |
actualizaciones. |
| 595 |
</li> |
| 596 |
</ul> |
| 597 |
</body> |
| 598 |
</section> |
| 599 |
</chapter> |
| 600 |
</guide> |
Archives