Como usar OpenSSH/es

Aus i2pwiki.mk16.de
(Weitergeleitet von Howto SSH/es)
Zur Navigation springen Zur Suche springen

Introducción[Bearbeiten]

SSH (Secure SHell, en español: intérprete de órdenes segura) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red. Permite manejar por completo la computadora mediante un intérprete de comandos, y también puede redirigir el tráfico de X para poder ejecutar programas gráficos si tenemos ejecutando un Servidor X (en sistemas Unix y Windows).

Además de la conexión a otros dispositivos, SSH nos permite copiar datos de forma segura (tanto archivos sueltos como simular sesiones FTP cifradas), gestionar llaves RSA, DSA, ECDSA (y otras) para no escribir claves al conectar a los dispositivos y pasar los datos de cualquier otra aplicación por un canal seguro tunelizado mediante SSH.

En el presente manual se usara basicamente el sistema de cifrado Ed25519, pues son las mas seguras disponibles en las versiones mas recientes de OpenSSH. En dispositivos mas simples, como raspberry puede suceder que se tenga acceso solo a RSA.


Instalación de Open Secure SHell (OpenSSH)[Bearbeiten]

En sistemas windows, se debe buscar el paquete PUTTY e instalar.

En sistemas Linux derivados de Debian, basta con ejecutar en una terminal:

$ sudo apt-get install openssh

o

$ sudo apt-get install openssh-client openssh-server


Uso Básico de Secure SHell[Bearbeiten]

El uso más sencillo del cliente ssh es:

$ ssh servidor

Esto nos abre una sesión remota interactiva con servidor.

Estamos dando por supuesto que el usuario del equipo remoto tiene el mismo nombre que nuestro usuario local y que el servidor ssh está escuchando en el puerto estándar (22).

Para indicar el usuario del servidor hacemos:

$ ssh usuario@servidor

Algunos parámetros útiles:

-p puerto
   Indica el puerto del servidor ssh al que conectarse (puerto)
-i fichero
   utiliza el fichero de claves fichero para autenticar la
   conexión, en vez de usuario/password (ver Confianza ssh)
-X
   Indica que queremos utilizar nuestro servidor X para las
   aplicaciones gráficas (ver Túneles SSH)
-L puerto_local:maquina3:puerto_maquina3
   Realiza un túnel entre puerto_local y maquina3:puerto_maquina3
   (ver Túneles SSH)
-R puerto_remoto:maquina3:puerto_maquina3
   Realiza un túnel entre servidor:puerto y maquina3:puerto_maquina3
   (ver Túneles SSH)
-N
   Sin conexión interactiva (útil en Túneles SSH)
-f
   En segundo plano (útil en Túneles SSH). Al acabar puede usarse,
   por ejemplo $ killall ssh

En el siguiente ejemplo se usan ficheros de claves, un puerto no estándar, un usuario diferente del local y varios túneles:

$ ssh usuario@servidor -p 10022 -i .ssh/id_dsa -X -L 18070:localhost:8070 -L 5555:localhost:5901


Servidor Open Secure SHell[Bearbeiten]

A continuacion varios consejos de seguridad (opcionales) que nos pueden evitar varios dolores de cabeza al momento de trabajar con OpenSSH.


Configuración del servidor SSH[Bearbeiten]

Una vez instalado con:

$ aptitude install openssh-server

Para mayor seguridad cambiamos el puerto, reducimos el tiempo de login y no permitimos conexiones de root

$ nano /etc/ssh/sshd_config
Port xxxx
LoginGraceTime 45
PermitRootLogin no

Tambien puede ser de mucha ayuda comentar las siguientes lineas

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Para que queden asi (en caso de que ED25519 no se encuentre, dejamos solo RSA sin comentar)

# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Y de esta manera solo aceptar ED25519, el protocolo de cifrado mas seguro que existe.


Restricción de usuarios y/o IP[Bearbeiten]

