Opciones por defecto en conexiones SSH

Muchos de los que leéis este blog usáis con frecuencia SSH para establecer conexiones a vuestras máquinas y me imagino que la gran mayoría sabrá de la existencia del fichero ~/.ssh/config de SSH. En él se pueden configurar y establecer opciones por defecto para algunas conexiones y que por lo tanto simplificarían mucho el día a día.

El ejemplo típico de estos casos es el de la necesidad de establecer un puerto diferente para la conexión SSH (por defecto, puerto 22). Así que imaginémonos que tenemos que establecer conexión con una máquina en el puerto 2222. Realizar esto implicaría pasarle unos parámetros y acordarse de hacerlo de cada vez.

shell> ssh -p 2222 db.local.net

Haciendo uso del fichero local de configuración de SSH se puede convertir esa llamada en la siguiente

shell> ssh db.local.net

Con únicamente añadir esto,

Host db.local.net
   Port 2222

Si te parece interesante esta opción, échale un vistazo al resto que comentaremos.

Simplificar conexión

Esta es quizás una de las opciones más comúnmente usadas en el fichero ~/.ssh/config. Simplifica con un nombre de conexión todas aquellas opciones que le debamos de pasar para tener una conexión satisfactoria. Un ejemplo,

Host database
   Hostname db.local.net
   User generic_user
   Port 2222
   GSSAPIAuthentication no
   GSSAPIDelegateCredentials no
   IdentityFile ~/.ssh/ssh

KeepAlive en conexiones

Esta es una buena opción a emplear si al equipo al que te conectas tiene un tiempo máximo de conexión sin actividad. Es decir, si pasado un tiempo sin hacer nada, la conexión SSH se cierra, esta es tu opción.

ServerAliveInterval 10

Lo que hará, no será más que enviar cada X segundos un paquete dummy para que la conexión detecte actividad y no se cierre por el servidor.

Multiplexar conexiones y mantenerlas persistentes

Imagínate que necesitas establecer varias conexiones a un mismo equipo remoto. Cada vez que te conectas, pierdes tiempo entre que se establece la conexión y te autenticas. Para solucionarlo, SSH permite multiplexar conexiones, o lo que es lo mismo, establecer una conexión y que el resto de conexiones a ese host empleen el socket abierto por la primera para realizarse. Todo el tráfico irá por la misma conexión y el servidor únicamente tendrá una conexión presente.

Del mismo modo, la opción de crear una conexión persistente indica que aunque la sesión se cierre, quedará un proceso en segundo plano manteniendo la conexión 1 hora (en este caso) y por lo tanto el socket seguirá disponible ese tiempo.

Host firewall
   ControlMaster auto
   ControlPath ~/.ssh/server-%r@%h:%p
   ControlPersist 1h

Ventajas: Acceso y autenticación mucho más rápidos.

Port forwardings

Hay veces que es necesario tener en tu equipo un puerto de un equipo remoto y viceversa. SSH para hacer esto ofrece las opciones -L y -R. El problema es que establecer estas conexiones implica escribir bastante y acordarse del nombre del equipo remoto, y del puerto local y remoto. ~/.ssh/config lo puede hacer por ti.

Host 192.168.1.15
   RemoteForward 8080 localhost:1030

Host 192.168.1.121
   LocalForward 3306 database:3306

Leer más

SSH terminal in web

Hoy os voy a mostrar una pequeña forma de tener accesible un servidor SSH desde un navegador. Supongo que a muchos de vosotros esto no os servirá de nada y a otras muchos les será de gran ayuda. Hay veces que tener una conexión segura SSH es más complicado, sin embargo, tener un servicio vía web que se encargue de ser servidor SSH, pues nos vendrá bien.

Por supuesto, lo que voy a contar ahora simplemente facilita la conexión a una máquina, pero para nada garantiza su seguridad. Así que un control de accesos y un extra de seguridad nunca está demás.

Instalación

Lo primero de todo es instalar el software necesario que vamos a emplear. En este caso usaremos shellinabox, que se define a si mismo como una línea de comandos encapsulada en código AJAX.

Puesto que está disponible desde los repositorios oficiales,

shell> apt-get install openssl shellinabox

Configuración de shellinabox

Una vez tenemos todo instalado, ya está el servicio prácticamente listo para arrancar. Lo único que nos queda pendiente es establecer el puerto por defecto en el que vamos a querer que se ejecute. En mi caso lo voy a poner en el 443 (https). Para ello, editamos el fichero de configuración, /etc/default/shellinabox y lo dejamos como sigue.

SHELLINABOX_DAEMON_START=1
SHELLINABOX_PORT=443
SHELLINABOX_ARGS="--no-beep"

Es decir, la configuración por defecto, únicamente cambiando el puerto de escucha.

Configuración avanzada

La configuración por defecto la verdad es que funciona perfectamente y nos permite ya de por sí abrir una consola en el equipo que está haciendo de servidor. Sin embargo, si nos interesa abrir una consola en otro equipo de la red local, también lo podemos hacer directamente empleando shellinabox. Un ejemplo de configuración para ello sería,

