miércoles, agosto 26, 2015

Tutorial autotools (VII): Crear librerías dinámicas con libtool

Intruducción

En enlazado o linkado dinámico es un mecanismo implementado en la mayoría de sistemas operativos actuales que permite compartir código entre diferentes procesos ejecutándose en la máquina. se implementa normalmente con ayuda de la gestión de memoria virtual del sistema. Las librerías dinámicas son los ficheros donde se almacenan este código compartido las cuales se construyen de diferente manera en función del sistema operativo.

Para intentar aislar las particularidades en la construcción de librerías dinámicas existe la herramienta libtool que se integrar de manera sencilla con las autotools para generar las librerías dinámicas de manera portable.

libtool incluye un script,libtoolize, el que va a crear una serie de scripts y macros m4 en nuestro proyecto que nos permite generar librerías dinámicas olvidándonos de las particularidades del sistema donde lo hacemos. Estos scripts son usados por autoconf y por el script de configure para generar toda la lógica necesaria. Por defecto, los ficheros y scripts que añade son enlaces simbólicos a los mismos instalados en el sistema, pero pueden copiar a nuestros proyectos si se desea.

Voy a usar de ejemplo el código del tutorial 5 que he subido a SourceForge. El código es muy simple, crear una librería de enlace dinámico libtest con tres funciones que se llaman desde el binario principal. Los ficheros configure.ac, Makefile.am y autogen.sh con las macros necesarias para que compilen la librería y funcione el enlazado dinámico serían los siguientes:

configure.ac