Solo permitimos acceder por ssh a los usuarios indicados en el fichero /etc/loginusers

$ nano /etc/pam.d/sshd
  #auth       required     pam_env.so # [1]
  auth        required     pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers

Creamos el fichero /etc/loginusers con los usuarios autorizados:

$ nano /etc/loginusers
  mi_usuer_ssh

En ocasiones puede ser muy util poder reducir el acceso por SSH y permitirlo solo a maquinas de la LAN:

$ nano /etc/hosts.allow
  sshd: 192.168.1.0/24

De esta manera solo las maquinas locales pueden acceder via SSH.


Denegación de uso de usuario/password[Bearbeiten]

Es posible conectarse al servidor ssh desde otra maquina utilizando login y contraseña ($ ssh usuario@maquina -p xxxx) o usando ficheros de clave pública/privada ($ ssh usuario@maquina -p xxxx -i id_dsa_copiada).

Para permitir solo el uso de certificados (recomendado) reconfiguramos sshd desautorizando las autentificaciones por contraseña

$ nano /etc/ssh/sshd_config
...
PasswordAuthentication no

Reiniciamos el servicio

$ /etc/init.d/ssh restart


Confianza Secure SHell[Bearbeiten]

Vamos a ver como hacer que el usuario de una máquina con servidor SSH (“servidor”) confíe en unas claves SSH. De esta manera podemos acceder al equipo sin necesidad de utilizar un usuario/password del servidor.

Si además los ficheros de claves ssh no tienen “passphrase” las conexiones ssh (ssh, scp…) se realizarán sin preguntar nada al usuario. Esto es cómodo pero altamente peligroso y desaconsejado.

Lo que se recomienda es no permitir acceso clave/usuario al servidor sino solo por ficheros ssh y que éstos tengan clave (passphrase). De esta forma para acceder al equipo hace falta disponer de algo (fichero de claves) y conocer algo (passphrase).

Notas

  • La confianza la establece un usuario concreto del equipo “servidor”.
  • El servidor debe estar configurado para aceptar confianzas (por omisión lo está).
  • Recordemos que la clave pública (id_dsa.pub), no hace falta protegerla, es pública y puede transmitirse en claro si es necesario.
  • Recordemos que la clave privada (id_dsa) es fundamental protegerla, es privada y solo debe transmitirse por medios seguros. éste es el fichero que tendremos que llevar con nosotros para conectar con el servidor y que deberemos proteger con la passphrase.
  • Si se accede a diferentes servidores los ficheros de clave privada pueden renombrarse libremente, por ejemplo como id_dsa-servidor.
  • Un mismo usuario de un mismo servidor puede disponer de diferentes pares de claves
  • Una confianza (par de claves) puede configurarse para incluir limitaciones


Configuración[Bearbeiten]

Primero generamos las claves ssh (esto se puede hacer desde cualquier equipo):

$ ssh-keygen -t ed25519 #En caso de NO tener soporte para ed25519, usar rsa

Esto generará una llave privada (id_ed25519) y otra pública (id_ed25519.pub).

Después se debe copiar la llave al servidor (con ayuda de una unidad USB o similar) y la autorizamos.

$ cat .ssh/id_ed25519.pub >> .ssh/authorized_keys

(Este procedimiento tambien sera usada para todos los certificados o llaves de otras maquinas/usuarios).

Como alternativa, tambien se puede (de forma local en una LAN) usar

$ ssh-copy -p puerto_servidor -c blowfish -C -l nuestro_usuario -q ip_servidor
# esto permite a la vez enviar y autorizar nuestras llaves.

Para enviar directamente al servidor a traves del propio OpenSSH, la llave publica y solo en caso de haber levantado las restricciones de acceso para realizar esta unica operacion.

