PNAMBIC significa "pay no attention to the man behind the curtain" (no preste atención al hombre atrás de la cortina) en alusión a que hay alguien que está "ayudando" para que las cosas funcionen (y escondido atrás de una cortina tratando de evitar que se note mucho...).
El término no viene de la informática, se acuño en el libro "El mago de Oz" para describir la verdadera naturaleza del (algo fraudulento) mago.
En su acepción fraudulenta ha sido algo usada en el ámbito de inteligencia artificial donde a propósito o por sesgo inadvertido algunos resultados "espectaculares" no siempre fueron conseguido solo por el software sino que tuvieron errr... ayuda externa.
Anécdotas al margen una red requiere de ciertas acciones automáticas, y en particular que los tuneles y ruteos entre LAN no tengan intervención humana; simplemente las redes no serían confiables si necesitaran de alguien para tener que tirar comandos excepto en circunstancias muy especiales.
Para establecer túneles como los descriptos en una entrada anterior establecidos en una conexión SSH brinda sencillez y seguridad. Pero al establecer el tunel la conexión SSH requiere la password, y nada menos que la password de root (la mas privilegiada de las passwords en un sistema Linux). Passwords que no todos se sienten cómodos en estar distribuyendo. Durante un breve tiempo experimental es inevitable tener que confiar a los experimentadores este tipo de privilegios (quien no se sienta cómodo con este tipo de confianza no debería ofrecerse a hacer experimentos en primer lugar, pero no todos conocen lo suficiente como para entender que no hay otra alternativa).
Pero tambien es justo remarcar que fuera de la experimentación no es razonable que para establecer un tunel uno de los "extremos" tenga que abrir totalmente su sistema confiando la password de root.
Insoluble? No en realidad, siempre que apelemos a la criptografía.
La password es solo para atestiguar que la persona que entra en el sistema es quien, en principio, dice ser. El problema es que teniendo la password de root puede entrar al margen del mero propósito de establecer el tunel y con máximo privilegio administrativo hacer lo que quiera en el sistema.
Sin embargo bastaría para todos los efectos prácticos que el sistema sepa que soy "yo" y que el administrador del sistema haya aceptado que para el solo propósito de establecer el tunel "yo" puedo hacerlo como si fuera root, pero no concediendome los privilegios de root para todo el resto de las funciones.
Esto se implementa mediante certificados criptográficos, de tal manera que la parte pública del certificado sea instalada en el server (el que recibe la conexión); el cliente (quien hace la conexión) conserva la parte privada de su certificado. La matemática atrás del proceso de certificados por clave pública/privada es matemáticamente áspero, pero conceptualmente es sencillo. Hay varios algoritmos pero el mas difundido es el denominado RSA (por sus autores Rivest, Shamir, Adleman) que se basa en el factoreo de números primos muy grandes. La fortaleza reside en la longitud de la clave y a todos los efectos prácticos no puede ser descifrado con recursos convencionales. Solo la persona con la clave privada puede aparear con la clave pública; todo el mundo puede saber esa clave pública pero es inutil sin la parte privada.
Los sistemas de encripción basados en clave pública/privada es una solución tecnológicamente reciente al dilema ancestral de como transportar en forma segura la password con la que un mensaje debe ser "liberado" o "des-encriptado", comprometer esa password implica comprometer el esquema de seguridad entero. La solución es sorprendentemente trivial, no hay que enviar una password que pueda ser comprometida. La solución matemática que lo permite es otra historia.
El proceso de generación de estos certificados es programáticamente sencillo y está descripto en "Buenos Aires Libre" sobre lo cual hay que hacer solo modificaciones menores.
Se utiliza el paquete ssh-keygen que es parte del paquete openssh-keygen, el que al invocarse requiere que se contesten algunas preguntas (lo indicado en rojo no es para ser tipeado sino instrucciones).
# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): (no tipear nada aqui, aceptar default)
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase): (no tipear nada aqui, aceptar default)
Enter same passphrase again: (enter)
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
84:1c:d8:24:d9:af:65:97:d7:f3:42:83:51:0a:1f:3c root@lu7hz.ampr.org
Como el mensaje lo indica al finalizar quedan en /root/.ssh dos archivos id_rsa (clave privada) y id_rsa.pub (clave pública). Es interesante ver en que consisten, basta hacer cat id_rsa o cat id_rsa.pub para verlo.
El archivo id_rsa tiene que ser guardado en el sistema cliente (el que origina la llamada) en el directorio /root/.ssh y no ser entregado a nadie, de este hecho depende la seguridad de todo el esquema. El archivo id_rsa.pub en cambio debe ser enviado al administrador del sistema que opera como servidor (el "otro extremo" del tunel).
El administrador tiene que "instalarlo" para que sea reconocido, los comandos para hacerlo son (asumiendo que la clave pública quede depositada en /tmp).
cat /tmp/id_rsa.pub >>/root/.ssh/authorized_keys2
chmod 600 /root/.ssh/authorized_keys2
Es importante el ">>" en el primer comando para no destruir certificados previamente instalados.
Si todo anda bien la siguiente vez que el usuario root del extremo cliente active un tunel con el server SSH entrará directamente sin necesidad de proveer una password, y sin comprometer la seguridad de ninguno de los sistemas.
Un ultimo factor que debe ser considerado. Una red HSMM está implementado por aficionados, usualmente poniendo mas buena voluntad y empuje que conocimientos. No ayuda que el tema de criptografía en general es denso, poco intuitivo y pobremente conocido aún en circulos profesionales. Como sea, la mención "encripción" y "radio" en la misma frase usualmente deriva en una negativa a utilizarla porque, efectivamente, reglamentariamente está prohibido transmitir información encriptada por radio. Pero hay que ser cuidadoso y no tomar decisiones sobre procesos que no se entienden; el canal SSH no se establece por radio, al menos no por radio de bandas de aficionado, sino por Internet. El tráfico de circular por la red "radial" lo hace en texto plano y cumple con la reglamentación, cuando se traslada de un extremo del tunel al otro es que está encriptado, pero vuelve a ser texto plano y reglamentariamente correcto una vez que sale de el. Los certificados por otra parte se intercambian por medios que no son radio (correo electrónico por ejemplo) y solo se intercambian dentro del canal SSH.
Con esta tecnología los tuneles pueden ser establecidos en forma automática, cuando los sistemas se levantan o recuperan de una falla y sin necesidad que el "ayudante detrás de la cortina" tenga que intervenir para nada.
No hay comentarios:
Publicar un comentario