Aviso: Este artículo asume conocimiento del protocolo TCP

Este es un listado de los ataques TCP más comunes que te puedes encontrar en un servidor en internet.

SYN Flood

Cuando un cliente inicia una conexión TCP con el servidor, lo hace en un intercambio de 3 paquetes llamado 3-way handshake:

  • 1 El cliente inicia la petición de conexión enviando un paquete SYN al servidor
  • 2 El servidor responde enviando un paquete SYN-ACK
  • 3 El cliente responde con un paquete ACK para estableces la conexión

El ataque consiste en iniciar la petición de conexión enviando un paquete SYN tras otro, al llegar al servidor cada petición abre una nueva entrada en la tabla de conexiones, y envía un paquete SYN/ACK que el atacante ignora. El servidor espera un tiempo antes de descartar un conexión que no fue exitosa, y con la llegada de cada vez más peticiones, la tabla de conexiones se va llenando hasta que no quedan recursos para gestionar el trafico legitimo.

Las ventajas desde el punto de vista del atacante, es que el ancho de banda necesario para este ataque es relativamente bajo, especialmente si se usa ip-spoofing para falsificar la dirección IP de origen de los paquetes SYN, de manera que la respuesta SYN/ACK se envían a un tercero.

SYN Flood (Wikipedia)

SYN Scan

Un escaneo no es un ataque per se, pero suele ser un precursor a un ataque en el que se escanean los puertos, para buscar servicios disponibles.

En un escaneo SYN en lugar de conectar al puerto para determinar si está abierto, un atacante envía un paquete SYN y espera a la respuesta, si es SYN/ACK indica que el puerto esta abierto, si no hay respuesta o es un paquete RST el puerto está cerrado. Si la respuesta es un paquete SYN/ACK, el atacante no envía el paquete ACK de respuesta, no finalizando la conexión lo que hace que sea más difícil de detectar.

XMAS/FIN/NULL Scan

Un escaneo XMAS envía un paquete tcp con los flags FIN, URG, y PSH activados. Si el puerto esta abierto no hay respuesta, pero si el puerto está cerrado el destinatario responde con un paquete RST/ACK. Este método sólo funciona en sistemas que siguen las especificaciones RFC793.

Un escaneo FIN es similar a un scan XMAS pero envía un paquete con el flag FIN activo, recibe las mismas respuestas que XMAS

NULL es similar a los otros dos pero envía un paquete con ningún flag activo.

Enlaces

Ver comentarios


Acabo de configurar un VPS como servidor web, y estas son las reglas iptables con las que empiezo todo firewall, a partir de aquí voy añadiendo todos los servicios adicionales que se necesiten.

#!/bin/bash

# Limpiar todas las reglas.
iptables -F
iptables -t nat -F
iptables -t mangle -F

# Creamos tabla para reglas de seguridad eth0
iptables -N security_eth0
iptables -F security_eth0
iptables -A INPUT -i eth0 -j security_eth0

# Admitimos todos los paquetes en interface loopback.
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Aceptamos todos los paquetes de conexiones ya establecidas
iptables -A INPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Permitir todas conexiones HTTP entrantes
iptables -A INPUT  -i eth0 -p tcp --dport 80 -m state --state NEW -j ACCEPT

# Permitir todas conexiones SSH entrantes
iptables -A INPUT  -i eth0 -p tcp --dport 22 -m state --state NEW -j ACCEPT

# Permitir conexiones SSH salientes (DESACTIVADO)
# iptables -A OUTPUT -o eth0 -p tcp --dport 22 -m state --state NEW -j ACCEPT

# Permitir icmp (ping,....)
iptables -A INPUT  -p icmp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT

# Permitir acceso DNS saliente
iptables -A OUTPUT -p udp -o eth0 --dport 53 --sport 1024:65535 -j ACCEPT
iptables -A INPUT  -p udp -i eth0 --sport 53 --dport 1024:65535 -j ACCEPT

# Por defecto descartamos los paquetes no aceptados explicitamente
iptables -P INPUT   DROP
iptables -P FORWARD DROP
iptables -P OUTPUT  DROP


#
# Medidas de seguridad para paquetes entrantes eth0
#

# echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Descomentar la siguiente linea para desactivar la tabla security_eth0
# iptables -A security_eth0 -j RETURN

# Ignoramos paquetes nuevos que no tengan flag SYN activado
iptables -A security_eth0 -p tcp ! --syn -m state --state NEW -j DROP

