12.5. Configurando el Registro y Ejecución Remotos

12.5.2.1. El Demonio ssh

El demonio sshd es el programa que escucha conexiones de red desde clientes ssh, gestiona la autentificación, y ejecuta las órdenes requeridas por el cliente. Hay un fichero de configuración principal llamado /etc/ssh/sshd_config y un fichero especial que contiene una clave usada por los procesos de autentificación y encriptación para representar la parte del host. Cada host y cada cliente tienen su propia clave.

Una utilidad llamada ssh-keygen se proporciona para generar un clave aleatoria. Esto comúnmente se usa una vez en la instalación para generar la clave del host, la cual el administrador de sistema guarda en un fichero llamado /etc/ssh/ssh_host_key. Las claves pueden ser de cualquier longitud de 512 bits o mayores. Por omisión, ssh-keygen genera claves de 1024 bits de longitud, y la mayoría de la gente usa lo predeterminado. Para generar una clave aleatoria, debe invocar la orden ssh-keygen así:

# ssh-keygen -f /etc/ssh/ssh_host_key

Se le pedirá que introduzaca una frase de paso. Sin embargo, las claves host no deben usar frase de paso, en este caso pulse la tecla return para dejarla en blanco. La salida del programa será algo así:

Generating RSA keys: ......oooooO...............................oooooO Key generation complete. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /etc/ssh/ssh_host_key Your public key has been saved in /etc/ssh/ssh_host_key.pub The key fingerprint is: 1024 3a:14:78:8e:5a:a3:6b:bc:b0:69:10:23:b7:d8:56:82 root@moria

Puede encontrar al final que los dos ficheros han sido creados. El primero se llama la clave privada, el cual debe mantenerse en secreto y estará en /etc/ssh/ssh_host_key. El segundo se llama la clave pública y es el que puede compartir; estará en /etc/ssh/ssh_host_key.pub.

Armados con las claves para la comunicación ssh, necesita crear un fichero de configuración. las órdenes ssh son muy potentes y el fichero de configuración puede contener muchas opciones. Expondremos un ejemplo sencillo para que empiece; debe dirigirse a la documentación de ssh para activar otras características. El siguiente código muestra un fichero de configuración seguro y mínimo de sshd . El resto de las opciones de configuración se detallan en las páginas del manual de sshd (8) :

    # /etc/ssh/sshd_config
    #
    
    # Las direcciones IP que escuchan conexiones entrantes. 0.0.0.0 significa todas las
    # direcciones locales
    ListenAddress 0.0.0.0
    
    # El puerto TCP que escucha conexiones entrantes. Por omisión el 22.
    Port 22
    
    # El nombre del fichero clave del host.
    HostKey /etc/ssh/ssh_host_key
    
    # La longitud de la clave en bits.
    ServerKeyBits 1024
    
    # ¿Debemos permitir registros (login) del root por ssh?
    PermitRootLogin no
    
    # ¿Debe el demonio ssh verificar que el directorio inicial (home) del usuario y los permisos de fichero
    # sean seguros antes de permitir el registro (login)?
    StrictModes yes
    
    # ¿Debemos permitir el método antiguo de autentificación  ~/.rhosts y /etc/hosts.equiv?
    RhostsAuthentication no
    # ¿Debemos permitir autenticación pura RSA?
    RSAAuthentication yes
    # ¿Debemos permitir autenticación por contraseña?
    PasswordAuthentication yes
    
    # ¿Debemos permitir /etc/hosts.equiv combinado con autentificación host por RSA?
    RhostsRSAAuthentication no
    # ¿Ignorar los ficheros ~/.rhosts?
    IgnoreRhosts yes
    # ¿Permitimos registros (logins) a cuentas con contraseñas vacías?
    PermitEmptyPasswords no

Es importante estar seguro de que los permisos de los ficheros de configuración son correctos para asegurar que se mantiene el sistema de seguridad. Use las siguientes órdenes:

# chown -R root:root /etc/ssh # chmod 755 /etc/ssh # chmod 600 /etc/ssh/ssh_host_key # chmod 644 /etc/ssh/ssh_host_key.pub # chmod 644 /etc/ssh/sshd_config

La etapa final de la administración del demonio sshd es ejecutarlo. Normalmente necesitará crear un fichero rc para ello o añadirlo a uno existente, de este modo se ejecutará automáticamente en el arranque. El demonio corre solo y no necesita ninguna entrada en el fichero /etc/inetd.conf . El demonio debe correr como usuario root . La sintaxis es simple:

/usr/sbin/sshd

El demonio sshd automáticamente se ejecutará en segundo plano. Ahora esta listo para aceptar conexiones ssh.

12.5.2.2. El cliente ssh

