ssh-keygen

SSH keygen.

Download PDF

SSH keygen.

Con SSH podremos conectarnos de manera segura a nuestras máquinas remotas y ejecutar o automatizar tareas con la certeza de que nadie podrá indagar qué estamos haciendo, privacidad absoluta.

En un post anterior vimos y aprendimos nuestros primeros pasos para trabajar por línea de comandos (shell) en una ventana terminal. Si no lo recordaís o quereís refrescar la memoria pues visitadlo y regresa acá para continuar nuestro aprendizaje (que yo también escribo esto para que no se me olvide -y ayudo a otros también-).


ssh-keygen
ssh-keygen

Pues el tema que nos trae hoy consta de dos publicaciones de la cual ésta es la primera. Ya sabemos cómo manejar la terminal por atajos de teclado para listar, copiar archivos, renombrarlos, etc. Todo esto lo hacíamos así, directamente sentados en nuestro ordenador, en contacto físico con nuestro equipo. ¿Pero que tal si nosotros necesitamos conectarnos a alguno de los ordenadores de nuestro trabajo? ¿O si estamos de viaje conectarnos a nuestra computadora en casa?

Apartando el tema que necesitamos conocer la dirección IP que nos asigna nuestro proveedor de internet para conectarnos (eso ya será tema para una nueva publicación) en el mundo Linux hay software antiquísimo diseñado especialmente para esto. En un  principio nos ocasionará temor el dejar nuestros equipos así, abiertos al mundo y con tanto “hacker” suelto por allí, que ni siquiera el mayor imperio conocido en la historia de la humanidad ha podido capturar a Edward Snowden o a Julian Assange, ¿qué quedará para nosotros? Al final de estas líneas os mostraremos al menos una herramienta para ayudar a protegernos de accesos no autorizados.

La buena noticia -y que tal vez los tranquilize un poco- es que estos dos señores (y muchos más) utilizan lo que nosotros aprenderemos aquí. Se dice rápido y fácil pero detrás de esto mucha gente se devanó los sesos pensando fórmulas matemáticas, estadística y algoritmos para garantizar nuestro acceso a ordenadores remotos. Sin más preámbulos pasemos a describir dicha tecnología.

SSH “Secure SHell”

En informática el acrónimo de 3 letras SSH (“Secure SHell”) describe la conexión segura entre dos computadores por medio de un canal seguro basado en un protocolo de red que nos permite manejar una línea de comandos como si estuviéramos de cuerpo presente frente al ordenador. La definición en inglés es cortísima, pero bueno cosas de ese idioma, todo es corto y rápido, “como para ayer pues”. Una cosa que yo admiro, eso sí, de esa gente es LA PRACTICIDAD. Estas conexiones nos permiten administrar múltiples equipos, pero el asunto va mucho más allá. Yo me esfuerzo todos los días para llegar a ser un Administrador de sistemas perezoso y ser así algún día UN BUEN ADMINISTRADOR DE SISTEMAS. Podemos crear archivos de procesos por lotes escritos en formato .sh (bin bash) y que nuestra máquina local ejecute cada cierto tiempo prefijado con CRON pero lo aplique a una máquina remota (la idea es poder introducir variables de búsqueda o parámetros a programas desde nuestro equipo local y aplicarlo en la máquina remota).

Para ello debemos nosotros mismos introducir la contraseña de la máquina remota y hasta allí llega nuestro entusiasmo para automatizar tareas. Pero para ello inventaron el ssh-keygen, un algoritmo que nos permitirá conectar automáticamente “sin contraseña” pero con una seguridad muy robusta y comprobada millones de veces diariamente.

Vuelvo y repito, detrás de todo esto hay mucha ciencia y esfuerzo, lo que les describo es una simplificación para aprender el concepto que luego pueden ampliarlo con los variados enlaces que incluyo y que utilicé para escribir esta entrada en mi blog.

Cinco pasos para crear “login sin contraseña”.

Tanto como “sin contraseña” no es el asunto, realmente tendremos que colocar una sola vez nuestra contraseña para poder acceder a nuestra página remota. Luego son cinco los pasos necesarios para crear nuestras conexiones “sin contraseñas” o como dicen en inglés “SSH Passwordless Login Using SSH Keygen in 5 Easy Steps“. Dichos pasos, panorama general, son los siguientes:

  1. En nuestra computadora local generaremos una llave digital.
  2. Luego crearemos un directorio en la máquina remota donde reposará dicha llave digital.
  3. Acto seguido copiaremos la llave en sí (local->remota).
  4. Asignaremos en la máquina remota permisos de lectura a dicha llave.
  5. Nos conectaremos como prueba de que la llave funciona.

Fue más fácil decirlo que hacerlo, como siempre. Ahora paso a describirlo con un ejemplo, en mi caso tengo una computadora real corriendo Ubuntu 14 de 64 bits (máquina local llamada “KEVIN” cuya dirección IP local es 192.168.1.47) corriendo un software llamado VirtualBox que me permite correr máquinas con diferentes sistemas operativos, para nuestras pruebas nos vienen como anillo al dedo pues ahorramos en hardware y en tiempo. La máquina virtual que utilizaré tiene corriendo Debian 7 “wheezy” la cual será la máquina remota, su nombre es “postgresql” y su dirección ip de área local es, para este ejemplo, 192.168.1.27 (una máquina virtual con motor de base de datos que utilizo para pruebas de programación).

Instalando SSH en la máquina remota (Debian).

Debido a la sencillez de este paso no se los había mencionado pero es que tampoco podemos obviarlo porque es crucial para aplicar los 5 pasos que nos fijamos como meta. Por seguridad (pienso yo) el SSH no viene instalado de manera prefijada en las distribuciones Linux. Pensemos esto como que si no existe una puerta nunca podremos entrar. Lo que vamos a hacer ni siquiera es abrir una puerta, lo que vamos a realizar es romper la pared y empotrar nuestra puerta.