# Ignoramos paquetes invalidos
iptables -A security_eth0 -m state --state INVALID -j DROP

# Descartar paqueter fragmentados
iptables -A security_eth0 -f -j DROP

# Descartar paquetes XMAS
iptables -A security_eth0 -p tcp --tcp-flags ALL ALL -j DROP

# Descartart paquetes NULL
iptables -A security_eth0 -p tcp --tcp-flags ALL NONE -j DROP

# Descartar ip falsas (spoofing)
iptables -A security_eth0 -s 0.0.0.0/8 -j DROP
iptables -A security_eth0 -s 127.0.0.0/8 -j DROP
iptables -A security_eth0 -s 10.0.0.0/8 -j DROP
iptables -A security_eth0 -s 172.16.0.0/12 -j DROP
iptables -A security_eth0 -s 192.168.0.0/16 -j DROP
iptables -A security_eth0 -s 224.0.0.0/3 -j DROP

Descargar

Este script bloquea todo tráfico entrante y saliente, excepto conexiones entrantes a los puertos html y ssh, el protocolo icmp, y las consultas DNS salientes. También crea la tabla security_eth0, donde se filtran todos los paquetes entrantes por eth0, para realizar algunos chequeos de seguridad.

Si no quieres añadir el script directamente a init.d, puedes introducir las reglas manualmente en el shell, y luego usar iptables-persistent para salvarlas.

$ sudo apt-get install iptables-persistent

Durante la instalación preguntará si quieres salvar las reglas de iptables, responde si, y serán salvadas en /etc/iptables/rules.v4 para ipv4, y /etc/iptables/rules.v6 para ipv6. Por último iniciamos el servicio:

$ sudo service iptables-persistent start

Ver comentarios


Hace unos días encontré un video interesante sobre inyección SQL en PHP (Inglés), y lo que me pareció más curioso, es que aún siga siendo un problema de seguridad tan extendido, he buscado las cifras y es el segundo ataque más usado con un 16%, detras de cross-site scripting con un 37%.



Si te ha gustado el video, el canal Computerphile tiene muchos más videos interesantes relacionados con la informática.

Ver comentarios


AIDE (Advanced Intrusion Detection Environment) es un programa de detección de intrusos, en especifico un monitor de integridad de archivos. Cuando un intruso consigue acceso a un sistema, una sus primera acciones será modificar los logs del sistema, y/o modificar algún programa para mantener el control, y ocultar su presencia. Por ejemplo puede sustituir el programa ps para que no liste determinados procesos, añadir el bit SUID a una copia del shell, o instalar algún rootkit.

Detectar esto es prácticamente imposible manualmente, AIDE en cambio nos permite hacerlo de forma rápida y sencilla, haciendo imposible cualquier manipulación de los archivo o directorios monitorizados.

Instalación

La instalación es sencilla la única dependencia del paquete, es un servidor de correo para poder enviar los informes y alertas al root, o a la dirección especificada, asegurate de que esta funcionando correctamente, antes de continuar con la configuración.

sudo apt-get install aide

Configuración

Antes de modificar la configuración por defecto de aide, vamos a comprobar que funciona correctamente, para ello generamos la primera base de datos. Este proceso puede ser muy lento dependiendo del ordenador, y del numero de archivos a monitorizar.

sudo aideinit

Una vez generada, la copiamos para instalarla:

sudo cp /var/lib/aide.db.new /var/lib/aide.db

Ahora podemos modificar la configuración para incluir cualquier directorio que necesitemos monitorizar, o eliminar algún directorio en el que no estemos interesados. Los archivos de configuración de AIDE en Debian/Ubuntu, son /etc/aide/aide.conf y el directorio /etc/aide/aide.conf.d/ , estos no son usados directamente por AIDE, sino que el script update-aide.config recopila toda la información y, crea el archivo final /var/lib/aide/config.autogenerated.

Para añadir nuestros directorios a la configuración, tenemos que crear un archivo en el directorio /etc/aide/aide.conf.d

sudo touch /etc/aide/aide.conf.d/60_aide_custom
sudo chmod 644 /etc/aide/aide.conf.d/60_aide_custom

El número al inicio indica el orden en el que el archivo es cargado, hay que asegurarse de que el numero de nuestro archivo es el mayor del directorio, de esta manera nuestra configuración sea la última en cargar y no tengamos conflictos.

