Es a menudo muy útil ejecutar una orden en un host remoto y que la entrada o la salida de esa orden pueda leerse o escribirse a través de una conexión de red.
Los programas tradicionales para ejecutar órdenes en hosts remotos son rlogin, rsh y rcp. Ya hemos visto un ejemplo de la orden rlogin y cuestiones de seguridad asociadas con esto y sugerimos ssh como alternativa. El paquete ssh proporciona unos reemplazos llamados slogin, ssh, y scp.
Cada una de estas órdenes genera un intérprete de órdenes en el host remoto y permite al usuario ejecutar órdenes. Por supuesto, el cliente necesita tener una cuenta en el host remoto donde la orden va a ser ejecutada. Así, todas estas órdenes usan un proceso de autentificación. Las órdenes //r// usan un simple intercambio de nombre de usuario y contraseña entre los hosts sin encriptación, de este modo cualquiera que esté escuchando puede fácilmente interceptar las contraseñas. El conjunto de órdenes ssh proporcionan un nivel de seguridad más alto: usan una técnica llamada Criptografía de Clave Pública, la cual proporciona autentificación y encriptación entre los hosts para asegurar que tanto contraseñas como datos de la sesión sean interceptados por otros hosts.
Es posible relajar la comprobación de la autentificación para ciertos usuarios todavía más. Por ejemplo, si usted tiene que registrarse en otras máquinas de su red frecuentemente, usted puede querer ser admitido sin tener que teclear su contraseña cada vez. Esto era posible con las órdenes //r//, pero las órdenes ssh le permiten hacer esto algo más sencillo. Esto no es una gran idea porque significa que si una cuenta de una máquina es violada, se puede ganar el acceso a otras cuentas que el usuario ha configurado para registrarse sin password, pero esto es muy conveniente y la gente quiere usarlo.
Hablemos acerca de quitar las órdenes //r// y usar ssh para trabajar en su lugar.
===== Desactivando las Órdenes r =====
Comencemos retirando las órdenes r si están instaladas. La forma más fácil de desactivar las órdenes r antiguas es comentando (o borrando) sus entradas en el fichero ##/etc/inetd.conf##. Las entradas relevantes se parecen a algo como esto:
|| # Shell, login, exec y talk como protocolos BSD.
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd ||
Puede comentarlas anteponiendo el carácter ##### al principio de cada línea, o borrando las líneas completamente. Recuerde, necesitará reiniciar el demonio inetd para que este cambio tenga efecto. Idealmente, debería retirar los mismos ejecutables también.
===== Instalando y Configurando ssh =====
OpenSSH es una versión libre del conjunto de programas ssh; el porte para GNU/Linux se puede encontrar en http://violet.ibs.com.au/openssh/ y en muchas distribuciones modernas de GNU/Linux.[1] No explicaremos aquí la compilación; se incluyen buenas instrucciones en el código fuente. Si usted puede instalarlo desde un paquete precompilado, es probablemente inteligente hacerlo así.
Hay dos partes en una sesión ssh. Hay un cliente ssh que usted necesita configurar y ejecutar en el host local y un demonio ssh que debe ejecutarse en el host remoto.
==== 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//.
==== 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 .” 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 http://es.tldp.org/Manuales-LuCAS/GARL2/garl2/x-087-2-appl.remote.html#X-087-2-FEATURES.SSH.CONF 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##.
Ejemplo 12-5. Ejemplo De Fichero de Configuración del Cliente ssh
|| # /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.
|| Aviso ||
|| No hay forma de recuperar una frase de paso si la olvida. Cercióorese de que será algo que usted recordará, pero como toda contraseña, elija algo que no sea obvio, como nombres propios o su nombre. Para que una frase de paso sea efectiva, debe tener entre 10 y 30 caracteres de longitud y no debe ser prosa inglesa simple. Pruebe incluir algunos caracteres no usuales. Si usted pierde su frase de paso, deberá generar una clave nueva. ||
Debería preguntar a cada uno de sus usuarios si han ejecutado la orden ssh-keygen para asegurarse de que sus ficheros de claves se han generado correctamente. El ssh-keygen creará sus directorios ##~/.ssh/## para ellos con los permisos apropiados y creará su clave privada y pública en ##.ssh/identity## y ##.ssh/identity.pub##, respectivamente. Un ejemplo de sesión se muestra aquí: || $ ##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.
==== 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.
==== Notas ====
|| [1] || OpenSSH se desarrolló por el proyecto OpenBSD y representa un ejemplo de los beneficios del software libre. ||
|| [2] || fingerprint ||
