Comando ssh en Linux: Cómo Conectar, Usar Claves y Crear Túneles de Puertos

El paquete OpenSSH ofrece servicio de acceso remoto a computadoras con Linux de forma segura con conexión encriptada punto a punto a través del comando ssh en Linux.

Utiliza el protocolo ssh (secure shell) para permitir la transferencia de archivos y shell seguro.

Fue creado para reemplazar los servidores de conexión que transfieren datos sin encriptación como telnet, rsh y rlogin. La versión de código abierto gratuito puede obtenerse en el sitio http://www.openssh.org o instalada directamente como paquete en la mayoría de las distribuciones.

OpenSSH cuenta con portabilidad para diversos sistemas como Linux, Solaris, FreeBSD, NetBSD, AIX, IRIX, HP-UX y OpenBSD.

La instalación de OpenSSH es simple y puede realizarse a través de paquetes con apt-get en Debian o yum en Red Hat.

La encriptación de OpenSSH utiliza el concepto de par de claves públicas y privadas.

Algoritmos de Encriptación

OpenSSH soporta varios algoritmos de firma para claves de autenticación que pueden dividirse en dos grupos, dependiendo de las propiedades matemáticas que explotan:

• DSA y RSA, que dependen de la dificultad práctica de factorar el producto de dos grandes números primos;
• ECDSA y Ed25519, que dependen del problema del logaritmo discreto de la curva elíptica.