Es así que PRIMERO debemos estar sentados en la que será la máquina remota (-si se pierden retrocedan un párrafo y se ubican-) y abrir una ventana terminal y ejecutar la siguiente sentencia:

apt-get install ssh

Debemos estar conectados como superusuario, en esta oportunidad utilicé el comando su introduje mi contraseña de usuario y ordené la instalación del software necesario para hacer la conexión (recordar que la máquina remota ejecuta Debian).

Instalando SSH.
Instalando SSH.

Como ya estaba instalado me reporta que no fue instalado ni modifcado nada y nos recuerda que hay 2 actualizaciones por realizar (de nuevo esta parte da material para otra entrada aparte en mi blog). Ya con esto establecido pordemos continuar ahora sí con los cinco pasos siguientes.

Bono adicional: instalando SSH en Ubuntu.

Pues eso, tengo una máquina virtual para probar Ubuntu de 64 bits con la versión 16.04 Xenial Xerus [Ubuntu da nombres rimbombantes a sus distros (abrid este enlace si queréis saber su significado en inglés), pero ¿quienes somos nosotros para criticarlos? Hagamos nuestra propia distro para ponerle un nombre que nos guste, ja ja ja 😉 ].

En dicha máquina virtual abrimos una ventana terminal con CTRL+T (recordad de nuevo que es Ubuntu) e introducimos el correspondiente comando:

apt-get install ssh (1)
apt-get install ssh (1)
apt-get install ssh (2)
apt-get install ssh (2)

En este ejemplo si que vemos cómo se instala completo, y notad la generación de certificados digitales mínimos necesarios para funcionar. También, en la figura 2, veréis como la última liínea se generan disparadores para ufw, el firewall que utiliza Ubuntu, al final ampliaremos esto. Luego de realizado esto podemos probar la conexión y revisar si conecta correctamente:

ssh jimmy@192.168.1.130
ssh jimmy@192.168.1.130

Paso N° 1: creación de llave digital.

Tal vez esta sea la sección más llamativa del asunto. Necesitamos crear una llave digital que consiste en un montón de caracteres organizados según un algoritmo que hace esta llave única. Incluso tiene opciones para hacerl más segura aún, pero les dejo eso como tarea y se entusiasmen tanto como yo. Dicho esto usaremos la opción “simple”, sentados en la máquina local abrimos una ventana de terminal y tecleamos lo siguiente:

ssh-keygen -t rsa
Generando llave SSH.
Generando llave SSH.

Luego presionamos la tecla intro (enter) cuatro veces, osea, empleamos los valores que trae por defecto el programa generador de llaves. Aquí debemos notar dónde guarda la llave que acabamos de generar: en nuestra carpeta personal dentro de un directorio oculto llamado ssh, en nuestro ejemplo es “/home/jimmy/.ssh/”. Sabiendo esto nos vamos al siguiente paso.

Paso N° 2: directorio remoto para guardar llave.

Para copiar nuestra nueva llave digital en nuestra máquina remota necesitaremos introducir los siguientes comandos desde la máquina local:

ssh jimmy@192.168.1.27 mkdir -p .ssh

Como ven aquí ya comenzamos a correr comandos en la máquina remota (llamada “postgresql” y cuya dirección ip es “192.168.1.27”). Para ser más exactos ordenamos pro medio del comando mkdir crear un directorio oculto (observar el punto delante) y con la opción -p le decimos que obvie error si ya existe el directorio. Con esa opción la línea de comandos no devolverá respuesta alguna si todo va bien, el estoicismo de Linux es heredado del Unix. Ya habrán podido notar que la sintaxis del ssh consiste a dónde se va a conectar y si le colocamos algún otro comando seguido pues simplemente ejecuta ese comando en la máquina remota y “se desconecta”.

Si sólamente colocamos “ssh usuario@máquina” (y por supuesto introducimos nuestra contraseña  de usuario de la máquina remota) quedará la ventana terminal abierta para teclear los comandos que necesitemos, eso sí, cambiando el prompt o indicador (para nuestro ejemplo “jimmy@posgresql:~$“) para que sepamos dónde estamos ubicados.

Paso N° 3: copiando la llave a la máquina remota.

En el paso N° 1 anotamos dónde se guardó nuestra llave digital en nuestro ordenador local (opción por defecto, presionamos intro y escribir otra ruta). Ahora la copiaremos mediante:

cat .ssh/id_rsa.pub | ssh jimmy@192.168.1.27 'cat >> .ssh/authorized_keys'

De nuevo introducimos nuestra contraseña de  usuario en la máquina remota con la aclaratoria del uso del signo “tubería” | que se denota así, una barra vertical que indica pasar los resultados de un comando al otro. Vemos que usamos cat un comando que nos permite visualizar por pantalla el contenido de un archivo de texto (o cualquier otro archivo) sólo que con el uso del signo “tubería” lo que íbamos a ver por pantalla (contenido de la llave digital “id_rsa.pub”) se lo enviamos al comando ssh quien a su vez, como tiene un comando a su derecha, lo pasa al interprete de comando de la máquina remota. Aquí hagamos una pausa para asimilar el resto de la linea (3 comandos).

Así como el comando cat nos permite extraer y visualizar -por pantalla, por defecto-, también nos permite INTRODUCIR texto en un archivo con el uso de los dos signos “>>” pero cambiandole el nombre a “authorized_keys“; si el archivo existiera pues lo agregaría al final (que una máquina remota puede servir para conectarnos desde varias máquinas locales diferentes, cada una con su propia llave digital). De nuevo el estoicismo y sencillez de Linux se hace notar.

Paso 4: asignando permisos a la llave copiada.