Existen variedad de programas clientes ssh: slogin, scp y ssh. Cada uno lee el mismo fichero de configuración, normalmente llamado /etc/ssh/ssh_config. Cada uno de ellos también lee ficheros de configuración desde el directorio .ssh en el directorio inicial (home) del usuario que lo esté ejecutando. El más importante de estos ficheros es el .ssh/config, el cual puede contener opciones que sustituirán a las especificadas en el fichero /etc/ssh/ssh_config, el fichero .ssh/identity, el cual contiene la propia clave privada del usuario, y el correspondiente fichero .ssh/identity.pub, conteniendo la clave pública propia del usuario. Otros ficheros importantes son .ssh/known_hosts y .ssh/authorized_keys; hablaremos de ellos después en Sección 12.5.2.3.” Primero, vamos a crear el fichero de configuración global y el fichero de claves de usuario.

El fichero /etc/ssh/ssh_config es muy similar al de configuración del servidor. Otra vez, tenemos muchas características que usted puede configurar, pero una configuración minima puede ser como la expuesta en Ejemplo 12-5. El resto de las opciones de configuración están detalladas en la página de manual sshd(8). Puede añadir secciones que coincidan con hosts específicos o grupos de hosts. El parámetro a la declaración “Host” puede ser cualquiera de los nombres completos de un host o una especificación de carácter comodín, como hemos usado en nuestro ejemplo, para que coincidan todos los hosts. Podemos crear una entrada que usada, por ejemplo, Host *.vbrew.com haga coincidir cualquier host en el dominio vbrew.com.

    # /etc/ssh/ssh_config
    
    # Opciones predeterminads a usar cuando se conecte a un host remoto
    Host *
      # ¿Comprimir los datos de sesión?
      Compression yes
      # .. usando qué nivel de compresión? (1 - rápida/escasa, 9 - lenta/mucha)
      CompressionLevel 6
    
      # ¿Usar  rsh si la conexión segura falla?
      FallBackToRsh no
    
      # ¿Debemos mandar mensajes para mantener la conexión (keep-alive)? Util si se usa enmascaramiento IP
      KeepAlive yes
    
      # ¿Intentar autentificación RSA?
      RSAAuthentication yes
      # ¿Intentar autentificación RSA en combinación con autentificación .rhosts?
      RhostsRSAAuthentication yes

Mencionamos en la sección de configuración de servidor que cada host y cada usario tiene una clave. La clave de usuario se guarda en su fichero ~/.ssh/indentity . Para generar la clave, se usa la misma orden ssh-keygen que usamos para generar la clave de host, excepto que esta vez no necesita especificar el nombre del fichero donde usted guarda la clave. ssh-keygen tiene predeterminada la localización correcta, pero le pregunta que introduzca un nombre de fichero en el caso que usted no quiera éste. Es útil algunas veces para tener ficheros de identidad diferentes, así que ssh permite esto. Como antes, ssh-keygen le preguntará que introduzca una frase de paso. Las frases de paso añaden otro nivel de seguridad y son una buena idea. Su frase de paso no será impresa en pantalla cuando usted la teclee.

    $ ssh-keygen
    Generating RSA keys:  .......oooooO..............................
    Key generation complete.
    Enter file in which to save the key (/home/maggie/.ssh/identity): 
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /home/maggie/.ssh/identity.
    Your public key has been saved in /home/maggie/.ssh/identity.pub.
    The key fingerprint is:
    1024 85:49:53:f4:8a:d6:d9:05:d0:1f:23:c4:d7:2a:11:67 maggie@moria
    $

12.5.2.3. Utilización de ssh

Ahora tenemos la orden ssh y sus programas asociados instalados y listos para ejecutarse. Veamos rápidamente como se ejecutan.

Primero, probaremos un registro (login) remoto a un host. Podemos usar el programa slogin de la misma forma que usamos el programa rlogin en nuestro ejemplo anterior en el libro. La primera vez que esperamos conectarnos a un host, el cliente ssh recuperará la clave publica del host y le preguntará si confirma esta identidad instándole con una versión reducida de la clave pública llamada huella dactilar[2].

El administrador del host remoto le debería haber proporcinado previamente estas huellas dactilares, las cuáles usted debe añadir a su fichero .ssh/known_hosts . Si el administrador remoto no le ha dado las claves apropiadas, usted puede conectarse al host remoto, pero ssh le advertirá que no tiene una clave y le pedirá que acepte una ofrecida por el host remoto. Asumiendo que usted está seguro que nadie le engaña con DNS spoofing y que usted de hecho está hablando con el host correcto, conteste yes. La clave se guarda automáticamente en su .ssh/known_hosts y no se le preguntará otra vez. Si, en un futuro intento de conexión, la clave pública recuperada desde este host no coincide con la que hay guardada, se le advertirá, porque esto representa un agujero de seguridad potencial.

La primera vez que conectamos con un host remoto veremos algo como esto:

$ slogin vchianti.vbrew.com The authenticity of host 'vchianti.vbrew.com' can't be established. Key fingerprint is 1024 7b:d4:a8:28:c5:19:52:53:3a:fe:8d:95:dd:14:93:f5. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'vchianti.vbrew.com,172.16.2.3' to the list of/ known hosts. maggie@vchianti.vbrew.com's password: Last login: Tue Feb 1 23:28:58 2000 from vstout.vbrew.com $

Se le pedirá una clave, debe contestar con la clave de la cuenta remota, no con la local. Esta clave no tendrá eco por pantalla cuando la introduzca.

Sin ningún argumento especial, slogin intentará utilizar el mismo identificador de usuario que en la máquina local. Puede cambiar esto usando el argumento -l , dando un nombre de registro alternativo en el host remoto. Esto que lo que hicimos en nuestro ejemplo anterior en el libro.

Podemos copiar ficheros hacia y desde un host remoto usando el programa scp. Su sintaxis es similar al convencional cp con la excepción que debe especificar un nombre de host antes del fichero, significando que el camino del fichero está en el host especificado. El siguiente ejemplo ilustra la sintaxis de scp copiando un fichero local llamado /tmp/fred al /home/maggie/ del host remoto chianti.vbrew.com:

$ scp /tmp/fred vchianti.vbrew.com:/home/maggie/ maggie@vchianti.vbrew.com's password: fred 100% |*****************************| 50165 00:01 ETA

De nuevo, se le pedirá una clave. La orden scp muestra el progreso de la copia por omisión. Puede copiar un fichero desde un host remoto con la misma facilidad; simplemente especificando su nombre de host y ruta como origen y la ruta local como destino. También se puede copiar un fichero desde un host remoto a otro host remoto, pero habitualmente no necesitará hacer eso, porque todos los datos viajan a través de su host.

Puede ejecutar órdenes en host remotos usando la orden ssh. De nuevo, su sintaxis es muy simple. Tengamos nuestro usuario maggie recuperando el directorio raíz del host remoto vchianti.vbrew.com. Ella hará algo como esto:

$ ssh vchianti.vbrew.com ls -CF / maggie@vchianti.vbrew.com's password: bin/ console@ dos/ home/ lost+found/ pub@ tmp/ vmlinuz@ boot/ dev/ etc/ initrd/ mnt/ root/ usr/ vmlinuz.old@ cdrom/ disk/ floppy/ lib/ proc/ sbin/ var/

Puede utilizar ssh con tuberías y entubar entradas/salidas de programas desde o hacia como cualquier otra orden, excepto que la entrada o la salida son dirigidas hacia o desde el host remoto mediante conexión ssh. Aquí tenemos un ejemplo de como puede utilizar esta característica en combinación con la orden tar para copiar un directorio entero con subdirectorios y ficheros desde un host remoto al host local:

$ ssh vchianti.vbrew.com "tar cf - /etc/" | tar xvf - maggie@vchianti.vbrew.com's password: etc/GNUstep etc/Muttrc etc/Net etc/X11 etc/adduser.conf .. ..

Hacemos notar que la orden se debe ejecutar con comillas para clarificar qué se está pasando como un argumento a la orden ssh y qué debe usar el intérprete de órdenes local. Esta orden ejecuta la orden tar en el host remoto para archivar el directorio /etc/ y escribir en la salida estándar. Hemos entubado una instancia de la orden tar ejecutando en nuestro host local en modo extracción leyendo desde la entrada estándar.

De nuevo, se pide una clave. ¡Ahora puede ver por qué le animamos a configurar ssh para que no se le pida las claves todo el tiempo! Vamos ahora a configurar nuestro cliente local ssh de modo que no nos pida la clave cuando conectemos al host vchianti.vbrew.com. Mencionamos antes el fichero .ssh/authorized_keys; aquí es donde se va a usar. El fichero .ssh/authorized_keys contiene las claves públicas de cada cuenta de usuario remota que queremos registrar automáticamente. Puede establecer registros automáticos copiando el contenido del .ssh/identity.pub desde la cuenta remota en nuestro fichero local .ssh/authorized_keys. Es vital que los permisos de fichero de .ssh/authorized_keys permitan sólo que usted pueda leer y escribir; cualquiera puede robar y usar las claves para registrarse en esas cuentas remotas. Para asegurar que los permisos sean correctos, cambie .ssh/authorized_keys, como sigue:

$ chmod 600 ~/.ssh/authorized_keys

Las claves públicas son una larga sencilla línea de texto plano. Si usa copiar y pegar para duplicar la clave en su fichero local, asegúrese de borrar cualquier carácter de final de línea que se pueden haber introducido de esta manera. El fichero .shh/uathorized_keys puede contener muchas de estas claves, cada una en una línea propia.

La suite de herramientas ssh es muy potente y tiene muchas otras características y opciones que pueden ser interesantes de explorar. Por favor consulte las páginas del manual y otros documentos que se proporcionan con los paquetes para más información.