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 |