Para que nosotros y sólo nosotros seamos los únicos que podamos usar esa llave digital en la máquina remota, debemos asignarnos permisos para nosotros, es decir, los otros usuarios registrados en esa máquina remota les cerramos la posibilidad de leer la llave que acabamos de copiar. De no hacer esto cualquier otro usuario registrado en esa máquina remota pudiera copiarla en un dispositivo e “instalarla” en otra computadora para tener acceso a dicha máquina remota con nuestras credenciales, suplantando nuestra identidad. Este esquema no lo he probado pero también se los dejo como tarea para que lo prueben y se den el gusto de escribirme diciendome que estoy equivocado en mis apreciaciones y conocimientos.

Para ello ejecutaremos el comando chmod a la derecha del comando ssh, ya conocemos bien la sintaxis:

ssh jimmy@192.168.1.27 "chmod 700 .ssh; chmod 640 .ssh/authorized_keys"

Lo único nuevo aquí es el uso del punto y coma para separar un comando de otro dentro del conjunto delimitado por las comillas dobles. En la máquina remota se ejecutará tal cual, lee el primer comando de la izquierda hasta que encuentre el punto y coma, ejecuta y luego sigue leyendo hasta conseguir otro punto y coma (o se acabe la cadena con la comilla que sirve para delimitar).

Paso N° 5: comprobar que funciona.

ssh keygen
ssh keygen

El paso más sencillo: ejecutar la conexión y comprobar “que no nos pide contraseña”, tecleando en la terminal lo siguiente:


Actualizado el sábado 24 de octubre de 2015:

Si quisiéramos conectarnos como usuario raíz o “root” el procedimiento necesitaría unos comandos -y ediciones- adicionales. No obstante la comunidad Linux recomienda NO hacerlo por razones de seguridad, lo mejor es crear un usuario en el grupo de “sudoers”.


Fail2ban para fortalecer servidor.

En esta segunda parte de la entrada nos dedicaremos a estudiar el programa Fail2ban para proteger nuestro servidor SSH revisando periódicamente los registros de acceso a nuestro servidor en búsqueda de síntomas que indiquen un ataque. Cuando un ataque es detectado, que cumplan los parámetros establecidos, Fail2ban actualizará nuestro iptables para bloquear la dirección ip del atacante (o al menos la dirección ip que recibimos) por un período de tiempo o incluso permanentemente. Fail2ban incluso nos avisará por correo electrónico del suceso, si le instalamos algunos programas adicionales. Por último tampoco podemos perder de vista el Ubuntu Fire Wall (ufw).

Instalación de Fail2ban.

Primero debemos verificar si nuestro servidor está actualizado con los últimos parches de seguridad (línea N° 1), luego instalaremos el Fail2ban en sí (línea N° 2), el programa sendmail si queremos recibir correo con informes de sucesos (línea N° 3) y configuraremos el firewall (en este ejemplo de Ubuntu) en las líneas N° 4 y 5:

apt-get update && apt-get upgrade -y
apt-get install fail2ban
apt-get install sendmail
ufw enable
ufw allow ssh

Y las capturas de pantalla para que veaís el resultado de las líneas 2° a la 5°:

apt-get install fail2ban
apt-get install fail2ban

 

apt-get install sendmail
apt-get install sendmail

 

ufw enable & ufw allow ssh
ufw enable & ufw allow ssh

Al instalar sendmail el problema no es la descarga del programa, que es rápido, sino el tiempoq ue tarda instalándose ya que revisa todo el sistema para instalar certificados digitales para la seguridad TLS y muchos otros valores así que paciencia con esto.

Configurando fail2ban.local

Fail2ban, al inciarse en nuestro equipo remoto (que ya tenemos listo para conectarnos “sin contraseña”) primero lee todos los archivos con extensión .conf (que trae por defecto) y luego lee los archivos con extensión .local que están ubicados en la carpeta de sistema /etc/fail2ban. Nosotros podemos aprovechar este comportamiento para nuestro beneficio copiando el archivo fail2ban.conf a fail2ban.local y editar la copia, dejando intacto nuestro archivo original (por si acaso algo sale mal, borramos fail2ban.local y repetimos el proceso):

cp fail2ban.conf fail2.local
cp fail2ban.conf fail2.local

Ahora abrimos con el editor de texto favorito (nosotros usamos nano en este caso) para ajustar los valores necesarios:

nano fail2ban.local
nano fail2ban.local

Podéis hacer click en la imagen para ampliarla en otra pestaña (si su navegador lo permite). Los valores son los siguientes:

  • loglevel: nos permite habilitar el nivel de detalle que nos presentará fail2ban: eventos críticos (“CRITICAL”), de error (“ERROR”), de advertencia (“WARNING”), nota (“NOTICE”), informativo (“INFO”), depuración (“DEBUG”). Por defecto está en “INFO”, cambiad a vuestro gusto.
  • logtarget: nos permite decidir a donde vamos a guardar el informe de fail2ban, por defecto en el archivo /var/log/fail2ban.log . Las otras opciones son STDOUT, STDERR y SYSLOG, esta última puede ser útil si queremos manejar por mensajes del sistema.
  • syslogsocket: como dijimos en el apartado anterior, si seleccionamos SYSLOG para que fail2ba.log nos envie el infrome de sucesos, podemos configurar para que automáticamente utilice la vía por defecto o si queremos ubicarlo en una ruta distinta (se puede dar el caso).
  • socket: nos permite comunicarnos con el “demonio” que corre el servicio fail2ban. Dejamos intacto esta línea, de lo contrario no podremos pasarle órdenes. En el mundo del software libre todo es cristalino y transparente, esta línea es útil a la hora de depurar errores de programación del fail2ban.
  • pidfile: cada vez que se inicie, en este archivo se guardará el PID del servicio (Process Identification Number), esto es un identificador único a nivel del sistema oeprativo y sirve, por ejemplo, si necesitamos eliminar el proceso de la memoria.
  • dbfile: fail2ban utiliza SQLite, un manejador ligero de base de datos, para guardar sus procesos en disco duro de manera indexada, lo cual nos permite buscar rápidamente el historial de eventos, así se detenga fail2ban. Permite establecer el proceso en memoria para rapidez -pero se perderán los datos al apagar el equipo- o simplemente no indexaremos nada (tal vez si nos conformamos con los avisos por correo electrónico pero pensamos que siempre necesitaremos saber más, por eso recomendamos dejarlo en su valor por defecto /var/lib/fail2ban/fail2ban.sqlite3). De este archivo podemos sacar datos si usamos la línea de comandos SQLite3.
  • Si establecimos en el apartado anterior el uso del manejador ligero de base de datos, podemos establecer en esta línea el tiempo máximo (en segundos) que se deben conservar los registros. Recomendamos establecerlo a 7 días en vez de las 24 horas que trae por defecto.