Los algoritmos de encriptación de curva elíptica (ECC) son una adición más reciente a los sistemas de encriptación de clave pública. Una de sus principales ventajas es la capacidad de proporcionar el mismo nivel de seguridad con claves más pequeñas, lo que hace las operaciones menos computacionalmente intensivas (es decir, creación de claves más rápidas, encriptación y desencriptación también.

Configuración del cliente OpenSSH 2

Para cada usuario, ssh también crea sus pares de claves, que residen en el subdirectorio ".ssh" del directorio HOME del usuario. En cualquier momento, el usuario puede crear sus pares de clave con el comando ssh-keygen:

$ ssh-keygen Generating public/private rsa key pair.Enter file in which to save the key (/home/uiraribeiro/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Your identification has been saved in /home/uiraribeiro/.ssh/id_rsa.Your public key has been saved in /home/uiraribeiro/.ssh/id_rsa.pub.The key fingerprint is:SHA256:7p177xnRUY0HDcrdUbDCQg uiraribeiro@Notebook-do-UiraThe key's randomart image is:+---[RSA 2048]----+|     E==o=+=o .. ||       =+ =o.=.oo||        = +o oo  |+----[SHA256]-----+

El ssh-keygen puede crear los siguientes pares de claves con diferentes algoritmos de encriptación:

• Clave privada DSA:  ~/.ssh/id_dsa (DSA);
• Clave pública DSA: ~/.ssh/id_dsa.pub (DSA);
• Clave privada ECDSA: ~/.ssh/id_ecdsa (ECDSA);
• Clave pública ECDSA: ~/.ssh/id_ecdsa.pub (ECDSA);
• Clave privada Ed25519: ~/.ssh/id_ed25519 (Ed25519);
• Clave pública Ed25519: ~/.ssh/id_ed25519.pub (Ed25519);
• Clave privada RSA: ~/.ssh/id_rsa (RSA);
• Clave pública RSA: ~/.ssh/id_rsa.pub (RSA)

Autenticación sin contraseña

El usuario puede, si lo desea, copiar su clave pública al directorio HOME del usuario que utiliza para conectarse en la máquina remota en el archivo  ~/.ssh/authorized_keys. Así, no necesitará más proporcionar la contraseña para una conexión remota con ese determinado host y usuario.

Archivo /etc/ssh_config

El cliente ssh mantiene un archivo /etc/ssh/ssh_config para las configuraciones del cliente SSH. Entre ellas se destacan:

Protocol            2    # permite que somente o SSH2 seja usadoPort                22   # altera a porta padrão do SSH de 22 para outraForwardX11Trusted   no   # não permite login remote via X11

Conexión Remota usando SSH

Cuando se realiza una conexión a un servidor SSH, hay un intercambio de claves públicas entre el cliente ssh y el servidor sshd.

Entonces cuando el servidor desea enviar algo al cliente, utiliza la clave pública del cliente para encriptar los datos para él. Solo la clave privada del cliente es capaz de desencriptar lo que fue encriptado con su clave pública.

Lo mismo sucede cuando el cliente quiere enviar algo al servidor. Utiliza la clave pública del servidor para encriptar algo para él. De esta forma solo la clave privada del servidor es capaz de leer su contenido.

Para conectarse a un host usando ssh, el comando sigue el patrón:

$ ssh nomedousuario@enderecodohost

Y para hacer conexión con protocolo X11, se usa la opción "-X" o "-Y":

$ ssh -X [email protected]

El ssh intercambia automáticamente las claves públicas del usuario local con las claves del usuario remoto, de forma transparente.

También es posible ejecutar remotamente un comando en el host de destino usando ssh:

$ ssh [email protected] svn /var/www/html

En este ejemplo, ssh realizará la autenticación y ejecutará el comando "svn /var/www/html" en el servidor remoto.

El ssh permite especificar un puerto de conexión, cuando el puerto 22 no es el puerto estándar del servidor remoto:

$ ssh -p 2222 [email protected]

La opción "-p" permite especificar el puerto.

ssh_know_hosts

El archivo /etc/ssh/ssh_known_hosts o ~/.ssh/known_hosts es consultado cuando el método de acceso utilizado está basado en la autenticación RSA. Este archivo contiene las claves públicas de una máquina para que la conexión sea exitosa.

Tan pronto como se establece una conexión por primera vez, ssh graba un hash del servidor en el archivo ~/.ssh/know_hosts. En las siguientes conexiones ese hash es comparado con el recibido por el servidor y del archivo know_hosts.

Si por algún motivo el servidor es alterado, la comparación fallará, SSH no se conectará y emitirá una alerta, diciendo que el servidor es posiblemente otra máquina y no aquella conocida.

Cuando hay necesidad de reemplazo del servidor, el cliente ssh debe remover la línea correspondiente al servidor en el archivo ~/.ssh/know_hosts.

OpenSSH Server

El servicio que provee conexión remota usando SSH del paquete OpenSSH es sshd. Este servicio se ejecuta generalmente a través del gestor de servicios Systemd.

En el momento de la instalación de OpenSSH Server, se creará una clave pública y una clave privada de su host. En la versión 2 de SSH, se crean los siguientes archivos:

/etc/ssh/ssh_host_rsa_key (clave privada RSA)
/etc/ssh/ssh_host_rsa_key.pub (clave pública RSA)
/etc/ssh/ssh_host_dsa_key (clave privada DSA)
/etc/ssh/ssh_host_dsa_key.pub (clave pública DSA)
/etc/ssh/ssh_host_ecdsa_key (clave privada ECDSA)
/etc/ssh/ssh_host_ecdsa_key.pub (clave pública ECDSA)
/etc/ssh/ssh_host_ed25519_key (clave privada Ed25519)
/etc/ssh/ssh_host_ed25519_key.pub (clave pública Ed25519)

Estas claves no deben ser alteradas, ya que son las claves de encriptación de su host. Si alguna de estas claves es alterada, las máquinas a las que se conectó ya no aceptarán una conexión suya, ya que entenderán que alguien está haciéndose pasar por usted.

sshd_config

El archivo de configuración principal de sshd es /etc/ssh/sshd_config. Es importante que este archivo tenga permiso de lectura y escritura solamente para el superusuario, ya que contiene información sensible, como permitir el ingreso del root o solo una lista de usuarios.

El archivo sshd_config es muy rico en posibilidades de configuraciones.

Las siguientes informações son relevantes en la configuración del sshd:

Protocol        2            # permite que somente o SSH2 seja usadoPort            4999         # altera a porta padrão do SSH de 22 para outraForwardX11      no           # não permite login remote via X11PermitRootLogin no           # não permite que o root entre remotamenteMaxAuthTries    2            # define o número máximo de tentativas de erroAllowUsers      tom jerry    # define quais logins são permitidos via ssh

Generalmente, por cuestiones de seguridad, no es común permitir que el root tenga acceso directo al ssh, de esta forma el administrador debe iniciar sesión con otra cuenta con privilegios normales y en los comandos que requieran super-usuario utilizar el sudo.

Habilitar el sshd

Para iniciar el servicio de ssh servidor:

$ systemctl start sshd

Para habilitar el servicio en la carga del sistema operativo:

$ systemctl enable sshd

ssh-agent e ssh-add

Las aplicaciones ssh-agent y ssh-add pueden ser utilizadas para controlar la conexión ssh, de forma que el usuario no necesite escribir su contraseña de autenticación en la máquina destino en cada conexión.

Es necesario que la máquina destino tenga una copia de la clave pública del usuario en la carpeta home/.ssh del usuario destino en la máquina destino:

# scp /root/.ssh2/hostkeys/key.pub root@server:/root/.ssh

El comando "scp" hace una copia segura de la clave pública creada con ssh-keygen para el directorio "/root/.ssh" de la máquina destino. 

Hecho esto, el comando "ssh-agent" muestra cuáles son las variables ambientales que necesitan ser creadas y cuál es el PID del proceso del agente SSH que controlará la conexión:

# ssh-agentSSH_AUTH_SOCK=/tmp/ssh-lqMuRR398/agent.398; export SSH_AUTH_SOCK;SSH_AGENT_PID=399; export SSH_AGENT_PID;

Copie y pegue en el shell el texto que ssh-agent mostró:

# SSH_AUTH_SOCK=/tmp/ssh-lqMuRR398/agent.398; export SSH_AUTH_SOCK;# SSH_AGENT_PID=399; export SSH_AGENT_PID;

Después de eso, es necesario ejecutar "ssh-add" y escribir la "pass­phrase" que fue ingresada al momento de la creación de las claves:

# ssh-addEnter passphrase:

De esta forma, cuando vayas a hacer una conexión segura con la "máquinadestino", ssh no preguntará tu contraseña.

# ssh root@maquinadestino

Otra forma de hacer esto es copiar el contenido de la clave pública id_rsa.pub de la máquina cliente al archivo ~/.ssh/authorized_keys de la máquina servidora. De esta forma cuando el cliente necesite iniciar sesión en la máquina servidora, no será exigida contraseña.

ssh-copy-id

El programa ssh-copy-id puede ser usado para hacer la copia de la clave pública a la máquina remota de forma segura y rápida. Él hace la copia de la clave pública del usuario al servidor remoto en ~/.ssh/authorized_keys.

$ ssh-copy-id [email protected]/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
/home/uiraribeiro/.ssh/[email protected]'s password: Number of key(s) added:        1Now try logging into the machine, with:   "ssh '[email protected]'"and check to make sure that only the key(s) you wanted were added.

Personalmente, no me gusta usar este método de acceso sin pedir contraseña. Una vez que tu máquina esté vulnerable, todas las máquinas en que usas regularmente el acceso ssh vía claves también estará comprometida.

Haciendo el SSHD más Seguro

Cambiar el puerto del SSH

Uno de los trucos para hacer el ssh más seguro es cambiar el puerto predeterminado de conexión del servicio de ssh.

Esto puede ser hecho alterando el archivo /etc/ssh/sshd_config, alterando la directriz "Port". Generalmente esta línea estará comentada con "#". Es necesario descomentar y cambiar el puerto de 22 para otro arriba de 1024:

Port 2323

No permitir inicio de sesión con el Root

También es interesante deshabilitar el acceso del super-usuario root en el ssh, permitiendo así que solamente usuarios comunes hagan inicio de sesión remoto.

Esto puede ser hecho alterando el archivo /etc/ssh/sshd_config, en la directriz "PermitRootLogin", que deberá estar descomentada y con valor igual a "no":

PermitRootLogin no

Después de cualquier alteración en el archivo sshd_config, es necesario reiniciar el servicio de ssh:

# systemctl restart sshd

Uso de Tcpwrapper

Una técnica antigua en Linux para limitar el acceso a un determinado servicio es el uso del tcpwrapper.

El tcpwrapper funciona como un portero que intercepta una conexión y verifica si determinado servicio puede ser accedido por un cliente. De esta forma es posible limitar cuáles direcciones IP de clientes podían acceder a determinado servicio.

Los programas en Linux que hacen uso del tcpwrapper usan la biblioteca libwrap.so.

Para determinar si un programa hace uso del tcpwrapper, puede consultarse qué bibliotecas él utiliza con el programa ldd:

$ ldd /usr/sbin/sshd | grep wrap     libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0

En este caso, es posible verificar que el programa sshd, utiliza la biblioteca libwrap, y por lo tanto, es capaz de limitar cuáles son los hosts que pueden acceder al shell seguro.

Para limitar cuáles hosts clientes pueden acceder a cuál servicio, el tcpwrapper consulta los archivos /etc/hosts.allow y /etc/hosts.deny para saber cuáles direcciones IP pueden acceder a cuál servicio.

hosts.allow y hosts.deny

Los archivos /etc/hosts.allow  y /etc/hosts.deny son utilizados para definir reglas de acceso a los servicios ofrecidos por la computadora.

El contenido de los archivos hosts.allow y hosts.deny siguen el siguiente formato:

nombre_del_servicio: dirección_ip

Hay una lógica y un orden establecido:

Cuando una conexión es establecida, el tcpwrapper lee primero el contenido del archivo /etc/hosts.allow. Si existe una regla para esta conexión él no verifica el archivo hosts.deny. 

$ cat /etc/hosts.allow sshd: 10.10.100.1

Si ninguna regla es encontrada en hosts.allow, él lee el /etc/hosts.deny en busca de una regla. Si es encontrado algo que coincida en hosts.deny, él termina la conexión. Si nada que coincida es encontrado, él libera el acceso.

Si deseas que solamente las conexiones explícitamente liberadas en el archivo hosts.allow sean permitidas, negando cualquier otro cliente no declarado, la regla "ALL:ALL" puede ser colocada en el archivo /etc/hosts.deny para que solamente las conexiones explícitamente definidas por las reglas en hosts.allow sean aceptadas.

Otra combinación posible en el hosts.deny es negar todo por servicio con la regla "sshd:all". Algunas distribuciones cambian la palabra "all" por "paranoid".

Las direcciones IP declaradas en los archivos hosts.allow y hosts.deny pueden ser tanto en la versión IPv4 como en IPv6. Más de una dirección debe separarse por comas:

sshd: 192.168.0.10, 192.168.0.15

También se puede declarar una dirección de una máquina:

sshd: uira.certificacaolinux.com.br

También es posible liberar por subred:

sshd: 192.168.0.0/255.255.255.0

El tcpwrapper también acepta una combinación parcial, si la línea termina con un ".":

sshd: 192.168.0.

En este caso, todas las direcciones que comienzan con "192.168.0" estarán incluidas.

La restricción de qué clientes pueden conectarse a un determinado servicio es una tarea que hoy se delega al uso de un buen Firewall. Sin embargo, tcpwrappers ofrece una capa más de seguridad, ya que si el firewall falla, aún queda el tcpwrapper para garantizar alguna protección adicional.

Aprende mucho más sobre Linux en nuestro curso en línea. Puedes realizar la inscripción aquí. Si ya tienes una cuenta, o quieres crear una, simplemente ingresa o crea tu usuario aquí.

¿Te gustó? Comparte