SHELLINABOX_PORT=443

# specify the IP address of a destination SSH server
SHELLINABOX_ARGS="--o-beep -s /:SSH:192.168.0.70"

En donde establecemos que se abra un túnel SSH hacia el servidor con IP 192.168.0.70.

Arrancando servicio

Una vez tengamos ya todo configurado simplemente tendremos que arrancar el servicio.

shell> /etc/init.d/shellinabox start

Y ya podremos conectarnos con un navegador al puerto descrito y tener nuestra shell en el equipo.

shellinabox example

Certificado SSL

Por cierto, shellinabox trae por defecto un certificado autofirmado, pero lógicamente podemos crear nuestro propio certificado si así tenemos más confianza.

shell> cd /var/lib/shellinabox
shell> openssl genrsa -des3 -out server.key 1024
shell> openssl req -new -key server.key -out server.csr
shell> cp server.key server.key.org
shell> openssl rsa -in server.key.org -out server.key
shell> openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
shell> cat server.crt server.key > certificate.pem

Y con ello podemos conseguir, por ejemplo, que el certificado SSL que nos muestre sea de confianza para nuestro navegador, tras importar los certificados pertinentes, lógicamente.

Para más información acerca del servicio empleado o de cómo usarlo puedes ir a su página oficial o leer la página del manual en cuestión.

Leer más

scp: no se encontró la orden

Tras la instalación de una imagen de CentOS mínima me puse a trabajar hasta que llegó el momento de copiar, vía scp, un fichero. Entonces, como en cualquier distribución GNU/Linux, ejecutas el comando scp y te sale el siguiente error.

shell> scp -r test/ javier@192.168.0.25:
javier@192.168.0.25's password: 
bash: scp: no se encontró la orden
lost connection

Tras lo que parece un intento raro de conexión, termina por decir que el comando no existe. La parte importante del mensaje es la de "scp: no se encontró la orden", o lo que es lo mismo, no se encontró el comando.

Para instalarlo bajo CentOS,

shell> yum install openssh-clients

La entrada scp: no se encontró la orden la puedes leer en Puppet Linux.

Leer más

OpenSSH User Enumeration Time-Based Attack

A finales de la semana pasada saltó a la luz un ataque por fuerza bruta contra servidores SSH que permite realizar de forma sencilla una enumeración de usuarios activos en el equipo. Aunque no es 100% fiable, sí ofrece una forma rápida, y la verdad que tras probarla, bastante eficaz de enumerar los usuarios de un equipo.

La prueba de concepto (pequeño script en Python), lo podemos descargar desde IT Security Blog. Para saber si un usuario está o no presente en un equipo llega con hacer una conexión contra dicho equipo. En función del tiempo de respuesta (con contraseña no válida), el script hace una pequeña estimación de si el usuario está o no presente en el equipo.

Aunque este ataque realiza una enumeración de usuarios, no de la tupla user+passwd, no deja de ser grave. El fallo afecta a las versiones 5.x y 6.x de OpenSSH (presentes en la mayoría de los equipos actuales).

La prueba de concepto está disponible para descarga y a mayores es necesario el típico fichero de diccionario,

javier:javier
test:test

Para lanzarlo únicamente,

shell> python ssh_time.py user.list 127.0.0.1:22 5
  Connecting test:test@127.0.0.1:22 
  Error:  Authentication failed.
  Connecting javier:javier@127.0.0.1:22 
  Error:  Authentication failed.
***********************************************************
Found:  ('javier:javier', '127.0.0.1', 22)
***********************************************************

Y efectivamente el usuario javier que existe en el equipo sale en la lista de usuarios.

Mientras esperamos una solución a nivel del servidor SSH para el control de esos tiempos de respuesta, lo mejor es asegurarse de tener claves SEGURAS en las máquinas expuestas, pues la enumeración de usuarios reduce considerablemente el tiempo en ataques por fuerza bruta.

La entrada OpenSSH User Enumeration Time-Based Attack la puedes leer en Puppet Linux.

Leer más

Control de acceso SSH

Aunque ya lo comentamos alguna vez más, hoy vamos a ver otra forma diferente de controlar el acceso de usuarios a nuestro sistema mediante SSH. Si una cosa buena tiene GNU/Linux es que puedas hacer la misma acción de muchas formas diferentes. Hay que reconocer que lo que tiene de bueno, también lo tiene de malo. Pero en la diversidad está el divertimiento, así que manos a la obra.

Partimos de un sistema con el servidor SSH instalado en el que queremos impedir el acceso al usuario root desde SSH (puerto 22), para todos los equipos, exceptuando los de su red, desde los que sí podrá tener acceso. Para lograrlo, debemos editar el fichero /etc/pam.d/sshd y descomentamos o agregamos la siguiente línea,

account    required     pam_access.so

Con ella indicamos al sistema SSH que emplee el módulo pam_access para permitir el acceso. Una vez habilitado, sólo queda configurar dicho módulo. Para ello editamos el fichero /etc/security/access.conf y añadimos la configuración

