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. [email protected]'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/ [email protected]'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 / [email protected]'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 - [email protected]'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.