El fichero de configure.ac sólo necesita añadir la macro LT_INIT. Esta macro cuando se expande para formar el fichero configure, añade toda la lógica necesaria para las opciones que controlan la creación de librerías dinámicas. Esta macro puede admitir parámetros para establecer cual debe ser el comportamiento por defecto de las opciones.

 1 dnl Esto es un comentario
 2 dnl Esta macro fuerza a una versión mínima de autoconf
 3 AC_PREREQ([2.59])
 4 AC_INIT([tut5],[1.0],[cterron@users.sourceforge.net],[tut5.tar.gz],[https://sourceforge.net/p/autotutorial/])
 5 LT_INIT
 6 dnl Necesitamos el compilador de C
 7 AC_CONFIG_HEADERS([config.h])
 8 AC_PROG_CC
 9 dnl Init automake 
10 AM_INIT_AUTOMAKE
11 AC_CONFIG_MACRO_DIR([m4])
12 dnl Debe de ir al final de la plantilla. Genera el fichero config.status
13 AC_CONFIG_FILES([Makefile])
14 AC_OUTPUT

Makefile.am

En este fichero se va a definir las plantillas que nos van a generar la libreria (llamada libtest) y el binario (tut5) que usará dicha librería. Para definir la librería usamos la variable lib_LTLIBRARIES. Esta es una lista de las librerías que vamos a crear. En nuestro caso libtest.la. Ahora se definen las fuentes que se van a usar para compilar generar la librería. Puesto que el nombre es libtest.la, la variable que hay que definir es libtest_la_SOURCES, en el caso del ejemplo libtest.c. La librería tiene un fichero de cabecera que queremos instalar para que se pueda usar por parte de otros programas,para lo que usamos la variable include_HEADER con la lista de ficheros de cabecera que se desea instalar. También añadimos una variable ACLOCAL_AMFLAGS para que incluya los ficheros de macros del directorio m4. Para que el binario se compile contra la librería dinámica, lo único que hay que definir la variable tut5_LDADD indicando que utilice libtest.la. El contenido del fichero es el siguiente:

 1 # Configurado par 
 2 # Construir la librería libtest.la con las funcioens f1,f2,f3
 3 # Instala la cabecera libtest.h en el sitio correspondiente
 4 # Compila un programa test_lib que llama a dichas funciones
 5 ACLOCAL_AMFLAGS = -I m4
 6 lib_LTLIBRARIES = libtest.la
 7 libtest_la_SOURCES = libtest.c
 8 include_HEADERS = libtest.h
 9 
10 bin_PROGRAMS = tut5
11 tut5_SOURCES = testlib.c
12 tut5_LDADD = libtest.la
autogen.sh

La única modificación necesaria en este fichero es añadir la llamada a libtoolize. Cuando se ejecute, configurará el sistema con los parámetros que deseemos pasarle

1 #!/bin/sh
2 aclocal -I m4  && \
3 rm -rf autom4te.cache/ && \
4 autoheader && \
5 automake --foreign --add-missing && \
6 libtoolize  && \
7 autoconf && \
8 ./configure $@
9 

Compilar y probar el resultado

Compilar el programa es sencillo. Se puede probar sin necesidad de instalar los binarios y las librerías con ayuda de las variables de entorno.

./autogen --prefix=/usr/local
make
env LD_LIBRARY_PATH=.libs/ .libs/tut5 # En Mac env DYLD_LIBRARY_PATH=.libs .libs/tut5

Enlaces

Actualizado 28/08/2015

miércoles, agosto 19, 2015

Controlar el portapapeles de OS X desde la línea de comandos

Mac OS X tiene dos comandos , pbcopy y pbpaste ,que permiten copiar manejar el portapapeles desde la línea de comandos. pbcopy leerá la entrada estándar almacenando los datos en portapapeles, mientras que pbpaste volcará el contenido del portapapeles por la salida estándar.

Por ejemplo, para copiar al portapapeles la salida del comando ls:

baldurgate:Documents terron$ls | pbcopy

Si se quiere copiar el contenido del portapaples a un fichero:

baldurgate:Documents terron$pbpaste > fichero.txt

Por otra parte, tener en cuenta que pbcopy intenta averiguar si los datos que va a copiar al portapapeles utilizan el formato EPS o RTF. En dicho caso, los copia con esos formatos. pbpaste por otra parte comprueba también los datos del portapapeles antes de volcarlos a la salida estándar: comprobará que es texto plano, sino si es EPS y por último RTF. Si los datos no están en ninguno de estos formatos, no vuelca nada.

Hay que tener en cuenta que estos dos comandos utilizan la variable de entorno LANG para determinar la codificación que deben de usar tanto en la entrada y la saluda.

miércoles, agosto 12, 2015

Crear una autoridad de certificación con OpenSSL

OpenSSL es un conjunto de utilidades y librerías que implementan diferentes rutinas criptográficas que ayudan a implementar todo tipo de protocolos seguros. Una de las funciones incluidas nos permite crear una autoridad de certificación o CA: una entidad en la que confiamos que puede emitir o revocar certificados que se usan para tener una comunicación segura.

En esta entrada pretendo crea una CA que nos permita generar certificados que puedan ser usardos para establecer conexiones https o conexiones cifradas con utilidades como socat. Esta CA estará autofirmada y será necesario que su certificado raíz esté disponible para aquellos programas que deseen comprobar la validez de un certificado firmado por la misma. Existen paquetes como easy rsa para quien no quiera hacer estos pasos manualmente.

Crear la autoridad de certificación

Para crear nuestra CA basta con bajarse el fichero de configuración config.cnf y seguir los siguientes pasos que se dan a continuación. En la última parte del artículo se hace un recorrido por todas las opciones de dicho fichero para comprender su funcionamiento.

  • Crear la estructura de ficheros
    mkdir /Users/terron/prog/ca
    mkdir /Users/terron/prog/ca/{certreqs,crls,private,certsdb}
  • Crear el fichero de configuración y el fichero de base de datos.
    cd /Users/terron/prog/ca
    wget -O config.cnf https://sites.google.com/site/underdarktales/home/propios/config.cnf?attredirects=0&d=1
    touch index.txt
  • Crear la clave privada y el CSR de la autoridad de certificación. El sistema pedirá el valor de ciertos atributos del certificado que están definidos en el fichero de configuración, en la sección de la política - ver al final del artículo -
  • cd /Users/terron/prog/ca
    openssl req -new -nodes -newkey rsa:4096 -keyout private/cakey.pem -out careq.pem -config config.cnf
    Las opciones que se le pasa a openssl req son las siguientes:
    • -config Usa el fichero de configuración config.cnf
    • -new Crea una nueva petición de CSR.
    • -newkey Crea una nueva clave RSA. En este caso de 4096 bits de longitud.
    • -nodes Indica que no se debe cifrar la clave privada. Recordar que para mantener la integridad de la CA, es necesario proteger esta clave al máximo.
    • -keyout Ruta al fichero donde se escribirá la clave privada. Se almacenará en private/cakey.pem
    • -out Ruta al fichero donde se escribirá el CSR. Se almacenará en careq.pem
  • Crear el certificado autofirmado e iniciar el número de serie. Este es el certificado que debe de distribuirse a aquellos programas que quiera verificar la autenticidad de un certificado firmado por nuestra CA.
    cd /Users/terron/prog/ca
    openssl ca -create_serial -out cacert.pem -days 3650 -keyfile private/cakey.pem -selfsign -extensions v3_ca -config ./config.cfg -infiles careq.pem
    Con esta llamada a openssl ca se generará el fichero cacert.pem que será el que se deba de distribuir como certificado raíz de nuestra CA. Los parámetros con los que se llamarán serán los siguientes:
    • -config Ruta al fichero de configuración. En nuestro caso config.cnf.
    • -create_serial Esta opción creará el fichero serial.txt y creará un número aleatorio de 128 bits en hexadecimal que se irá incrementando con cada certificado firmado.
    • -out Ruta donde se depositará el certificado firmado por la CA. Además, creará una copia en el directorio certsdb.
    • -days Número de días en las que será válido el certificado desde el momento en que se firme. En este caso, al ser la raíz de la CA, 10 años.
    • -keyfile Clave privada de la CA que se va a usar para generar el certificado firmado.
    • -selfsign Indica que se quiere un certificado autofirmado. Esto se hace para generar el certificado raíz de la CA.
    • -extensions Utiliza la extensión de certificado X.509 definida en el fichero de configuración. En este caso se utiliza la extensión llamada v3_ca y define los atributos necesarios para que el certificado generado sea el raíz de una CA.

Generar un certificado firmado por nuestra CA

Para generar un certificado firmado por nuestra CA es necesario dar los siguientes pasos:

  • Generar una clave privada y un CSR. Es importante, en el caso de querer usar este certificado para https que el campo CN que nos pregunta el comando coincida con el nombre del host o en su caso con la dirección IP, sino no funcionará.
    openssl req -new -nodes -newkey rsa:4096 -keyout server.key.pem -out server.req.pem -config config.cnf
  • Usar el CSR (fichero server.req.pem) generado en el paso anterior para generar nuestro certificado firmado por nuestra CA. Esta orden nos mostrará los atributos del certificdado que está apunto de firmar para que confirmemos la operación.
    cd /Users/terron/prog/ca
    openssl ca -config config.cnf -days 365 -keyfile private/cakey.pem -extensions v3_req -in server.req.pem -out server.cert.pem
    Las opciones son similares al caso del certificado raíz, pero usando otras extensiones para el certificado X.509

Restricciones y posibles problemas

  • La base de datos de texto que usa openssl ca para guardar los certificados firmados es crítica. Si se pierde peude haber problemas.
  • No hay ningún tipo de soporte para concurrencia en openssl ca a la hora de firmar los certificados.

El fichero de configuración

Esta sección contiene una descripción detallada del fichero de configuración config.cnf usado como ejemplo en los pasos anteriores. Este fichero está compuesto de secciones que se utilizan en función de la utilidad de OpenSSL que se llame. Nosotros vamos a usar openssl req y openssl ca para la generación de la autoridad de certificación.

La sección de ca

La estructura de directorio que se va a usar es la siguiente. ROOT indica cual es el directorio raíz donde va a residir los ficheros de nuestra autoridad de certificación.

ROOT
    certsdb
    private
    certreqs
    crls

En el fichero de configuración se va a definir en primer lugar cuales son las opciones que se van a usar. En primer lugar vamos a definir la sección que se va a usar por defecto para defecto para generar la autoridad de certificación.

[ ca ]
default_ca = CA_default

[ CA_default ]
dir              = /Users/terron/prog/ca
database         = $dir/index.txt
new_certs_dir    = $dir/certsdb
certificate      = $dir/cacert.pem
serial           = $dir/serial
private_key      = $dir/private/cakey.pem
RANDFILE         = $dir/private/.rand
default_days     = 365
default_crl_days = 30
default_md       = sha256
policy           = policy_any
email_in_dn      = no
name_opt         = ca_default
cert_opt         = ca_default
copy_extensions  = none

[ policy_any ]
countryName            = supplied
stateOrProvinceName    = optional
organizationName       = optional
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional

Esta primera sección del fichero config.cnf configura el comportamiento del comando openssl ca. Cuando se llame a dicho comando, pasándole la opción -config config.cnf buscar la sección [ ca ]. En dicha sección le hemos dicho, que por defecto, utilice la sección [ CA_default] la cual configura una serie de propiedades de la autoridad de certificación que se está creando.

En primer lugar, se definen una serie de rutas que se van a usar para almacenar los diferentes ficheros y directorios necesarios para el funcionamiento de la autoridad de certificación. Se va a referenciar a partir de la ruta raíz de la autoridad que está definida en la variable dir y en el ejemplo anterior es /Users/terron/prog/ca. Cuando openssl cuando carga el fichero de configuración realizará las sustituciones de variables necesarias por nosotros. Por ejemplo, en nuestro caso $dir/index.txt pasa a ser /Users/terron/prog/ca/index.txt.

Los parámetros que se configuran en esta sección [ Ca_default ]

  • database Configura la ruta hacía la base de datos de certificados. Este parámetro es obligatorio que exista y el fichero debe de existir cuando se empieza a usar la autoridad de certificación. Puede crearse con touch. Se puede especificar la ruta desde la línea de comandos con -database.
  • new_certs_dir Configura la ruta al directorio donde se almacenarán los nuevos certificados firmados por la autoridad de certificación. Este parámetro es obligatorio. Se puede tambiér especificar desde la línea de comandos con -outdir.
  • certificate Ruta hacía el certificado raíz de la autoridad de certificación. Es obligatorio y también puede especificarse desde la línea de comandos con -cert.
  • serial Contiene el siguiente número de serie en hexadecimal para usar en el certificado. Normalmente, en los ejemplos que he visto en Internet se solía configurar con 01, pero es mejor usar una opción cuando se crea el certificado raíz que lo autogenere.Este parámetro es obligatorio.
  • private_key Esta es la clave privada de la autoridad de certificación. De su seguridad depende la integridad de todo el proceso de la autoridad de certificación.
  • RANDFILE Ruta a un fichero usado para leer y escribir semillas que sirvan para la generación de números aleatorios.
  • default_days Número de días en los que será válido un certificado. También puede especificarse con ayuda de la opción de línea de comandos -days.
  • default_crl_days Número de días hasta que se publique la siguiente CRL
  • default_md Algoritmo de huella digital que se utilizará en los certificados y en la lista de revocación de los mismos. Se puede pasar con la línea de comandos con la opción -md. Es obligatoria.
  • policy Configura la sección donde se define la política que va a usar la autoridad de certificación para verificar un certificado. Esta política define qué campos deben de estar presentes y cuales deben de coincidir. Se puede pasar en la línea de comandos con -policy y es obligatoria su definición.
  • email_in_dn Si este campo no está presente o vale yes el campo email, se copiará al . Está configurado para que no se copie.
  • name_opt, cert_opt Estos dos campos controla los campos que se muestran cuando se pide la verificación de un certificado . Existen varios campos, pero lo razonable es dejar el campo ca_default.
  • copy_extensions Controla que hacer con las extensiones que estén presente en las CSR. Si el valor es none , no se copiará ninguna de las extensiones que vengan presenten en el CSR, copy hará que se copia toda extensión que no esté en el certificado destino y copyall copia todas las extensiones del CSR. Hay que tener especial cuidado al usar las opciones copy y copyall porque puede suponer un riesgo de seguridad.

En este fragmento de fichero de configuración se ha definido una política, policy_any. La política corresponde a una serie de campos identificados por su DN. Estos campos tienen tres posibles valores:

  • match El campo debe de existir en el certificado y debe de coincidir con el mismo de la autoridad de certificación.
  • supplied El campo debe de existir.
  • optional El campo puede existir.

Cualquier campo que no esté especificado en la política será descartado sin advertencia. En nuestro ejemplo se ha definido una política que tiene seis campos de los cuales dos son obligatorios y deben de estar presentes. El resto son opcionales.

La sección req

El comando openssl req se controla a través de las sección [ req ] del fichero de configuración. Este comando es el encargado de generar peticiones para que la autoridad de certificación nos la firme. También es el encargado de generar certificados autofirmados para usar en nuestras propias autoridades de certificación. El fragmento del fichero de configuración que se utiliza es el siguiente:

[ req ]
default_bits            = 4096
default_md              = sha256
prompt                  = yes
x509_extensions         = v3_req
distinguished_name      = req_distinguished_name
string_mask             = utf8only
[ v3_req ]
basicConstraints        = CA:FALSE
keyUsage                = keyEncipherment, dataEncipherment
[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address
countryName_default             = ES
stateOrProvinceName_default     = Madrid
localityName_default            =
0.organizationName_default      = Testing OpenSSL S.L.

Los paramétros de configuración de la sección anterior define:

  • default_bits Número de bits por defecto - si no se especifica otra cosa - que tendrán la clave privada de los certificados que se generen.
  • default_md Algoritmo de huella digital que se utilizará por defecto.
  • prompt Si vale no, cogerá los valores por defecto de los campos que utilice el certificado del fichero de configuración. En nuestro caso vale yes porque queremos que el sistema nos pregunte por los campos que se quieren que vayan en el certificado.
  • x509_extensions Este campo nos indica una sección dentro del fichero de configuración que se usará cuando se ejecutemos openssl req con la opción -x509. Esta sección especifica una serie de extensiones que se añadirán al certificado. En este caso se está especificando que utilice la sección [ v3_req ].
  • distinguished_name Especifica la sección donde se definen los campos por los cuales se preguntará al usuario cuando se genere un CSR o un certificado. En este caso la sección se llama req_distinguished_name.
  • string_mask indica que tipo de cadenas de caracteres se va a usar en los campos del certificado. En este caso, se indica que sólo se aceptaran cadenas UTF-8 válidas.

En nuestro caso, la extenciones que se quieren añadir al certificado son

  • basicConstraints
  • keyUsage

Las sección req_distinguished_name define qué campos van a ir en el certificados. Se pueden definir aquellos que se deseen, siempre que se definan a través de la sección oid_section o oid_file. Existen ya una serie de nombres definidos (con sus correspondientes identificadores) en OpenSSL. En nuestro ejemplo se han definido siete campos, y posteriormente algunos valores por defecto (nombre del campo_default)

La sección para las extensiones de la Autorida de Certificación

Para terminar, es necesario añadir una sección especial en el fichero de configuración donde se definen una serie de extensiones a los certificados X.509 que nos permitirán crear la autoridad [ v3_ca ]:

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, cRLSign, keyCertSign

Esta sección define una serie de restricciones que se usarán para generar el certificado raíz de la autoridad de certificación:

  • subjectKeyIdentifier Indica como se debe de calcular el atributo Subject Key Identifier del certificado. Debe de dejarse en el valor de hash.
  • authorityKeyIdentifier Este campo configura como debe de calcularse el atributo Authority Key Identifier, que sirve para identificar la autoridad de certificación que ha firmado un certificado. Este campo indica que se usará para indentificar a la misma. En ecaso del ejemplo se usa el keyid - el identificador de la clave de la autoridad de certificación y issuer que hace que se utilicen los campos Subject y el número de serie del certificado de la CA. Aunque esta configuración puede presentar un problema en caso de que tenga que rehacerse la CA con la misma clave privada.
  • basicConstraints Este es una extensión que indica que el certificado puede actuar como una autoridad de certificación y permite restringir la longitud de la cadena de certificación. En este caso se le está indicando que el certificado si es una CA y que es crítica, es decir, que sino puede acceder a ella no puede ser procesado
  • keyUsage Esta extensión determina cuales son los usos apropiados de la clave de la CA: Al menos debe ser capaz de firmar la lista de revocación de certificados (cRLsign) y los certificados (keyCertSign). En el caso de que esta extensión no esté presente, se permiten todos los usos de las claves.

Referencias


domingo, agosto 02, 2015

Recursos y algunas notas sobre Suricata IDS

Suricata es un sistema de detección de intrusiones y monitorización de red de fuentes abiertas publicado con la licencia GPL. Sus tres principales fortalezas en la actual versión, 2.0.8 son:

  • Escalabilidad gracias a su arquitectura multihilo.
  • Identificación de protocolos en los flujos de datos, lo que permite escribir reglas de detección de patrones orientadas al protocolo no a puertos.
  • La posibilidad de calcular huellas md5 de ficheros al vuelo, extraer los mismos e identificarlos.

Por motivos laborales, he estado buscando bastante información sobre Suricata el último mes. Con esta entrada pretendo crear un pequeño índice que me sirva de ayuda cuando necesite buscar información sobre el mismo.

Documentación y ayudas

Existe un pequeño índice con la documentación oficial de Suricata, donde está la Guía de usuario como documentación más completa y base donde se puede consultar.

Hay tres blogs con una serie de entradas sobre Suricata y su configuración muy interesantes:

Hay dos listas de correos donde se puede obtener información Oisf-users, la lista de usurios de Suricata y para los más aventureros la lista de desarrollo Oisf-devel

Otro recurso importante para obtener información y ayuda es el canal Suricata en la red de IRC Freenode

Estadísticas

Suricata es capaz de generar diversas estadísticas: uso de memoria, alertas, paquetes capturados y perdidos, etc en el fichero stats.log. Para que se generen las mismas es necesario que esté activado en el fichero de configuración. Érin Leblod tiene un programa suri-stats que puede ayudar a analizar y hacer gráficos sobre las mismas. Para activar las estadísticas basta con añadir al fichero de configuración las opciones correspondiente en la sección outputs:

outputs:
  - stats:
      enabled: yes
      filename: stats.log
      append: yes
      interval: 20

Las opciones anteriores hará que Suricata vaya generando cada 20 segundos - interval - la información en el fichero $PREFIX/var/log/stats.log. Además , la información no se borra en cada rearranque (append es yes). El formato de los ficheros de configuración de Suricata es Yaml

Algunas opciones de línea de comandos

Cuando estás midiendo rendimiento y probando configuraciones hay dos opciones que son importante mirar:

  • --build-info Suricata listará las opciones que se ha usado a la hora de generar el binario, las rutas de instalación por defecto y librerías que ha usado. Puede ser una buena idea incluir esta información cuando se va a pedir ayuda.
  • --dump-config Suricata volcará la configuración. Además, el formato en la que la vuelca es muy cómodo porque permite modificar los parámetros al vuelo en la línea de comandos con --set
  • .

Hardware

Es importante tener hardware que tenga la capacidad suficiente para captura el flujo de datos que se quiere analizar. Si se está trabajando bajo Linux implica el uso de hardware al cual se pueda tener acceso con la interfaz de captura AF_PACKET y soporte para los anillos de captura. Además, en función del número de reglas - esto es algo crítico - , se necesitará memoria y CPUs. Leyendo las listas de correo de Suricata no es raro hablar de 64 Gbytes de RAM y 16 cores para poder procesar un conjunto respetable de reglas y tráficos de varios gigabytes por segundo.

Nota sobre configuraciones y pruebas

Cuando se está haciendo pruebas para obtener una configuración óptima de Suricata en un hardware determinado es conveniente ir versionando los ficheros de configuraciones para que seamos capaces de saber que se ha tocado y el rendimiento esperado con las modificaciones. Quizás lo más cómodo sea usar algún sistema de contro de versiones como git que nos permita almacenar cada cambio. Tener algún tipo de sistema de pruenas automático con un tráfico defino también ayuda en esta labor.

sábado, agosto 01, 2015

Multiplexar conexiones ssh

Las últimas versiones de OpenSSH tienen una funcionalidad que permite usar una única conexión ssh para multiplexar varios canales. Se abre y autentifica la primera conexión, y de manera automática, se usa ésta para establecer el resto de canales con la mísma máquina. Es el mismo mecanismo que se utiliza en el forwarding de X11 pero aplicado a todas las conexiones ssh.

Cuando se configura de esta manera el ssh, se establece una conexión master la cual abre un socket Unix y se pone a la escucha en el mismo. Cuando se quiere conectar con la misma máquina, el proceso ssh intentará usar este socket. En caso de que no se pueda, realizará la conexión de manera habitual en función de como hayamos configurado la multiplexación de conexiones.

Para configurar la multiplexación de conexiones hay que modificar el fichero $HOME/.ssh/config y usar las opciones ControlMaster, ControlPath y ControlPersist. Si queremos que sólo estén activas estas opciones para los host de la red 192.168.120.0/24, sería necesario modificar el fichero de la siguiente manera:

host 192.168.120.*
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 300

Controlmaster activa la multiplexación de conexiones y se activa en modo auto. Esto quiere decir que ssh intentará usar la compartición de conexiones y si no está disponible, usará la conexión normal. ControlPath establece la ruta donde se creará el socket Unix que crea ssh para escuchar conexiones y multiplexarlas. Como puede verse en la ruta existe ciertas plantillas que se sustituyen por sus valores: %r es el usuario remoto usado para conectar, %h es el nombre del host y %p es el puerto remoto que se está usando. ControlPersist controla el comportamiento del ssh una vez que se ha cerrado la conexión master. Si vale yes, ssh pasa a segundo plano de manera indefinida, esperando más conexiones, si vale no se cerrará la conexión y en caso de que especifique un valor de tiempo, estará en segundo plano el tiempo que se especifique y finalizará si no hay nuevas conexiones o tráfico.

En la primera captura de pantalla se ve dos conexiones ssh sin compartir el socket. En la segunda se puede ver la multiplexación de conexiones con netstat -na --inet (las opciones de este comando son sólo válidas en Linux)


ssh sin multiplexar

ssh multiplexado