#Denied ALL EXCEPT
- : root : ALL EXCEPT 192.168.1.

Una forma sencilla y elegante de lograrlo.

La entrada Control de acceso SSH la puedes leer en Puppet Linux.

Leer más

SSH sólo para túneles

Ya hablamos de cómo crear un túnel SSH y también cómo hacer un túnel SSH inverso. Estas dos opciones son muy interesantes, especialmente la primera, a la hora del trabajo diario, sin embargo puede darse el caso de que nos interese establecer un túnel SSH contra una máquina, por ejemplo, para acceder a una tercera, pero que no nos interese (por el motivos que sea) dejar una conexión SSH "abierta", es decir, una consola. Si no vamos a realizar ningún trabajo en esa máquina, sino que únicamente la vamos a emplear de puente, para qué tener una conexión establecida. Para evitar esta consola innecesaria, SSH permite establecer un túnel no interactivo. Para lograrlo, únicamente debemos de emplear la opción -N, que evita que se abra una conexión interactiva (una consola) y la opción -f, que hace que el cliente SSH pase a segundo plano. Luego únicamente debemos de crear el túnel como siempre.

shell> ssh -N -f -L 1025:remote-desktop:443 server-ssh

La entrada SSH sólo para túneles la puedes leer en Puppet Linux.

Leer más

SSH, túnel inverso

Hace un tiempo hablamos en este blog sobre cómo crear un túnel SSH al conectarse a un servidor. Algo que nos puede ser de gran utilidad, especialmente cuando sólo tenemos acceso a un puerto SSH de un equipo en la red, pero sabemos que más allá hay más puertos accesibles.

Sin embargo, SSH permite más tipos de túneles, como puede ser el túnel inverso. Aunque éste es menos común en su uso, puede ser igual de interesante saber, cuando menos, que existe. El funcionamiento es justo el inverso del túnel SSH, es decir, lo que vamos es dar visibilidad de un puerto accesible localmente a un puerto en el servidor al que nos conectamos. Aunque puede que no tenga un interés masivo, el túnel inverso tiene sus utilidades.

La forma de establecerlo es,

shell> ssh -R 1025:localhost:80 server-ssh

Tras ello, desde el equipo server-ssh en el puerto 1025 estará accesible el mismo contenido que desde el equipo cliente de la conexión el 80, o lo que es lo mismo, exportamos el servidor web local al puerto 1025 remoto.

Al igual que con el túnel normal, en el túnel inverso podemos "enviar" un puerto de otro equipo,

shell> ssh -R 1025:win-server:3690 server-ssh

Donde el nombre win-server debe ser resuelto desde localhost, o bien emplear una IP directamente.

La entrada SSH, túnel inverso la puedes leer en Puppet Linux.

Leer más

SSH, limitar los intentos de login

Sobre configuraciones de seguridad y optimización del servidor SSH ya hablamos bastante, pero es cierto que le fichero de configuración del servicio (/etc/ssh/sshd_config) es muy extenso, por lo que siempre habrá parámetros nuevos que nos interese modificar que garanticen un poco más la seguridad. En este caso vamos a comentar 3 parámetros  que no se suelen mencionar muy a menudo, pero que pueden ser de interés.

• LoginGraceTime
  
  Indica el número de segundos que la pantalla de login estará disponible para introducir el nombre de usuario y la contraseña. En caso de que en ese tiempo no se haya introducido nada, se cerrará automáticamente. Es una buena idea dejar este tiempo bajo, a 20 o 30 segundos, que es más que suficiente para que alguien pueda meter sus credenciales.
  Es importante tener este tiempo bien establecido, para así evitar que la pantalla de login quede ahí esperando credenciales por tiempo ilimitado y que alguien no autorizado pueda intentar acceder.

  LoginGraceTime 30
  

• MaxAuthTries
  
  Indica el número de veces que un usuario puede equivocarse de contraseña y el sistema se la seguirá solicitando. Un número bueno de veces son 2 o 3, más ya no, ya que permitiría a un posible atacante reintentar un número de veces mayor obtener las credenciales.
  Es cierto que este número no impide para nada que el atacante vuelva a intentar loguearse, pero cuando menos le obliga a tener que volver a lanzar el comando de login (ssh -l user ip). Algunos bot's por la red dejarán de intentarlo, otros no.

  MaxAuthTries 2
  

• MaxStartups
  
  Indica el número máximo de pantallas de login simultáneas que un usuario podrá tener en el mismo momento. No tiene nada que ver con el número de sesiones por usuario, sino con el número de sesiones de intento de login simultáneos que tendrá. 1 o 2 pantallas deberían de llegar, ya que así evitaríamos tener ataques por fuerza bruta con el mismo usuario.

  MaxStartups 2
  

Lógicamente todas las medidas de seguridad que se pongan en el servidor SSH no son efectivas si la contraseña no es segura. Así que ya sabéis, vuestros usuarios deben siempre tener una contraseña fuerte.

La entrada SSH, limitar los intentos de login la puedes leer en Puppet Linux.

Leer más

Matar una conexión SSH remota