Cada archivo contiene la lista de directorios y archivos que tienen que ser monitorizados por AIDE, por ejemplo los archivos de configuración de una aplicación, el directorio de contenidos estáticos de una pagina web, o el directorio donde se guardan los backups, etc. Tras cada una de esas rutas, se añade la lista de aspectos que tiene que ser monitorizados, usando el mismo formato definido en el manual de AIDE

En el siguiente ejemplo se pueden ver algunas de las posibilidades que ofrece AIDE, otra buena fuente son los archivos de configuración en /etc/aide/aide.conf.d/

# Parametros que pueden ser comprobados
#
# p:      permissions
# ftype:  file type
# i:      inode
# n:      number of links
# l:      link name
# u:      user
# g:      group
# s:      size
# b:      block count
# m:      mtime
# a:      atime
# c:      ctime
# S:      check for growing size
# I:      ignore changed filename
# md5:    md5 checksum
# sha1:   sha1 checksum
# sha256: sha256 checksum
# sha512: sha512 checksum
# rmd160: rmd160 checksum
# tiger:  tiger checksum
# haval:  haval checksum
# crc32:  crc32 checksum
# R:      p+ftupe+i+l+n+u+g+s+m+c+md5
# L:      p+ftype+i+l+n+u+g
# E:      Empty group
# >:      Growing logfile p+ftype+l+u+g+i+n+S
# The following are available if you have mhash support enabled:
# gost:   gost checksum
# whirlpool: whirlpool checksum
# The following are available and added to the default groups R, L and >
# only when explicitly enabled using configure:
# acl:    access control list
# selinux SELinux security context
# xattrs:  extended file attributes
# e2fsattrs: file attributes on a second extended file system

# Creamos nuestras reglas.
MinimalCheck = p+i+u+g
FullCheck = p+i+n+u+g+s+b+c+sha256

# Directorios a monitorizar
/home/secnot/private/website MinimalCheck
/home/secnot/chroot FullCheck

# Archivo a monitorizar
# a diferencia de los directorios los archivos son terminados en '$'
# antes de '.' hace falta un caracter de escape '\'
/home/secnot/mi_aplicacion\.conf$       FullCheck

# Usar las reglas no es necesario pero es más legible
/etc/mi_otra_aplicacion\.conf$          p+i+g+d

# Podemos usar las reglas definidas en /etc/aide/aide.conf,
# como en los otros archivos de configuración
/home/webuser/webapp    VarLog

# Forzamos que se ignore un archivo o varios
!/etc/app\.conf$
!/var/log/.*

Por último solo nos queda editar /etc/default/aide, en el cual podemos definir donde deseamos que lleguen los informes generados periódicamente (por defecto root), junto algunas opciones más sobre los mismos.

Uso

Cada vez que realicemos alguna modificación, instalemos, o eliminemos algún programa, generamos una nueva base de datos, a partir de ese momento cada vez que se ejecute AIDE se comprobará que nada ha sido alterado con respecto al estado almacenado en la base de datos.

sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Como medida de seguridad adicional, es recomendable calcular un hash de la base de datos, para poder comprobar manualmente que no ha sido modificada por un atacante. Guarda una copia del hash en un lugar seguro.

sha256sum /var/lib/aide/aide.db

AIDE es ejecutado automáticamente todos los días por cron, a través de un script en /etc/cron.daily/, este ejecuta update-aide.config para generar un archivo de configuración actualizado, y después llama aide. Una vez la comprobación ha terminado, almacena la información en los archivos de log /var/log/aide/aide.log y de errores /var/log/aide/error.log, por último envía un informe a la dirección de correo configurada si es que una existe.

Si queremos comprobar si ha habido alguna modificación manualmente, primero es recomendable comprobar que la base de datos no ha sido modificada usando sha256sum, después podemos ejecutar el script:

sudo /usr/bin/aide.wrapper

O podemos generar manualmente el archivo de configuración, y después ejecutar aide.

sudo update-aide.config
sudo aide -c /var/lib/aide/aide.conf.autogenerated --check

Ver comentarios


Continuamos Seguridad SSH parte I con más trucos para hacer el servicio un poco más seguro. En esta segunda parte tratamos de mejorar la seguridad de las claves, y dificultar la vida de un aracante que consiga acceso.

5. Limitar el acceso ssh a los usuarios

Por defecto todos los usuarios del sistema pueden conectarse usando ssh, pero si no todos los usuarios necesitan acceso ssh, por ejemplo tiene un usuario sólo para acceder por ftp, es posible restringir su acceso en el archivo /etc/ssh/sshd_config