Configurando fail2ban.jail

En este archivo fail2ban.jail haremos lo mismo que hicimos con fail2ban.conf.: copiaremos el contenido de fail2ban.jail a fail2.local para conservar el archivo original. Nota: los desarrolladores advierten que fail2ban.conf será cambiado en cualquier momento en que actualizemos a una nuevar versión. De antemano ya habíamos previsto utilizar los archivos .local y así nos lo especifican en una nota al comienzo del archivo.

Los valores que contiene son los siguientes (usamos de nuevo el editor nano con derechos de administrador):

  • En la sección [INCLUDES] la etiqueta before indica que se lean primero los archivos .conf (ya describimos este comportamiento).
  • En la sección [DEFAULT] la etiqueta ignoreip permite colocar las direcciones ip a las cuales no le aplicaremos regla alguna. Por defecto trae en formato CIDR a la dirección especial de equipo local 127.0.0.1/8 y si queremos o necesitamos podemos colocar direcciones ip específicas e incluso podemos bloquear servidores de nombres de dominio DNS. Debemos separar con un espacio los diferentes valores. Así podríamos, por ejemplo, especificar que no aplicase regla alguna a nuestros fallidos intentos de conexión SSH desde nuestra red de área local (generalmente 192.168.1.X) con la siguiente notación CIDR: 192.168.1.0/24 (una subnet y 255 direcciones ip).
  • maxretry y findtime: el primer parámetro indica cuántos intentos fallidos y en cuál período de tiempo han de haber sucedido para bloquear la dirección ip del atacante. Por defecto el número máximo de intentos son 5 en 600 segundos (10 minutos) o menos.
  • bantime: si cumple con el punto anterior, en este parámetro especificamos por cuánto tiempo bloquearemos la dirección ip del atacante. Por defecto serán 600 segundos sin atender llamada desde esa dirección ip involucrada.
  • usedns: esto lo explicaremos por la utilidad más notable, ver si la dirección ip es dinámica por medio del reverso del DNS. Al llegarnos un ataque podemos usar su dirección ip al DNS bajo la cual está bajo control a fin de determinar si es una dirección ip fija a un nombre de dominio o si es una dirección ip dinámica que cambia constantemente entre los clientes de un proveedor de internet (ISP). La segunda utilidad es poder marcar en un formato legible para nosotros los humanos en el archivo de registro de eventos. Por defecto viene marcada como advertencia.
  • logencoding: permite codificar el archivo de registro, viene marcado como “auto” y esto quiere decir que se utilizará lo que tenga asignado el sistema operativo, Posibles valores: ASCII, UTF-8 (este último formato es útil para nosotros los latino hablantes: castellano, francés, italiano, etcétera).
  • enable: por defecto es falso “false” y permite habilitar el archivo jail correspondiente.
  • filter: permite que el archivo “interactue” con otros mensajes del sistema, dándole el nombre propio del archivo para pasarlo como variable. No tocar esta línea para nada.

Hacemos una pausa para separar los valores destinados al envío de correos del sistema:

  • destemail: por defecto root@localhost será quien esté informado de lo que esté sucediendo.
  • sender: quien envia el correo, se repite el valor root@localhost, como vemos “yo con yo” no es útil así que en destemail colocaremos nuestra dirección de correo electrónico.

Fuentes consultadas.

Aquí les coloco los que visité y leí para poder escribir esta entrada “con sabor venezolano”:

En idioma castellano.

En idioma inglés.

En idioma francés.

Nuestro “tuiteo” acerca de este tema:



<Eso es todo, por ahora>.

Download PDF

GNU Linux Turnkey 14.

Download PDF

GNU Linux Turnkey 14.

GNU Linux Turnkey LAPP 14 es una distribución pensada para instalar-y-usar con un buen conjunto de aplicaciones (LAPP abreviatura de Linux, Apache, Postgresql y PHP) sin descuidar la seguridad (instala claves SSH inmediatamente –algo que deberíamos hacer nosotros mismos-) y un conjunto de valores predefinidos que agilizan nuestro trabajo al montar servidores para la producción, todo esto con las características intrínsecas del Software Libre. CUENTA ADEMÁS (servicio que hay que pagar, eso sí) con DNS y respaldos “en la nube” ya que de algo tienen -tenemos- que vivir los programadores.


Yo sigo la cuenta Twitter del sr. S. Vaughan-Nichols quien siempre tiene interesantes reportajes (y abundantes críticas) sobre el mundo de la informática, muy especialmente en los temas de servidores y lo que está de moda ahora: “la nuuuuuuube” (imaginen tamborileo en paralelo). Él siempre alega la SIMPLICIDAD (muchos lo llamamos “K.I.S.S. principle“) y no sólo critica por criticar sino que ÉL TAMBIÉN APORTA SOLUCIONES.

Es por tanto que me llamó poderosamente la atención el siguiente “trino (tweet)”:

Sigo el enlace, leo el artículo, sigo el otro enlace hacia los creadores de la distribución TURNKEY, noto que en cada artículo colocan el enlace para descargar la imagen ISO con la “distro” más la aplicación deseada -amd64, por supuesto, estamos hablando de servidores-, todo muy bien explicado y detallado (en idioma inglés) y en 5 minutos la descargo y en 2 minutos más la ejecuto en un ambiente VirtualBox y listo, tengo corriendo un servidor LAPP en modo live CD y casi listo para producción. ¿NO ME CREEN? Veánlo “con sus propios ojos”:

La genial idea de los programadores de Turnkey estriba en adaptar una distribución Linux para que, siguiendo los preceptos de la licencia GNU, sea libre y sin embargo si uno desea seguir adelante con un servidor DNS y respaldo de datos en los servidores Turnkey de manera paga y con una genial API KEY en poco tiempo estemos en línea y produciendo dinero.

Esas cosas las admiro profudamente: simplicidad, apoyo inicial y si quieres CRECER allí están para convertirse en socios de manera instantánea. Además  observo que Turnkey no trabaja sola, también vende servicios Amazon para alojamiento, si es que uno no tiene máquina propia para montar lo requerido.


Instalación de Turnkey.

En otras publicaciones he descrito cómo instalar un servidor PostgreSQL y cómo administrarlo con phpPgAdmin paso a paso. Siempre es bueno saber hacerlo todo uno mismo y luego que uno ya haya aprendido no está mal que obtener ayuda extra como la concebida en esta maravillosa distribución Linux Turnkey. A pesar que en los enlaces anteriores describo en detalle el entorno que utilizo, describo un resumen: uso VirtualBox en Ubuntu 64 bits, le asigné 512 megabytes en RAM, 1 CPU, 12 megabytes para vídeo y la única tarjeta de red virtual la configuro como “puente” para que la máquina virtual Turnkey se comunique con mi enrutador inalambrico (y de allí a la internet) quien se encarga del trabajo DHCP y le asigna la dirección 192.168.1.131 con los Norton DNS.

La instalación en sí la vieron arriba en el video que subí -alojamiento cortesía de Youtube- y el detalle adicional es que RECUERDEN BIEN que la distribución del teclado es en inglés [yo hace años que dejé de usarlos, ni siquiera en español tengo ya, sólo distribución Latinoamericano, ojito al meter las contraseñas 😉 ]


Primera vista a Turnkey.

Para el sr. S. Vaughan-Nichols, quien lleva años trabajando con PhpMyAdmin, probó el Adminer y le resultó agradable; en mi caso veo una sencilla interfaz que va directo al grano y sin complicación alguna: yo la recomendaría para aprendizaje previo al PhpMyAdmin y/o PhpPgAdmin.

La primera diferencia que hallo es que para poderme conectar por el explorador de internet (en mi caso Mozilla) debo utilizar el prefijo https. Como les comenté, la seguridad no ha sido descuidadada en esta distribución, ya que genera sus propias claves al instalar la distro Turnkey (en nuestro caso “correr” live CD). Si quieren conocer al detalle los de las claves SSH y su administración recomiendo leer el siguiente post del Maestro Twitter @Phenobarbital Sr. Jesús Lara.

Como dichas claves SSH no están avaladas por un tercero de confianza el navegador hace la debida advertencia de seguridad a la cual le estableceremos unas indicaciones para nuestras pruebas en el servidor virtual Turnkey (si adquirimos una llave API tipo TKLBAM con Turnkey NADA de lo siguiente que explico haría falta hacer).

Turnkey 01
Conectando por primera vez para administrar Turnkey en una máquina VirtualBox.

Como ven el en gráfico anterior haremos click en “comprendo los riesgos” y luego “agregar excepción”. Esto sólo lo haremos con nuestras máquinas que corren en nuestra propia red de área local, jamás ni nunca lo haremos con otros sitios web en internet (sigamos los consejos de seguridad de SUSCERTE).

Turnkey 02
NO agregaremos como permanente la excepción de seguridad.

NO agregaremos como permanente la excepción de seguridad ya que sólo hacemos esto con propósitos didácticos, recuerden que corremos el servidor en RAM -live CD- y cada vez que lo reiniciemos imagino genera nuevas claves SSH así que no embasuremos nuestro querido navegador web ADEMÁS que si hacemos pruebas con otras máquinas virtuales y el enrutador les asigna la misma dirección IP local nos saldrán otros mensajes de advertencia de seguridad, OSEA no nos embaserumos nosotros mismos a la hora de aprender a programar.

Turnkey 03
Portada principal para administrar Turnkey.

Lo primero que vamos a ver es el Adminer LAS FLECHAS ROJAS en las imágenes son de mi autoría para guiarnos paso a paso, hacemos click a donde ellas apuntan.

Turnkey 04
Usando Adminer,
login “posgres”.

El usuario -o “login”- es la palabra “posgres” y la contraseña la que hallamos colocado al instalar -o correr- el Turnkey.

Turnkey 05
Administrando PostgreSQL con Adminer.

En fin, hagan uso de su albedrío y creen bases de datos, agreguen tablas y/o índices, clonen, jueguen y aprendan. Recuerden que como estamos ejecutando un live CD al reiniciar la máquina se perderán todos los datos. Mi imaginación vuela en este caso: si adquirimos una API key que nos permita respaldar con los servidores de Turnkey y una vez hecho eso, apagamos y pudieramos levantar otro servidor virtual en cualquier otro sitio restaurando los datos desde Turnkey, aunque imagino que eso tendrá su costo adicional, respaldar y restaurar con frecuencia. No soy el único en Venezuela que conoce TurNkey ya hay varios usuarios “corriéndolo” en Venezuela: Maracaibo, Barquisimeto, Araure [ ¿? ], Valencia, Puerto Cabello, Maracay, Cumaná y, ¡cómo no!, Caracas.

Turnkey 10
Servidores (al día de hoy 27sep2015) corriendo Turnkey en Venezuela.