Fijo que a muchos de vosotros os ha pasado alguna vez. Entráis en un equipo y descubrís un usuario que está haciendo un uso del mismo que no debe, o tiene una sesión que no debiera, o cualquier otro motivo. El caso es que necesitáis terminar con dicha conexión remota. Para hacer esto existen diversas formas de lograrlo.

La primera es directamente relacionada con procesos y socket's. Cuando un usuario inicia sesión en un equipo remoto, vía SSH, se abre un socket en éste, por lo que haciendo un poco de uso de netstat y de ps, podremos saber exactamente qué proceso habrá que matar.

shell> netstat -pnat
Proto Local Address    Foreign Address     State        PID/Program name
tcp   0.0.0.0:22       0.0.0.0:*           LISTEN       2086/sshd
tcp   127.0.0.1:20001  0.0.0.0:*           LISTEN       1065/netams
tcp   127.0.0.1:3306   0.0.0.0:*           LISTEN       1697/mysqld
tcp   192.168.1.16:22  192.168.1.33:47350  ESTABLISHED  32322/sshd: javier
tcp6  :::22            :::*                LISTEN       2086/sshd

En la línea destacada en negrita se observa claramente cómo en el servidor (IP: 192.168.1.16) hay una conexión SSH establecida por el cliente 192.168.1.33 con nombre de usuario javier. También se puede observar perfectamente el PID del proceso, 32322. Por suerte, el usuario no está conectado como root, sino como usuario normal, algo lógico por seguridad. Vamos a ver por lo tanto el proceso,

shell> ps -ef | grep 32322
root     32322  2086  0 May06 ?        00:00:00 sshd: javier [priv]
javier   32325 32322  0 May06 ?        00:00:00 sshd: javier@pts/1

Todo usuario normal crea dos procesos, uno como root, que es la sesión de SSH y otro como usuario normal, que es el que realmente debemos de matar. Por lo tanto, en este caso deberíamos de matar el PID 32325. Para ello,

shell> kill -9 32325

Y al cliente le saldrá en su conexión la siguiente línea,

shell> Connection to 192.168.1.16 closed by remote host.
Connection to 192.168.1.16 closed.

Ahora ya es cuestión del administrador encargarse de que dicho usuario no vuelva a iniciar sesión en la máquina si así lo desea.

La segunda forma que vamos a ver es más simple. Es bueno siempre terminar de leerse las entradas ;-). En este caso, vamos a emplear el comando pkill, que tiene un funcionamiento muy similar a kill, sólo que no coge como parámetro el PID del proceso, sino algún otro atributo del mismo. En este caso, el número de terminal.

shell> who
javier   pts/0        2013-05-06 18:41 (:0.0)
javier   pts/1        May  6 18:56 (192.168.1.33)

Con el comando who, obtenemos el listado de los usuarios conectados al sistema. Destacamos en negrita el usuario y la sesión del mismo que queremos eliminar. Como se puede observar, está en el terminal 1 y conectado desde la IP 192.168.1.33.

Ahora hacemos uso de pkill, desde el que le mandamos una señal -9 (KILL) al proceso cuya TTY sea el terminal pts/1, tal que así,

shell> pkill -9 -t pts/1

Espero que esta entrada os pueda ser de utilidad. Siempre es bueno tener a mano los comandos necesarios para volver a tener el control del sistema y limitar los usuarios que estén dentro del equipo. Aunque, lógicamente, lo mejor es no tener que recurrir a estas técnicas.

La entrada Matar una conexión SSH remota la puedes leer en Puppet Linux.

Leer más

Simplificando ssh, ~/.ssh/config

Si sois de los que empleáis SSH para acceder a vuestros equipos, bien hecho!, pero estaréis de acuerdo conmigo cuando os diga que en muchas ocasiones el acceso SSH depende de parámetros y si manejáis una gran cantidad de equipos, recordarlos todos puede llegar a ser una tarea hercúlea.

Pues bien, para simplificar esta tarea, SSH incluye un pequeño fichero de configuración, local a cada usuario, que permite recordar y automatizar esos pequeños parámetros de forma sencilla. El fichero en cuestión es ~/.ssh/config y sobre él podemos definir los equipos a los que queremos acceder, el puerto sobre el que hacer login, usuario, la clave rsa/dsa que se emplear, etc. Algo que resultará práctico.

A continuación os dejo un ejemplo sencillo de cómo emplearlo para que veáis el valor que tiene.

Host github.com
   User git
   Hostname github.com
   PreferredAuthentications publickey
   IdentityFile ~/.ssh/clave_rsa_github

Host web
   User apache
   Port 2222
   Hostname 192.168.1.100

Ahora únicamente bastaría con que nuestro usuario intentase acceder a los equipos por SSH y una simple llamada,

shell> ssh web

Se convertiría automáticamente a,

shell> ssh -p 2222 apache@192.168.1.100

La entrada Simplificando ssh, ~/.ssh/config la puede leer en Puppet Linux.

Leer más

Abriendo puertos por combinación