DenyUsers ftpuser1, ftpuser2

o aún más seguro, restringir el acceso a todo los usuarios excepto los especificados:

AllowUsers secnot, juan

6. Desactivar claves vacías

Comprobar que usuarios con claves vacías no puedan hacer login, normalmente esta incluido en la configuración por defecto, pero es mejor comprobarlo en /etc/ssh/sshd_config:

PermitEmptyPasswords no

7. Firewall para el puerto SSH

Si las conexiones a SSH van a ser siempre desde una ip fija, es posible configurar el firewall para que permita conexiones sólo desde esa ip. Esto no es una guía de iptables, pero para acceso exclusivo desde la ip 82.168.100.7, podría ser algo similar a esto:

iptables -A INPUT -i eth0 -p tcp -s 82.168.100.7 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -j DROP
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

antes de modificar iptables asegúrate que sabes lo que haces, porque te puedes quedar sin acceso remoto, si bloqueas el puerto por error.

8. Caducidad de sesiones inactivas

Cuando exista la posibilidad de que usuarios dejen abiertas sesiones ssh en ordenadores inseguros, es recomendable configurar sshd, para que las sesiones se cierren automáticamente tras un periodo de inactividad. En sshd_config añadimos o modificamos:

# Log Out tras 5 minutos
ClientAliveInterval 300
ClientAliveCountMax 0

Esto establece un periodo de 5 minutos (300 segundos). Cuando la sesión de un usuario está inactiva más de este intervalo, es cerrada automáticamente.

9. Fortaleza de las claves

Aunque no relacionado directamente con el servicio ssh, las claves de los usuarios son uno de sus principales puntos débiles, un usuario con una clave débil puede hacer todo el sistema vulnerable, aunque la mejor solución es desactivar login con claves y usar exclusivamente autenticación pública, desgraciadamente esto no es siempre posible, en estos casos se puede paliar el problema obligando a los usuarios a elegir mejores claves.

Pluggable Authentication Modules (PAM) es el encargado de proporcionar autenticación para usuarios y servicios en linux, y nos permite mediante distintos módulos, configurar prácticamente todos los aspectos del proceso. En este caso el modulo que nos interesa esta en /etc/pam.d/common-passwd donde tendremos que editar la linea:

#password       [success=1 default=ignore]      pam_unix.so obscure sha512
password        [success=1 default=ignore]      pam_unix.so obscure sha512 minlen=8

Así forzamos a que las claves sean al menos de 8 caracteres. Si esto no es suficiente, puedes probar el modulo pam_cracklib

secnot@servidor:~$ sudo apt-get install libpam-cracklib

Tras instalar cracklib editamos /etc/pam.d/common-password:

password requisite    pam_cracklib.so    retry=3 minlen=10 difok=3 ucredit=1 lcredit=1 dcredit=1

Esto forzará que las claves sean como mínimo de 10 caracteres, que al menos 3 caracteres cambiaron respecto a la clave anterior, al menos un carácter esté en minúsculas, uno en mayúsculas, y uno sea un número. Se pueden usar políticas mucho más restrictivas usando cracklib, pero llevado al extremo comienza a ser contraproducente, las claves resultantes son demasiado complejas para recordar, y acaban apuntadas en un post-it pegado al monitor.

10. Apparmor

En muchos casos los usuarios no necesitan tener más acceso que a su directorio personal, y siempre es buena política dar a los usuarios exactamente los mínimos privilegios posibles, tradicionalmente restringir el directorio se ha hecho con chroot, pero hoy en día apparmor me parece una solución más limpia y flexible.

Vamos a restringir el usuario juanjo, lo primero será crear una un link del shell bash a jailbash, para poder modificar las opciones de apparmor de forma independiente.

secnot@servidor:~$ sudo ln /bin/bash /usr/local/bin/jailbash

Añadimos jailbash a la lista de shells disponibles en /etc/shells

Y se asigna el nuevo shell al usuario a restringir

secnot@servidor:~$ sudo chsh -s /usr/local/bin/jaiblash juanjo

Tras esto creamos /etc/apparmor.d/usr.local.bin.jailbash que contiene el perfil apparmor para el nuevo shell, incluyo un ejemplo como patrón del contenido, pero es necesario adaptarlo a las necesidades de cada sistema y las restricciones del usuario.

#include <tunables/global>