Mi imaginación va mucho más allá: la manera como programaron a Turnkey se puede prestar para montar servidores maliciosos. El pequeño detalle es que deben pagarle a Turnkey con una tarjeta de crédito cuyo dueño es localizable por los bancos de manera rápida y si usan una tarjeta robada o extraviada igual es delito federal en los EE.UU. así que esa opción, como ven, queda descartada.


Administrando a Turnkey.

Turnkey 00
Pantalla de bienvenida a Turnkey.

En esta pantalla de bievenida que veremos por cónsola nos muestra un resúmen sobre cómo conectarnos vía remota y ya analizamos como entrar en el apartado anterior. Hago hincapié en la publicidad: si adquirimos una API key TKLBAM la debemos introducir en el cuadro de diálogo anterior y esperar que se realicen las actualizacions y/o instalaciones para montar BIEN EN SERIO UN SERVIDOR PARA PRODUCIR DINERO. Ese tema, por ahora ni lo tocaremos ni lo revisaremos.

Turnkey corriendo en VirtualBox.
Turnkey corriendo en VirtualBox.

Lo que si que vamos a hacer es echar un ojo a las opciones para administrar nuestro futuro servidor:

Turnkey 03
Portada principal para administrar Turnkey.

¿Recuerdan la portada principal? PUES ESTA VEZ HACEMOS CLICK EN EL ÍCONO QUE DICE WEBMIN, olvídense por un momento de la flecha roja [qué pichirre soy con el alojamiento web, NO voy a subir otra imagen nada más que para apuntar con otra flecha roja ja ja ja 😉 ]

Turnkey 06
Entrando a Webmin como usuario “root”.

Usaremos las credenciales de usuario raíz -“root”- y si éste fuera un servidor para producción lo primero que haríamos es crear los usuarios correspondientes y no volver a tocar la dichosa cuenta. Acá como estamos aprendiendo y jugando pues no haremos nada de eso. La contraseña pues, halá, la que introdujimos al instalar -o correr-:

Turnkey 07
Menú principal Webmin.

Sinceramente quedé abrumado por la cantidad de opciones del Webmin lo único que se me ocurre para describirles la aplicación es que es como si estuvieramos sentados en la cónsola del servidor, pero con una interfaz gráfica de la cual carece -excepto de esta manera remota-. Podemos agregar los usuarios que les dije, reiniciar o apagar el equipo (partimos de que estamos conectados por https o SSH y bien seguros), instalar o quitar aplicaciones, configurar la red (ojito con desconectarnos nosotros mismos) y cualquier otra cantidad de cosas. Incluso para nuestro aprendizaje (nunca para un servidor en producción) podemos instalar “Google Gears” -un proyecto que aunque abandonado desde marzo de 2011 seguirá existiendo por SVN – e incluso lo podemos exportar y mantenerlo en nuestro propio espacio GitHub (nada malo ha pasado con el alojamiento de proyectos de código abierto ofrecidos por este gigante, sólamente reconocen que GitHub es mucho mejor e incluso ellos se mudaron también; YO DIGO QUE ES OTRA VICTORIA PARA LINUS TORVALDS Y RICHARD STALLMAN, un proyecto abandonado de software libre puede ser mantenido perfectamente por otros que aún lo consideren importante):

Turnkey + Webmin + Google Gears
Turnkey + Webmin + Google Gears.

Como son muchas las opciones que tiene el Webmin sólamente les mostraré las capturas de pantallas de las opciones del menú:

Webmin opción principal
Webmin opción principal
Webmin opción "system".
Webmin opción “system”.
Webmin opción "servers".
Webmin opción “servers”.
Webmin opción "tools".
Webmin opción “tools”.

 

Webmin opción "networking".
Webmin opción “networking”.
Webmin opción "hardware".
Webmin opción “hardware”.

Apagado de Turnkey virtual.

Espero hayan disfrutado de este post tanto como yo, hoy aprendimos algo nuevo y sólo queda apagar la máquina virtual por (faltaba más faltaba menos) por medio de Webmin:

Apagado de servidores remotos por Webmin.
Apagado de servidores remotos por Webmin.

 

<Eso es todo, ¡por ahora!>.

Download PDF
CANTV Debian logos

CANTV Debian repositorio.

Download PDF

CANTV  Debian repositorio.


 

CANTV Debian repositorio. En mi inquietud de implementar repositorios para Linux en territorio venezolano a fin de ahorrar tiempo y hasta divisas (usar menos los cables submarinos que nos conectan a otros países) me ha llevado hasta consultar “tuiteros” con experiencia en ésa área. Para ello el sr. Juan Carlos Monsalve me ha indicado de un repositorio para Debian alojado en los servidores de datos de CANTV “a dos saltos de distancia” y es por ello que me propongo probarlos en una máquina virtual con Debian 8 Jessie.



  Me dirijo hasta la dirección suministrada, donde muestran la siguiente información para ser introducida en nuestro archivo sources.lst (Debian, y su derivado Ubuntu utilizan “Advance Packaging Tool” para los repositorios de software).  


 

# REPOSITORIOS “MAS VELOCES”, ESTABLES Y VENEZOLANOS (CANTV)
# A solo dos saltos de cualquier usuario ABA

## Debian – stable
deb http://mirror-01.cantv.net/debian/ stable main contrib non-free
deb-src http://mirror-01.cantv.net/debian/ stable main contrib non-free
deb http://mirror-01.cantv.net/debian-security squeeze/updates main contrib

## Actualizaciones de seguridad
deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free

## Backports
deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free

 