Hace ya unos cuantos días publiqué un post que trataba de cómo activar SSH en dos pasos para aumentar la seguridad de inicio de sesión. Este tipo de seguridad ofrece una capa extra al típico inicio de sesión de login/password, ya que incluye el factor móvil y temporal. Al más puro estilo Gmail en 2 pasos. Pues bien, esta combinación es efectiva, pero nada impide a los bot's que hay por Internet estar intentando averiguar el usuario para acceder. Aunque estemos más seguros de que no lo van a conseguir, miles de intentos diarios nos ensucian los log's y hace que sea difíciles de controlar. Para ello, hoy vamos a ver cómo programar una combinación de puertos secreta que habilite el puerto SSH cuando nosotros lo requiramos y sino que esté cerrado.

La idea general de esto es, enviamos un ping al puerto X, Y y Z del equipo y éste nos abre el puerto 22 y si lo volvemos a hacer, automáticamente lo cierra, empleando iptables para ello. Esta técnica se conoce como port knocking y realmente se podría englobar en seguridad por ofuscación.

Vamos a comenzar por instalar el software necesario, knockd, para luego preparar el sistema.

shell> apt-get install knockd

Ahora vamos a permitir que el software arranque cuando se inicia el equipo. Para ello editamos el fichero de configuración por defecto, /etc/default/knockd (necesario en Debian/Ubuntu).

START_KNOCKD=1

Ya sólo nos queda configurar knockd para establecer la secuencia que apertura y cierre del puerto SSH. Para ello, editamos el fichero de configuración general, /etc/knockd.conf y lo dejamos tal que así.

Personalmente no me gusta dejar la combinación de puertos por defecto, así que las cambiamos. Los puertos elegidos ya quedan a vuestro gusto.

[options]
  UseSyslog

[openSSH]
  sequence    = 7070,8080,9090
  seq_timeout = 5
  command     = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j DROP
  tcpflags    = syn

[closeSSH]
  sequence    = 9090,8080,7070
  seq_timeout = 5
  command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j DROP
  tcpflags    = syn

Y finalmente arrancamos el nuevo servicio.

shell> /etc/init.d/knockd start
Starting Port-knock daemon: knockd.

Cada vez que deseemos acceder al equipo, simplemente tendremos que emplear nmap antes para habilitar la secuencia mágica de acceso. En nuestro caso,

shell> nmap -sT -p7070,8080,9090 192.168.1.150

Y tras ello, el puerto SSH quedará abierto. Al finalizar el trabajo, lo vamos a dejar cerrado. Para ello,

shell> nmap -sT -p9090,8080,7070 192.168.1.150

Por cierto, del lado del servidor SSH que estamos abriendo veremos el "ábrete sésamo",

knockd: 192.168.1.33: openSSH: Stage 1
knockd: 192.168.1.33: closeSSH: Stage 2
knockd: 192.168.1.33: closeSSH: Stage 3
knockd: 192.168.1.33: closeSSH: OPEN SESAME
knockd: closeSSH: running command: /sbin/iptables -D INPUT -s 192.168.1.33...

Leer más

SSH, remote port to local port

Este es un pequeño y sencillo truco que muchas veces se nos olvida. SSH tiene la posibilidad de compartir puertos, tanto de local a remoto como de remoto a local. Muchas veces puede que tengamos acceso al puerto SSH de un equipo, pero no a otros puertos o a puertos de otros equipos. Entonces... ¿Cómo accedemos a diferentes puertos? Con SSH y el nateo de puertos, o lo que es lo mismo, estableciendo un túnel SSH. Con algo tan sencillo como

shell> ssh -L 8080:localhost:80 equipo.remoto.com

conseguimos que bajo el puerto 8080 de nuestro equipo local (localhost) esté el mismo contenido disponible que en el 80 del equipo remoto.

En caso de que nos interese ir un paso más allá, podremos hacerlo tal que así,

shell> ssh -L 8080:segundo.remoto.com:80 primero.remoto.com

En este caso, en localhost tenemos el puerto 80 de un equipo al que no podemos acceder, pero al que el equipo remoto sí puede acceder.
Posibilidades de SSH, muchas ;-)

La entrada SSH, remote port to local port la puedes leer en Puppet Linux.

Leer más

SSH logout automático

Fijo que a muchos de vosotros os ha pasado alguna vez lo de dejar una sesión SSH abierta en un equipo hasta el día siguiente o la media hora del café. Ahora imaginarios que el equipo no quedase bloqueado y que algún curiosos se acercase. Una sesión abierta en una máquina abandonada nunca es buena combinación. Para evitar este tipo de despistes, vamos a configurar nuestro servidor SSH para que haga un logout automática de aquellas cuentas que no muestren actividad pasado un tiempo. Este tiempo debe ser prudencial, por ejemplo 10 minutos (600 segundos).

Para hacerlo debemos de editar el fichero de configuración del servidor SSH (/etc/ssh/sshd_config) y meter los siguientes valores,

ClientAliveInterval 600
ClientAliveCountMax 0

Tras hacerlo, simplemente reiniciamos el servicio SSH para que recargue los nuevos valores.

shell> service sshd restart