/usr/local/bin/jailbash {
        #include <abstractions/base>
        #include <abstractions/bash>
        #include <abstractions/consoles>
        #include <abstractions/nameservice>
        #include <abstractions/user-manpages>
        #include <abstractions/user-tmp>

        deny /bin/df r,
        deny /etc/bash_command_not_found r,

        /bin/ r,
        /bin/bash rix,
        /bin/cat rix,
        /bin/chmod rix,
        /bin/chown rix,
        /bin/cp rix,
        /bin/date rix,
        /bin/egrep rix,
        /bin/grep rix,
        /bin/gunzip rix,
        /bin/gzip rix,
        /usr/local/bin/jailbash rix,
        /bin/ln rix,
        /bin/ls rix,
        /bin/mkdir rix,
        /bin/mktemp rix,
        /bin/more rix,
        /bin/mv rix,
        /bin/ping rix,
        /bin/readlink rix,
        /bin/rm rix,
        /bin/rmdir rix,
        /bin/sed rix,
        /bin/sleep rix,
        /bin/tar rix,
        /bin/touch rix,
        /bin/uname rix,
        /bin/vim rix,
        /bin/vim-normal rix,
        /bin/zcat rix,
        /dev/null rw,
        /dev/urandom r,
        /etc/ r,
        /etc/manpath.config r,
        /etc/opt/ r,
        /etc/sysconfig/console r,
        /etc/sysconfig/mail r,
        /etc/sysconfig/news r,
        /etc/vimrc r,

        owner /home/*/ r,
        owner /home/*/** rwl,
        /opt/ r,
        owner /proc/*/cmdline r,
        owner /proc/*/exe r,
        owner /proc/*/mounts r,

        /tmp/** rw,
        /proc/loadavg r,
        /usr/bin/ r,
        /usr/bin/groups rix,
        /usr/bin/lesspipe rix,
        /usr/bin/cut rix,
        /usr/bin/whereis rix,
        /usr/bin/sort rix,
        /usr/bin/basename rix,
        /usr/bin/head rix,
        /usr/bin/id rix,
        /usr/bin/less rix,
        /usr/bin/man rix,
        /usr/bin/manpath rix,
        /usr/bin/mc rix,
        /usr/bin/scp rix,
        /usr/bin/screen rix,
        /usr/bin/ssh rix,
        /usr/bin/ssh-add rix,
        /usr/bin/ssh-agent rix,
        /usr/bin/ssh-copy-id rix,
        /usr/bin/ssh-keygen rix,
        /usr/bin/ssh-keyscan rix,
        /usr/bin/tail rix,
        /usr/bin/tty rix,
        /usr/bin/vim rix,
        /usr/bin/wget rix,
        /usr/bin/which rix,
        /usr/lib*/mc/cons.saver rix,
        /usr/lib*/ssh/ssh-keysign rix,
        /usr/local/bin/ r,
        /usr/share/mc/** r,
        /usr/share/vim/** r,
}

Por último activamos apparmor para jailbash:

secnot@servidor:~$ sudo aa-enforce jailbash
Setting /etc/apparmor.d/usr.local.bin.jailbash to enforce mode.

Ver comentarios


SSH (Secure Shell) es un protocolo de comunicación cifrado, que permite el acceso remoto, y la ejecución remota de comandos. Probablemente sea el único servicio disponible en todo servidor, y aunque el protocolo es seguro, la configuración por defecto no suele ser la más adecuada.

Aparte se usar claves de calidad para los usuarios del servidor, hay muchas pequeñas modificaciones que pueden incrementar sustancialmente la seguridad del servicio.

1. Cambiar el puerto por defecto

Por defecto ssh escucha el puerto 22, de manera que es fácil para cualquier atacante escanear el puerto para determinar si ssh se está ejecutando. Cambiando el puerto se soluciona parcialmente el problema, los escaneos automáticos no encontrarán el puerto, en cambio un atacante interesado específicamente en tu servidor, puede escaneará todos los puertos hasta encontrar ssh.

Aun así este cambio es muy sencillo, nos protege de ataques automáticos, e hipotéticos exploits remotos que puedan aparecer algún día.

Para modificar el puerto sólo es necesario editar /etc/ssh/sshd_config añadiendo o modificando la linea:

# Nuevo puerto ssh
Port 7544

y reiniciar el servicio sshd

secnot@servidor:~$ sudo service sshd restart

para conectar ahora hay que usar

secnot@cliente:~$ ssh servidor -p 7544

2. Desactivar login al root

Acceder como root a cualquier sistema es una mala practica, especialmente en logins remotos, siempre es preferible tener un usuario con permisos sudo para ejecutar comandos como root. Si este es tu caso, es recomendable prohibir el acceso por ssh al usuario root.

El primer paso es asegurarnos que tenemos al menos un usuario con permisos para usar sudo, si no es así nos quedaríamos sin acceso como root al servidor.

secnot@servidor:~$ whoami
secnot
secnot@servidor:~$ sudo whoami
[sudo] password for secnot:
root

Si da algun problema al ejecutar sudo no continuar con este paso. Para modificar la configuracion editamos /etc/ssh/sshd_config:

# Desactivar login para root
PermitRootLogin no

y reiniciamos el servicio

secnot@servidor:~$ sudo service sshd restart

3. Desactivar protocolo 1

SSH puede usar dos protocolos 1 y 2, el protocolo 1 es el más antiguo y fue remplazado por el 2, cuando se descubrieron ciertas vulnerabilidades, pero algunas distribuciones de unix/linux, aún continúan permitiendo usar ambos para mantener compatibilidad hacia atrás. Es recomendable desactivar el protocolo 1, para ello editamos /etc/ssh/sshd_config:

# Protocol 2,1
Protocol 2

y reiniciamos el servicio

4. Usar autenticación de clave Publica

Tiene dos ventajas, la primera es que es posible hacer login sin introducir la clave, y la segunda, es que podremos desactivar completamente el login con claves, haciendo imposibles los ataques por fuerza bruta o diccionario. El primer paso es generar un par del claves publica/privada en el cliente:

secnot@cliente:~$ ssh-keygen -b 4096 -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/secnot/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/secnot/.ssh/id_rsa.
Your public key has been saved in /home/secnot/.ssh/id_rsa.pub.
The key fingerprint is:
0d:d2:94:07:93:a9:dd:b9:33:73:fb:f1:6e:3e:ce:d7 secnot@client
The keys randomart image is:
+--[ RSA 4096]----+
|     ..          |
|      .. .  .    |
|      .oo o. o   |
|     .+o.=. . .  |
|     ..oSo   .   |
|       ooo. .    |
|        E..  .   |
|         . .  .. |
|            ..o. |
+-----------------+

Primero pregunta en que directorio deseas guardar el par de claves, a no ser que tengas otro par y no quieras confusiones, usa el directorio por defecto.

En el segundo paso te pide un passphrase (una clave para proteger el par de claves), si no se la proporcionas cualquiera que consiga acceso al par de claves, tendrá acceso automático al servidor, a cambio no tendrás que introducir una clave cuando hagas login. En cambio si proporcionas un passphrase si que tendrás que introducir una clave para hacer login, pero si el par de claves es robado, no podrán usarlo para acceder al servidor. Tu decisión

Por último queda subir las claves al servidor, para ello hay que añadir el contenido de la clave pública id_rsa.pub al archivo ~/.ssh/authorized_keys de tu usuario en el servidor. Para facilitar la tarea existe la utilidad ssh-copy-id:

secnot@cliente:~$ ssh-copy-id -i .ssh/id_rsa.pub secnot@servidor
secnot@servidor's password:
Now try logging into the machine, with "ssh 'secnot@servidor'", and check in:

~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Si ssh-copy-id no está disponible en tu sistema, puedes hacerlo manualmente, si no existe creamos el directorio .ssh en el servidor

secnot@servidor:~$ mkdir .ssh
secnot@servidor:~$ chmod 700 .ssh

copiamos el archivo de clave publica .ssh/id_rsa.pub al servidor:

secnot@cliente:~$ scp ~/.ssh/id_rsa.pub secnot@servidor:./

añadimos id_rsa.pub a ~/.ssh/authorized_keys, y nos aseguramos que los permisos del archivo sean los correctos

secnot@servidor:~$ cat id_rsa.pub >> ~/.ssh/authorized_keys
secnot@servidor:~$ chmod 600 ~/.ssh/authorized_keys
secnot@servidor:~$ rm id_rsa.pub

Una vez tengas comprobado que todo funciona correctamente, y que puedes hacer login usando ssh, ya sea sin clave o con tu passphrase, puedes dar el ultimo paso, desactivar la autenticación por clave, modificando el archivo /etc/ssh/sshd_config

# Desactivar logins usando claves
PasswordAuthentication no

Por ultimo, asegúrate de guardar una copia de el par de claves id_rsa e id_rsa.pub, si las pierdes no podrás acceder al servidor remotamente.

Seguridad SSH parte II >>

Ver comentarios