Un repositorio, de software en este caso, es simplemente una colección de programas informáticos catalogados y almacenados de manera normalizada (o normada, que sigue las normas) a fin de poderlos descargar para cada ordenador que lo necesite (nuevo o que esté reinstalando su sistema operativo).   He aquí el meollo del asunto: un grupo de servidores no podrá encargarse de entregar para el mundo entero, no resistiría la carga. Es por ello que se implementaron servidores “espejos” -“mirrors” en inglés- que copian la información de, en teoría, los servidores centrales, pero esto no es necesariamente así. Ya que los datos digitales se pueden copiar exactamente como fueron creados y disponemos de algoritmos aplicados para certificar que dichas copias sean exactas al original pues podemos montar servidores espejos desde el que tengamos más cercanos, físicamente hablando.   Acá en Venezuela ese lugar es precisamente Caracas, nuestra ciudad capital. Mi idea es montarlos en las otras ciudades principales de Venezuela, por ejemplo Maracaibo, Valencia o Ciudad Bolívar. Para ello hemos solicitado al Ciudadano Presidente de la República Nicolás Maduro un plan especial de dirección IP fija (aprovechando que las direcciones versión 6 están bien encaminadas a ser implementadas) y el cambio de tecnología ADLS a DSL. Acá publico el video donde el Presidente recibe nuestra solicitud:


     


Ya colocando manos a la obra publico el video donde muestro cómo modificar el archivo (con derechos de root) y mido la velocida de descarga tanto de las cabeceras como de las mismas actualizaciones en sí:



Para lo que yo llamo “catálogo” de aplicaciones descargó 19,6 MB en 36 segundos (velocidad de 541 kB/s) y en este punto he de confesarles que tengo varios equipos conectados en la misma red de área local y al mismo modem CANTV, y uno de ellos trabaja las 24 horas compartiendo las ISO Debian por Torrent (entre otros trabajos que necesito, no viene al caso mencionarlos aquí 😎 ). Es por ello que PUEDE SER que se conecte a mayor velocidad, mi plan es de 10 mbps “de bajada” y 1 mbps “de subida” (¿ya vieron por qué necesito una conexión SIMÉTRICA?).   Ahora bien, hago una pequeña prueba instalando un programa, para la prueba Filezilla el cual utilizo en demasía, y descargó 9004 kB en 15 segundos (velocidad 592 kB/s) tras lo cual quedó satisfactoriamente instalado (de hecho duró más tiempo instalando -26 segundos- que descargando -15 segundos-). Hago notar que POR SUPUESTO mientras más lejos uno esté de Caracas, pues más tardará en descargar, son más los “saltos” a dar dentro de la misma red de CANTV (de allí mi idea de distribuir repositorios por toda Venezuela con el plan sugerido a CANTV).   Poco después el sistema operativo automática detectó las actualizaciones necesarias (éste Debian es el 8.0 y ya salió el 8.2 por lo que son sustanciosos los cambios necesarios).


 


Luego descargó 269,1 MB en 17 minutos a una veolocidad aproximada de 270 kB/s, el verdadero promedio que deseaba obtener con una descarga de tamaño moderado. De nuevo duró más instalando las actualizaciones (253 minutos) que descargandolas (17 minutos). Saquen ustedes mismos sus conclusiones, comparando con las descargas que realizen ustedes en sus casas y/o lugares de trabajo.

<Eso es todo, por ahora>.

Download PDF
Joseph Raphson signature

GoLang Newton Raphson.

Download PDF

GoLang Newton Raphson.

GoLang es un “nuevo” lenguaje de programación en el cual estoy interesado ya que el programa de repositorios llamado Aptly está escrito en ese “idioma de computación” (gracias a Andrey Smirnov @smira). Ustedes pueden obtener información más precisa sobre este lenguaje de programación en este enlace que obtuve via Twitter:

Por ello lo estoy aprendiendo por medio de un tutorial y allí me encuentro con un método para calcular raíces cuadradas por aproximación según Isaac Newton el cual yo no conocía.

Introducción.

Como yo estudié ingeniería y las matemáticas me traen gratos recuerdos me puse a analizar la fórmula que proponen los desenfadados programadores y desenfadadas programadoras de Google (la tuve que nombrar ya que ésta empresa es la que lo patrocina) y definitivamente que no me gustó la fórmula que presentan y el método de programación para calcularla.

Mucha gente ha escrito sobre el tema, incuyendo Wikipedia, por supuesto, pero me pareció un método muy enrevesado, para mi gusto (la historia allí descrita me hace saber que en realidad lo inventó primero el matemático Joseph Raphson pero Newton llegó a la misma conclusión si saber nada del trabajo del otro matemático).

Me encanta ser práctico, ver ejemplos y lo que muestran en este enlace me pareció pulcro y limpio y a pesar que llevo AÑOS sin calcular derivadas y series se llega rápidamente a una solución en el ejemplo 2 (pero yo realmente me deleité con el ejemplo 1) .

Propuesta.

Basado en lo que me explican me propongo programar para calcular CUALQUIER raíz cuadrada de un número natural mayor a 1 y de una manera recursiva (a diferencia de como lo piden en el tutorial con 10 iteraciones) más sin embargo no he podido resolver el detalle de convertir dicha función en un objeto que sólo tengamos que pasarle el número a calcular su raíz cuadrada, la precisión en decimales, sin más desde afuera, como lo planteo siempre hay que modificarle adentro en la función.

Si más preámbulos (que no, que no vamos a estudiar en este post “Análisis Matemático I”, II ni III, ni “Ecuaciones Diferenciales” ni “Matemáticas Aplicadas”) le presento mi solución, con comentarios en castellano:

package main

import (
    "fmt"
    "math"
)

func NewtonRaphson(x float64, comienzo int, margen float64) float64 {
  var resp float64 = 0
  var z    float64
  var dif  float64
  //Cambiar z al entero cuadrado inferior a x para calcular
  //otras raices
  if comienzo == 1 { z = 1   }
  //fin semilla
  if comienzo == 0 { z = x }
  
  //Para calcular otra raíz cambiar el primer 2 por
  //el numero cuya raiz cuadrada se desea calcular    
  z = ( z + 2 / z) / 2
  dif = x - z
  
  
  if dif > margen {
    resp = NewtonRaphson( z , 0, margen)
  } else {
    resp = z
  }
  return resp
}