Ahora si no hay actividad en una cuenta durante 10 minutos esta será automáticamente cerrada por el sistema, evitando así las "sesiones olvidadas".

SSH también no permite definir el tiempo que transcurre desde que un usuario pide sesión hasta que éste se autentica. Es la variable

LoginGraceTime 30

la cual también podemos y debemos acortar para evitar dejar un tiempo excesivo un intento de login.

La entrada SSH logout automático la puedes leer en Puppet Linux.

Leer más

MSM760 Controller, automatic WiFi key

En post anteriores (hp, enterasys) mostramos la forma de ejecutar comandos en sistemas que no admiten una ejecución continuada, sino que van pidiendo datos poco a poco, como puede ser la shell de router's o switch's. Hoy quiero dejar disponible un pequeño script que hice hace tiempo y que trata sobre cómo cambiar automáticamente la contraseña en un equipos HP MSM760. Este equipo es un controlador WiFi que tiene infinidad de configuraciones. Dispone de un interfaz web para administrarlo o como buen equipo con Linux que es, una pequeña shell de control. Aunque es muy limitada, por ejemplo el cambio de claves de la WiFi y la sincronización de los AP's es sencillo de automatizar. Os dejo a continuación el código.

#!/usr/bin/expect -f

set KEY [lindex $argv 0]

spawn ssh admin@192.168.1.2
match_max 100000
expect -exact "Password:"
send -- "mi_passwd\n"
expect -- "CLI>"
send "enable\n"
expect -- "CLI#"
send "config\n"
expect -- "#"
send "virtual ap \"WiFi\"\n"
expect -- "#"
send "encryption key 1 $KEY\n"
expect -- "#"
send "end\n"
expect -- "#"
send "end\n"
expect -- "#"
send "controlled network group \"Listado APs\"\n"
expect -- "#"
send "execute action synchronize\n"
expect -- "#"
send "end\n"
expect -- "#"
send "end\n"
expect -- ">"
send "quit\n"

Para aquellos a los que le interese, pueden consultar más datos del manual del equipo.
Una vez que tengamos el script, lo podemos colocar, por ejemplo en /usr/local/sbin/change_pass y luego, cada vez que necesitemos cambiar la contraseña de nuestra WiFi, únicamente habrá que llamarlo, pasándole como parámetro la nueva clave que deseemos.

shell> /usr/local/sbin/change_pass 12345

En caso de que nos interese cambiarla diariamente, podremos programarlo desde cron añadiendo la siguiente línea,

... PASS=`< /dev/urandom tr -dc A-Za-z| head -c4; echo n`; /usr/local/sbin/change_pass $PASS

La entrada, MSM760 Controller, automatic WiFi key la puede leer en Puppet Linux.

Leer más

SSH: Autenticación en dos pasos

Hace ya tiempo Google sacó un sistema novedoso, la autenticación en 2 pasos para todo su sistema. Para aquellos que no lo conozcáis, no es más que un extra se seguridad a tu contraseña basado en un código temporal que deberás de introducir cada vez que quieras iniciar sesión en Google. Puesto que el código es aleatorio y se cambia cada 30 segundos, es extremadamente complicado que alguien que esté a la escucha (ataque made in the middle) pueda capturar la contraseña y aprovecharse de ello. Ya no digamos, adivinarla directamente.

Recientemente encontré un proyecto, Google Authenticator que lleva la misma filosofía a nuestro servidor SSH, permitiendo así tener un segundo paso de autenticación. Imaginaros un servidor SSH expuesto a Internet, pues nunca está demás tener un extra de seguridad, así que esta autenticación en dos pasos, es muy interesante.

En este post vamos a ver cómo configurar este nuevo software con nuestro servidor SSH y cómo poder enlazarlo en nuestro móvil (Android, iPhone o Blackberry). Para ello, vamos a seguir unos sencillos pasos.

1. Descargar la aplicación Google Authenticator
   Está disponible en los market's de vuestro sistema. Por lo menos en Google Play, como "Google Authenticator". También necesitamos tener instalado un lector de códigos QR, para hacer los pasos más sencillos. Yo os recomiendo Barcode Scanner.
2. Instalar el software necesario en el servidor GNU/Linux
   
   Si estás empleando Ubuntu, puedes añadir directamente el repositorio,

   shell> add-apt-repository ppa:failshell/stable
   shell> apt-get update
   shell> apt-get install libpam-google-authenticator
   

   En caso de emplear otra distribución, puedes descargar el código desde aquí y compilarlo.
   Una vez tengas el software instalado, sólo quedará por realizar los pequeños cambios en los ficheros de configuración oportunos.
   1. /etc/pam.d/sshd

      auth required pam_google_authenticator.so
      ...
      ...
      

   2. /etc/ssh/sshd_config

      ChallengeResponseAuthentication yes
      

   3. Reiniciar el servidor ssh

      shell> service ssh restart
      