Por ultimo se ajustan los permisos de los archivos locales de OpenSSH:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/*
$ chmod g-w ~/

Para mejorar aun mas la seguridad, es recomendable guardar nuestras llaves privada y publica en una unidad USB. De esta manera al momento de conectarnos al servidor se hace:

$ ssh -p puerto_servidor -c blowfish -C -l nuestro_usuario -q -i /mnt/unidad_usb/llave_privada ip_servidor

Opcionalmente se pueden incluir opciones en la clave autorizada, como command=command, no-pty, no-port-forwarding… (man sshd).

Es importante intercambiar certificados entre equipos, ya sea con ayuda de un dispositivo fisico (como USB) o con ayuda del propio OpenSSH, en una terminal.

  • Enviamos el certificado y lo autorizamos desde el cliente al servidor (desaconsejado y mejor usar una unidad USB)
$ scp .ssh/id_ed25519.pub admin@maquina1.servidor:/home/servidor_user
$ cat .ssh/id_ed25519.pub >> .ssh/authorized_keys
  • Enviamos el certificado y lo autorizamos desde el servidor al cliente (desaconsejado y mejor usar una unidad USB)
$ scp .ssh/id_ed25519.pub cliente@maquina1.cliente:/home/cliente_user
$ cat .ssh/id_ed25519.pub >> .ssh/authorized_keys

Y con esto ya estamos listos para trabajar sin necesitar claves entre las maquinas.


Uso[Bearbeiten]

Para cambiar (o des/asignar) una passphrase, de un fichero de claves, hacemos:

$ ssh-keygen -p -f .ssh/id_ed25519
{!} Se recomienda cambiar la passphrase (clave) regularmente.

Desde cualquier equipo si se dispone de la clave privada (id_ed25519) de puede acceder al servidor mediante:

$ ssh servidor -i id_ed25519

También puede utilizarse toda la potencia de ssh, por ejemplo:

$ ssh usuario@servidor -p x -N -f -i id_ed25519 -L 5901:localhost:5901


Túneles SSH[Bearbeiten]

Podemos usar SSH para generar túneles seguros. Estos túneles ssh establecen una conexión cifrada entre un puerto de nuestra máquina local y otro puerto accesible desde la máquina remota, generalmente un puerto local de la máquina remota, pero no necesariamente.

Puede ver como configurar un servidor ssh [Configuración de ssh], de confianza ssh, usos básicos de ssh [Uso de ssh] y scp [Uso de scp].


Túnel directo[Bearbeiten]

Si queremos conectar con un servidor MySQL de una maquina remota “servidor” sin usar ssh conectaremos con nuestro cliente de base de datos al puerto 3306 del servidor. El problema es que toda la comunicación es insegura y viaja en claro.

Si “servidor” dispone de ssh podemos generar un túnel ssh para proteger la comunicación. Lo que hacemos es “conectar” un puerto de nuestra máquina local, por ejemplo 13306 con el puerto 3306 de “servidor”. Después conectamos nuestro cliente de base de datos al puerto local 13306 y ssh se encargará de comunicar con “servidor” de manera segura.

Para hacer este primer túnel sencillo hacemos:

$ ssh servidor -L 13306:localhost:3306
Acceso Remoto a I2P/Tor/Freenet

Si queremos usar privoxy + i2p + tor + freenet tambien en otras maquinas
remotamente se puede usar OpenSSH

$ ssh -Nf user@host-con-privoxy -L 8112:127.0.0.1:8112

Y asi podemos acceder localmente desde nuestro navegador, apuntando
nuestro proxy a 127.0.0.1:8112


Esto indica que el puerto 13306 de la máquina local (cliente) se dirige al puerto que servidor conoce como “localhost:3306″; esto es el puerto local 13306 apunta al puerto 3306 de “servidor”.

También podemos complicar un poco el comando ssh para usar ficheros de llaves<ref>http://guimi.net/blogs/hiparco/confianza-ssh/</ref> que es lo recomendado, mediante -i; para indicar el usuario de la máquina “servidor” si no coincide con el usuario de la máquina local; para indicar el puerto ssh del servidor (si no utiliza el puerto por omisión: 22).

Esta vez generaremos un túnel para el puerto 5432 (el puerto habitual de PostgreSQL) desde el puerto local 5555:

$ ssh usuario@servidor -p x -i id_ed25519_copiada -L 5555:localhost:5432

El puerto 5555 de la máquina local (cliente) se dirige al puerto que servidor conoce como localhost:5432; esto es el puerto local 5555 apunta al puerto 5432 de “servidor”.


Túnel a una tercera máquina[Bearbeiten]

Supongamos que “servidor-ssh” y “servidor-svn” son dos máquinas de una red local. Uno tiene ssh y otro svn. Nos interesa desde Internet conectar de forma segura al servidor de svn:

$ ssh servidor-ssh -L 3690:servidor-svn:13690

El puerto 3690 de la máquina local (cliente) se dirige al puerto que servidor-ssh conoce como “servidor-svn:5432″; esto es el puerto local 5555 apunta al puerto 5432 de la máquina que servidor-ssh conoce como “servidor-svn”. Es importante remarcar que el nombre “servidor-svn” lo resuelve “servidor-ssh”, no nuestro cliente local, por tanto puede ser la IP de la red local o un nombre que sea capaz de resolver “servidor-ssh”.

Con esto establecemos una conexión segura hasta “servidor-ssh” que a su vez conecta en claro (por la red local) con “servidor-svn”. De esta forma si utilizamos un cliente SVN para conectar con el puerto local 13690, la información estará viajando protegida por el túnel ssh hasta “servidor-ssh” y después en claro hasta “servidor-svn”.

Esto permite que “servidor-svn” no tenga ninguna conexión directa con el exterior y esté más protegido.


Túnel inverso[Bearbeiten]

Aunque menos utilizado puede interesarnos que un puerto del equipo “servidor-ssh” se redirija a un puerto a través de nuestra máquina local:

$ ssh servidor -R 13690:localhost:3690

De esta manera todas las conexiones al puerto 13690 de “servidor” será redirigidas al puerto “localhost:3690″ de la máquina local. También se puede hacer por tanto:

$ ssh servidor -R 13690:otra-maquina:3690

El puerto 13690 de la máquina “servidor” se dirige al puerto que nuestra máquina local conoce como “otra-maquina:3690″; esto es el puerto servidor:13690 apunta al puerto que nuestra máquina local conoce como “otra-maquina:3690″. Es importante remarcar que el nombre “otra-maquina” lo resuelve nuestra máquina local.


Túnel no interactivo[Bearbeiten]

Podemos usar la opción -N para que no se abra una conexión interactiva (una consola remota) y podemos usar -f para que el cliente ssh pase a en segundo plano. De esta forma si solo queremos hacer el túnel es más cómodo. Por ejemplo para habilitar un túnel a un servidor de OpenERP:

$ ssh servidor -N -f -L 18070:localhost:8070


Túnel de las X (servidor gráfico)[Bearbeiten]

Aquí trataremos algo totalmente diferente a todo lo anterior. En principio, cuando abrimos una terminal remota mediante ssh “solo” podemos utilizar comandos sin GUI y no aplicaciones gráficas. Podemos pedirle a ssh que para la sesión abierta utilice nuestras X locales (si las tenemos, claro) como servidor gráfico. Así podemos lanzar comandos con GUI, es decir aplicaciones gráficas, que se ejecutarán en el servidor pero las veremos en nuestra máquina local.

$ ssh servidor -X


Varios túneles a la vez[Bearbeiten]

Pueden generarse varios túneles a la vez, por ejemplo:

$ ssh servidor -X -L 18070:localhost:8070 -L 5555:localhost:5901

O con ficheros de claves, puerto no estándar y usuario diferente del local:

$ ssh usuario@servidor -p 10022 -i .ssh/id_ed25519 -X -L 18070:localhost:8070 -L 5555:localhost:5901


Véase También[Bearbeiten]


Referencias[Bearbeiten]

<references />