func main() {
    fmt.Println(NewtonRaphson(2, 1, 0.0000001))
    fmt.Println(math.Sqrt(2))
}

Obteniendo los siguientes resultados, los cuales se aproximan bastante, como ven:

1.414213562373095
1.4142135623730951

Program exited.

Si quisiéramos calcular la raíz cuadrada de 50 debemos hacer dos cambios en el programa (atención: si copian y pegan el código para probar, respeten el indentado):

package main

import (
"fmt"
"math"
)

func NewtonRaphson(x float64, comienzo int, margen float64) float64 {
 var resp float64 = 0
 var z    float64
 var dif  float64
 //Siete elevado al cuadrado es el primer inferior a 50
 if comienzo == 1 { z = 7   }
 //fin semilla
 if comienzo == 0 { z = x }

 //El primer número 2 lo cambiamos por 50
 z = ( z + 50 / z) / 2
 dif = x - z

 //Verifica el margen de error para finalizar el cálculo
 //y devolver el resultado
 if dif > margen {
  resp = NewtonRaphson( z , 0, margen)
 } else {
  resp = z
 }
 return resp
}

func main() {
 fmt.Println(NewtonRaphson(50, 1, 0.0000001))
 fmt.Println(math.Sqrt(50))
}

Y esto es lo que arroja el servidor remoto que ejecuta código:

GoLang cálculo raíz cuadrada de 50 por método Newton Raphson.
GoLang cálculo raíz cuadrada de 50 por método Newton Raphson.

AHORA BIEN ésta es mi primera impresión de este lenguaje (puede ser que esté equivocado), se parece bastante a Python, pero bueno, vamos a “seguirle dando a los hierros” y veremos en que consiste este lenguaje, prometo próximas entradas en este blog acerca del tema.

<Eso es todo, por ahora>.

Download PDF
Ubuntu 6 32 bits 27 junio 2007

Ubuntu 6.10 32 bits.

Download PDF

Ubuntu 6.10 32 bits.

Ubuntu 6.10 32 bits (año 2007 y reinstalado en 2015 por medio de una máquina VirtualBox): un CD que recuperé del baúl de los recuerdos el cual le hice una imagen ISO con Brasero (recuperado en un 99,9% a pesar de haber estado más de 48 horas leyendo y releyendo) y la utilidad de disco confirma los defectos en la imagen grabada. También tiene utilidad de comprobación de memoria RAM, la ejecuté también, todo está en el video.

Por allá en el 2004 tenía una computadora que compré ya armada y me vendieron una marca infame de tarjeta madre (yo recomiendo las marcas Foxconn, Asus y Gigabyte con los ojos cerrados) y dicha tarjeta madre dejó de reconocer disco duro alguno en el 2007, pero al menos si arrancaba desde CD (en aquella época era una novedad en Venezuela el DVD interno para computadora, el cual era el primero de mi propiedad y de paso era quemador también). Así que para no darle más vueltas a ese asunto descargué el Ubuntu y usaba el live CD y guardaba en memoria USB (pendrive). Esa computadora a la final la desarmé y vendí por partes pero como no hay mal que por bien no venga me introdujo a mi primera experiencia real con el Software Libre, submundo Linux.

<Eso es todo, por ahora>.

Download PDF

NASA Journey to Mars.

Download PDF

NASA Journey to Mars:

Porque para eso son las utopías, para siempre ir hacia adelante.

NASA Journey to Mars

NASA is developing the capabilities needed to send humans to an asteroid by 2025 and Mars in the 2030s – goals outlined in the bipartisan NASA Authorization Act of 2010 and in the U.S. National Space Policy, also issued in 2010.

Mars is a rich destination for scientific discovery and robotic and human exploration as we expand our presence into the solar system. Its formation and evolution are comparable to Earth, helping us learn more about our own planet’s history and future. Mars had conditions suitable for life in its past. Future exploration could uncover evidence of life, answering one of the fundamental mysteries of the cosmos: Does life exist beyond Earth?

While robotic explorers have studied Mars for more than 40 years, NASA’s path for the human exploration of Mars begins in low-Earth orbit aboard the International Space Station. Astronauts on the orbiting laboratory are helping us prove many of the technologies and communications systems needed for human missions to deep space, including Mars. The space station also advances our understanding of how the body changes in space and how to protect astronaut health.

Our next step is deep space, where NASA will send a robotic mission to capture and redirect an asteroid to orbit the moon. Astronauts aboard the Orion spacecraft will explore the asteroid in the 2020s, returning to Earth with samples. This experience in human spaceflight beyond low-Earth orbit will help NASA test new systems and capabilities, such as Solar Electric Propulsion, which we’ll need to send cargo as part of human missions to Mars. Beginning in FY 2018, NASA’s powerful Space Launch System rocket will enable these “proving ground” missions to test new capabilities. Human missions to Mars will rely on Orion and an evolved version of SLS that will be the most powerful launch vehicle ever flown.

A fleet of robotic spacecraft and rovers already are on and around Mars, dramatically increasing our knowledge about the Red Planet and paving the way for future human explorers. The Mars Science Laboratory Curiosity rover measured radiation on the way to Mars and is sending back radiation data from the surface. This data will help us plan how to protect the astronauts who will explore Mars. Future missions like the Mars 2020 rover, seeking signs of past life, also will demonstrate new technologies that could help astronauts survive on Mars.

Engineers and scientists around the country are working hard to develop the technologies astronauts will use to one day live and work on Mars, and safely return home from the next giant leap for humanity. NASA also is a leader in a Global Exploration Roadmap, working with international partners and the U.S. commercial space industry on a coordinated expansion of human presence into the solar system, with human missions to the surface of Mars as the driving goal. Follow our progress at www.nasa.gov/exploration and www.nasa.gov/mars.

<¡Eso es todo, por ahora!>.

Download PDF