3. Generar la clave para el usuario
   
   Ahora que ya el administrador hizo todo su trabajo, sólo queda generar una nueva clave. Para ello habrá que ejecutar el comando 'google-authenticator' como usuario, lo que generará un código QR que será el que tengamos que leer con nuestro teléfono. A mayores, nos ofrece un 5 códigos de emergencia, los cuales debería de ser guardados en un lugar seguro y también una clave secreta, por si no tienes un lector de códigos QR, poder crear la nueva cuenta en la aplicación móvil.

   shell> google-authenticator 
   
   
   
   
   
   
   
   
   
   
   
   
   
   Your new secret key is: GSDRTAHDMEHZ5545
   Your verification code is 785634
   Your emergency scratch codes are:
     62294539
     67649794
     80559805
     17028096
     57642341
   
   Do you want me to update your "~/.google_authenticator" file (y/n) y
   ...
   ...

4. Añadirla en el teléfono
   
   
   Antes de cerrar la consola, necesitamos abrir la aplicación Authenticator de nuestro móvil y configurar una nueva cuenta. Ahí nos permite añadirla desde un código QR o desde un clave manual. Elegimos la primera opción y escaneamos el código que obtuvimos. Automáticamente se nos añadirá la cuenta a la aplicación y como veréis hay un pequeño reloj en la parte derecha que indica el tiempo de validez de la contraseña. Una vez termina, se genera una nueva clave.
5. Acceder al sistema
   
   Si todo está correcto, la próxima vez que se intente acceder al sistema recién configurado veremos que para hacer efectivo el acceso será necesario la verificación en dos pasos. La contraseña y la clave aleatoria.

   javier@local> ssh remote_host
   Verification code: 
   Password: 
   Welcome to Ubuntu 12.10 (GNU/Linux 3.5.0-18-generic i686)
   
    * Documentation:  https://help.ubuntu.com/
   
   
   javier@remote> 
   

   En caso de que alguna de las dos no sea correcta, el sistema no permitirá el acceso.

Sin duda es una forma muy útil de tener un extra se seguridad a muy bajo precio y aparte del software aquí comentado, lo único que se necesita es que ambos equipos (móvil y equipo) estén con la hora sincronizada (NTP), para que la clave generada - clave esperada coincidan.
Más información en, www.howtogeek.com y en Google-authenticator wiki

La entrada SSH en dos pasos la puedes leer en Puppet Linux.

Leer más

OpenSSH, permitir acceso por usuarios/grupos

En el post anterior hablamos de cómo poder bloquear el acceso ssh a un equipo mediante las directivas DenyUsers y DenyGroups. Ahora toca hablar de cómo poder permitir el acceso a un equipo por ssh, para lo que existen las directivas AllowUsers y AllowGroups.

Antes de nada, hay que aclarar que por defecto, si no se emplea ninguna directiva, TODOS los usuarios del sistema pueden acceder por ssh al equipo, pero que en caso de que alguna de las directivas de acceso estén habilitadas, sólo lo podrán hacer aquellos que la cumplan.

Entonces... ¿para qué sirven las directivas Allow*?

Pues bien, sirven para tener un mayor control de usuarios que pueden acceder siempre que el número de estos vaya a ser menor que el número de usuarios que no, sino, tendría más sentidos usar las vistas anteriormente.

Al igual que para Deny*, también tenemos control de usuarios y grupos.

• AllowUsers

  AllowUsers user1 user2
  

• AllowGroups

  AllowGroups grupo_acceso_ssh
  

Nota: No está permitido usar UID's o GID's para especificar a los usuarios.

Leer más

OpenSSH, denegar acceso por usuarios/grupos

OpenSSH es el servidor SSH open source que está incluido en prácticamente todas las distribuciones de GNU/Linux y Unix en general. Es muy potente y versátil a la vez. Tiene un fichero de configuración principal, /etc/ssh/sshd_config, que es muy potente y esconde ciertas directivas que permiten definir muy bien quién puede y no puede acceder al equipo, dándole así un punto extra de seguridad.

En este post vamos a ver las directivas de denegación de acceso y cómo poder usarlas. Existen dos tipos de directivas, denegación por usuario y denegación por grupo. A continuación se verá un ejemplo de ambas.

• DenyUsers
  
  Se especifica aquellos usuarios a los que se desea bloquear el acceso. Por defecto, ssh permite acceder a todos los usuarios del sistema. Si se especifica con la directiva DenyUsers una lista de usuarios, a éstos no les será posible iniciar sesión por ssh en el sistema.

  DenyUsers user_1 user_2 user_3
  

• DenyGroups
  
  El funcionamiento es muy similar al de los usuarios, simplemente que permite especificar un grupo que contenga usuarios.
  Esto ofrece la ventaja de ante un nuevo usuario que no se le quiera permite el acceso, simplemente lo agregamos al grupo bloqueado y ya no podrá acceder. Si empleamos el DenyUsers habría que editar el fichero de configuración de ssh y recargar el servicio.

  DenyGroups group_no_ssh
  

Leer más

Configuración PAM+SSH para permitir acceso SSH

