12.5. Configurando Login Remotoy Ejecución

12.5.2.1. El demonio ssh

El demonio sshd es el programa que escucha conexiones red desde clientes ssh, maneja autentificación, y ejecuta las peticiones de comando. Hay un fichero de confoguración principal llamado /etc/ssh/sshd_config y un fichero especial que contiene una clave useda por el proceso de autentificación y encriptación para representar el host final. Cada host final, cada cliente tiene 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 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 defecto, ssh-keygen genera claves de 1024 bits de lengitud, y mucha gente usa esta longitud. Para generar una clave aleatoria, usted puede invocar el comando ssh-keygen así:

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

Se le pedirá que introduzaca una passphrase. Sin embargo, las claves host no usan passphrase, 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

Usted puede buscar 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 llamas la clave publica y es uno que usted puede compartir; estará en /etc/ssh/ssh_host_key.pub.

Armados con las claves para la comunicación ssh, usted necesita crear un fichero de configuración. El juago ssh es muy potente y el fichero de configuración puede contener muchas opcioness. Nosotros expondremos un ejemplo sencillo para que usted empieze; usted debe dirigirse a la documentación de ssh para activar otras caracteristicas. El siguiente código muestra seguro y mínimo fichero de configuración sshd . El resto de las opciones de configuración se detallan en las páginas del manual del sshd (8) :

    # /etc/ssh/sshd_config
    #
    
    # The IP adddresses to listen for connections on. 0.0.0.0 means all
    # local addresses.
    ListenAddress 0.0.0.0
    
    # The TCP port to listen for connections on. The default is 22.
    Port 22
    
    # The name of the host key file.
    HostKey /etc/ssh/ssh_host_key
    
    # The length of the key in bits.
    ServerKeyBits 1024
    
    # Should we allow root logins via ssh?
    PermitRootLogin no
    
    # Should the ssh daemon check users' home directory and files permissions?
    # are safe before allowing login?
    StrictModes yes
    
    # Should we allow old ~/.rhosts and /etc/hosts.equiv authentication method?
    RhostsAuthentication no
    # Should we allow pure RSA authentication?
    RSAAuthentication yes
    # Should we allow password authentication?
    PasswordAuthentication yes
    
    # Should we allow /etc/hosts.equiv combined with RSA host authentication?
    RhostsRSAAuthentication no
    # Should we ignore ~/.rhosts files?
    IgnoreRhosts yes
    # Should we allow logins to accounts with empty passwords?
    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 los siguientes commandos:

# 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 esto o añadir 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 automaticámente se ejecutará en segundo plano. Usted ahora esta listo para aceptar conexiones ssh.

12.5.2.2. El cliente ssh

Existen un número de 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 leen ficheros de configuración desde el directorio .ssh en el directorio home del usuario que lo esté ejecutando. El más importante de estos ficheros es el .ssh/config , el cual debe contener opciones que están por encima de las especificadas en el fichero /etc/ssh/ssh_config, el fichero .ssh/identity, el cual contiene la clave privada del usuario propietario, y el correspondiente fichero .ssh/identity.pub, conteniendo la clave pública de usuario. Otros dicheros 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.

/etc/ssh/ssh_config es muy similar al fichero de configuración de 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 especificos 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 relacionar todos los hosts. Podemos crear una entrada que usada, por ejemplo, Host *.vbrew.com relacione cualquier host en el dominio vbrew.com.

    # /etc/ssh/ssh_config
    
    # Default options to use when connecting to a remote host
    Host *
      # Compress the session data?
      Compression yes
      # .. using which compression level? (1 - fast/poor, 9 - slow/good)
      CompressionLevel 6
    
      # Fall back to rsh if the secure connection fails?
      FallBackToRsh no
    
      # Should we send keep-alive messages? Useful if you use IP masquerade
      KeepAlive yes
    
      # Try RSA authentication?
      RSAAuthentication yes
      # Try RSA authentication in combination with .rhosts authentication?
      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 el mismo comando 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 por defecto la correcta localización, pero le pregunta que introduzca un nombre de fichero en el caso que usted no quiera este. Esto se usa para tener diferentes ficheros de identidad, ssh permite esto. Como antes, ssh-keygen le preguntará que introduzca una passphrase. Passphrases añaden otro nivel de seguridad y son una buena idea. Sus passphrase no deben ser imprimidas en pantalla cuando usted las 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
    $

Ahora ssh esta listo para ejecutarse.

12.5.2.3. Using ssh

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

Primero, provaremos un login remoto a un host. Podemos usar el porgrama slogin de la misma forma que usamos el programa rlogin en nuestro anterios ejemplo 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 digital.

El administrador del host remoto le debe proporcinar previamente estas huellas digitales, las cuales 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 avisará 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 esta hablando con el correcto host, 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 avisará, porque esto representa un agujero de seguridad.

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á un password, debe contestar con el password de la cuenta remota, no con la local. Este password no tendrá salida por pantalla cuando lo introduzca.

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

Podemos copiar ficheros hacia y desde un host remoto usando el programa scp. Su siontaxis es similar al convencional cp con la excepción que debe especificar un hostname 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á un password. El comando scp enseña el progreso de la copia por defecto. Puede copiar un fichero desde un host remoto con la misma facilidad; simplemente especificando su hostname y camino como origen y el camino local como destino. Tambien se puede copiar un fichero desde un host remoto a otro host remoto, pero habitualmente a usted no necesitará hacer eso, porque todos los datos viajan via su host.

Puede ejecutar comandos en host remotos usando el comando ssh. De nuevo, su sintaxis es muy simple. Tengamos nuestro usuario maggie recuperando el directorio root directory 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 de o hacia como cualquier otro comando, excepto que la entrada o la salida son dirigidas hacia o desde el host remoto via conexión ssh. Aquí tenemos un ejemplo de como usted puede utilizar esta característica en combinación con el comando 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 el comando se debe ejecutar con marcas de quota para hacerlo limpio cuando sea pasado como argumento hacia ssh y usado por la shell local. Este comando ejecuta el comando tar en el host remoto para archivar el directorio /etc/ y escribir en la salida estandard. Hemos entubado una instancia del comando tar corriendo en nuestro host local en modo extract leyendo desde la entrada estandard.

De nuevo, se pide un password. Ahora puede ver porque le animamos a configurar ssh ¡de este modo no se le pedirán password todo el tiempo! Vamos ahora a configurar nuestro ssh client local de modo que no nos pida password cuando conectemos al host vchianti.vbrew.com. Hablamos antes del fichero .ssh/authorized_keys; esto es porque se usa. El fichero .ssh/authorized_keys contiene las claves públicas en cada cuanta de usario remota donde nosotros queramos conectar automáticamente. Puede establecer conexiones automáticas 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 conectarse en 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 juego de herramientas ssh es muy potente y tiene muchas otras características y opciones que le puede intererar investigar. Por favor consulte las páginas del manual y otros documentos que se proporcionan con los paquetes para más información.