Guía de Administración de Redes con Linux | ||
---|---|---|
Anterior | Capítulo 12. Características Importantesde Redes | Siguiente |
Los programas tradicionales para ejecutar órdenes en hosts remotos son rlogin, rsh y rcp. Vimos un ejemplo de la orden rlogin en Capítulo 1 en la sección Sección 1.2.1.” vimos brevemente cuestiones de seguridad asociadas con esto en Sección 1.5.1” 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.
# 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 |
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.
# ssh-keygen -f /etc/ssh/ssh_host_key |
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 |
# /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 |
# 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 |
/usr/sbin/sshd |
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.
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 |
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. |
$ 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.
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.
[1] | OpenSSH se desarrolló por el proyecto OpenBSD y representa un ejemplo de los beneficios del software libre. |
[2] | fingerprint |