Si justo en el post anterior hemos explicado cómo hacer para tener un fichero con los nombres de usuario a los que queremos denegar el acceso, también podemos hacer lo mismo pero a la inversa. Tener un fichero sólo con los nombres de los usuarios a los que permitiremos el acceso SSH. En realidad el funcionamiento es el mismo, sólo que cambia un poco la línea a añadir en PAM (/etc/pam.d/ssh).

...
auth required pam_listfile.so item=user sense=allow file=/etc/ssh/ssh.allow onerr=fail
...

Como se puede observar, ahora el tipo sense es allow, es decir, los usuarios que coincidan podrán acceder. Y para ser un poco más coherentes, cambiamos el nombre del fichero a /etc/ssh/ssh.allow.

Ahora si un usuario quiere poder acceder al sistema, tendrá que estar dentro de dicho fichero.

Leer más

Configuración PAM+SSH para denegar acceso SSH

Existen muchas formas de denegar el acceso de un usuario a un sistema GNU/Linux, pero quizás el empleo del módulo pam_listfile.so en SSH sea uno de los más efectivos y potentes.

Se puede dar el caso de que un usuario pueda tener que acceder al equipo localmente, pero de ninguna forma nos interese que éste pueda acceder remotamente. En este caso, tener un listado de usuario al que denegarle el acceso sería más que interesante. Pues bien, esto es lo que vamos a configurar a continuación. Para ello, vamos a modificar el módulo SSH de PAM (/etc/pam.d/ssh) para indicarle que emplee la opción de una lista de usuario denegados, tal como sigue.

...
auth required pam_listfile.so item=user sense=deny file=/etc/ssh/ssh.deny onerr=succeed
...

Una explicación sencilla de la línea que acabamos de agregar es:

• auth required pam_listfile.so
  Nombre del módulo requerido para validar los usuarios.
• item=user
  Chequea el campo usuario.
• sense=deny
  Deniega el acceso si el usuario está en el fichero especificado.
• file=/etc/ssh/ssh.deny
  Fichero con los nombres de usuario (uno por línea)
• onerr=succeed
  Devuelve un PAM_SUCCESS si hay un error.

Una vez tenemos agregada la línea anterior, simplemente creamos el fichero /etc/ssh/ssh.deny y escribimos los nombres de usuario a los que queramos impedir el acceso, uno por línea.

usuario_1
usuario_2
...

Desde este momento cualquier usuario que desee acceder al sistema y esté dentro del fichero ssh.deny no lo podrá hacer.

Leer más

Bloquear acceso sftp, scp, rsync, ssh

Hace tiempo vimos una forma simple de hacer que un usuario sólo pueda acceder por sftp al sistema y que además quede "enjaulado" en su home, impidiéndole así cotillear archivos que no debe. Sin embargo esa forma quizás no es del todo flexible que nos pueda interesar. Para hacerla un poco más manejable, hoy vamos a ver cómo empleando rssh vamos a poder seleccionar las diferentes formas de acceso que se van a permitir al sistema.

rssh es una shell restrictiva, que permite elegir el método de acceso que se desea entre los disponibles: scp, sftp, cvs, svn, rsync o rdist. Para usarla primero habrá que instalarla.

shell> apt-get install rssh

Una vez instalada sólo queda configurarla y emplearla. Para empezar vamos a incluir la nueva shell instalada como una shell válida dentro del sistema. Para ello,

shell> echo "/usr/bin/rssh" >> /etc/shells

Y a continuación la configuramos (/etc/rssh.conf). Aquí es donde podemos optar por una configuración general o una particular para cada usuario.

• General
  
  Establece los métodos de conexión permitidos por la shell y se aplican a todos los usuarios. Se define al principio del fichero de configuración.

  ...
  #allowsvnserve
  #allowscp
  allowsftp
  #allowcvs
  #allowrdist
  #allowrsync
  ...
  

• Particular
  
  Se aplica a cada usuario y permite diferenciar usuario a usuario el método de acceso, así como la jaula chroot (si se desea) en la que éste quedará encerrado con dicha conexión. La forma de establecer a qué tendrá permisos es mediante una máscara binaria (0: no permitido, 1: sí permitido).

  user=javier:011:000010:"/home/javier chroot" # scp with chroot
  user=javier:011:000100:"/var/www chroot"     # sftp with chroot
  user=test:011:000110                         # scp & sftp
  

Una vez establecidos los permisos en el fichero de configuración tendremos que indicarle al sistema que emplee la nueva shell a aquellos usuarios que nos interese. Por lo tanto si creamos un usuario nuevo,

shell> adduser --shell /usr/bin/rssh javier

Y si modificamos uno existente,

shell> usermod -s /usr/bin/rssh test

Ahora al intentar acceder con algún sistema del que no se tenga permisos saldrá la advertencia de que no es posible acceder y los métodos para los que sí está habilitado el acceso a dicho usuario.

shell> ssh -l test 192.168.1.35
test password:
Last login: Wed Feb  9 22:49:47 2011 from 192.168.1.33

This account is restricted by rssh.
Allowed commands: sftp and sftp

If you believe this is in error, please contact your system administrator.

Connection to 192.168.1.35 closed.

Leer más