|
Una de las debilidades en el uso de mecanismos de confianza definidos
mediante archivos .rhosts en Unix es que los programas tales como rsh y
rlogin simplemente se basan en una dirección IP para autenticar
a la máquina en quien confían, y dado que las direcciones
IP pueden ser falsificadas, este mecanismo de confianza no es seguro.
Peor aún, toda la información que transita entre una y
otra máquina lo hace "en claro" o sin ser cifrada, lo
cuál resulta en un fallo de seguridad grave pues atenta contra
la propiedad de confidencialidad de la información. Por las razones expuestas arriba, la posición de EDS es evitar el uso de archivos .rhosts y archivos .netrc (estos últimos contienen nombres de usuario, contraseñas y direcciones IP para hacer transferencias automáticas de archivos usando el protocolo FTP). Sin embargo, por razones de negocio algunas veces resulta inevitable hacer uso de mecanismos de confianza, en cuyo caso la política es reemplazar estos mecanismo de confianza nativos en Unix por un esquema más robusto, más seguro. Aquí es donde entran en juego las llaves de autenticación de SSH. Para poder hacer uso de llaves de SSH es necesario tener instalada la herramienta SSH/OpenSSH. A partir de Solaris 9, SSH viene incluido por default (SSH-2.0-Sun_SSH_1.0.1), pero si desea mantenerse actualizada esta herramienta, lo mejor es reemplazarla con OpenSSH (SSH-1.99-OpenSSH_4.1). Referirse al material del taller de "Manual de Instalación, Configuración y Uso de OpenSSH" para instalar OpenSSH. Una vez instalado SSH/OpenSSH es necesario definir las 4 entidades que participarán en la relación de confianza: una máquina cliente (mcliente), un usuario en la máquina cliente (ucliente), una máquina servidor (mservidor) y un usuario en la máquina servidor (uservidor). El procedimiento para configurar esta relación de confianza es el siguiente: 1. Conectarse a mcliente con el usuario ucliente 2. Crear una llave de tipo DSA con una longitud de 1024 bits para el protocolo SSHv2 con una frase de paso (passphrase) nula (ingresar ENTER cuando se solicite la frase de paso): ssh-keygen -t dsa -b 1024 Generating public/private dsa key pair. Enter file in which to save the key (/export/home/ucliente/.ssh/id_dsa): [ENTER] Created directory '/export/home/ucliente/.ssh'. Enter passphrase (empty for no passphrase): [ENTER] Enter same passphrase again: [ENTER] Your identification has been saved in /export/home/ucliente/.ssh/id_dsa. Your public key has been saved in /export/home/ucliente/.ssh/id_dsa.pub. The key fingerprint is: 18:c8:a8:80:32:bf:12:d3:4b:1d:f6:ae:35:d7:e4:e0 ucliente@mcliente Este comando genera una llave privada contenida en el archivo $HOME/.ssh/id_dsa y una llave pública contenida en el archivo $HOME/.ssh/id_dsa.pub. 3. Conectarse a mservidor con el usuario uservidor 4. Conectarse desde mservidor a mcliente usando SSH y terminar la sesión (este paso es únicamente para que automáticamente sea creado el subdirectorio $HOME/.ssh y dentro se guarde la llave de mcliente, en el archivo known_hosts): ssh ucliente@mcliente The authenticity of host 'mcliente' can't be established. RSA key fingerprint in md5 is: 4b:3c:9b:d7:d9:ed:9d:89:05:76:3b:4a:45:32:fc:a0 Are you sure you want to continue connecting(yes/no)?yes Warning: Permanently added 'mliente,10.98.201.145' (RSA) to the list of known hosts. ucliente@mcliente's password:******** Last login: Mon Jul 25 11:51:59 2005 from mservidor 5. Transferir de forma segura la llave pública creada en mcliente y colocarla en el directorio .ssh recién creado: cd .ssh scp id_dsa.pub ucliente@mcliente:.ssh/id_dsa.pub id_dsa.pub 100% |*************************| 600 00:00 6. Crear el archivo authorized_keys2. Este archivo debe contener la llave id_dsa.pub (y el resto de las llaves, en caso de que se requiera configurar más de una): cat id_dsa.pub >> authorized_keys2 chmod 600 authorized_keys2 rm id_dsa.pub 7. Probar el acceso a mservidor desde mcliente: ssh uservidor@mservidor The authenticity of host 'mservidor' can't be established. RSA key fingerprint in md5 is: 77:83:db:48:12:ea:15:70:04:ec:8c:22:36:de:b4:15 Are you sure you want to continue connecting(yes/no)? yes Warning: Permanently added 'mservidor,10.98.201.166' (RSA) to the list of known hosts. Last login: Mon Jul 11 11:03:29 2005 from ucliente Sun Microsystems Inc. SunOS 5.9 Generic May 2002 You have new mail. $ hostname mservidor $ exit NOTAS IMPORTANTES o Si mservidor está corriendo la versión de SSH instalada por default en Solaris 9, el archivo authorized_keys2 debe llamarse simplemente authorized_keys. o Tanto el directorio HOME de uservidor como el subdirectorio .ssh deben tener permisos 700 y deber ser propiedad del usuario y grupo definidos en el archivo /etc/passwd. o La llave privada de ucliente ($HOME/.ssh/id_dsa) debe tener los permisos 600. o Si la conexión no puede ser establecida puede usarse el modo de depuración de SSH para encontrar la razón. Si SSH está corriendo en modo standalone es necesario dar de baja el servidor sshd y luego iniciar SSH en modo de depuración: SSH Solaris 9: /etc/init.d/sshd stop; /usr/lib/ssh/sshd -d OpenSSH: pkill -9 sshd; /usr/local/sbin/sshd -d Si SSH es manejado por inetd, es necesario comentar el servicio ssh en el archivo /etc/inetd.conf y hacer que inetd vuelva a leer este archivo de configuración: vi /etc/inetd.conf #ssh stream tcp nowait root /usr/local/sbin/sshd sshd -i pkill -HUP inetd También resulta útil hacer uso de la opción verbose en el cliente de SSH para detectar errores de configuración: ssh -v uservidor@mservidor |
HOW TO LIST THE SOFT PARTITIONS IN A GIVEN SLICE
The metarecover command, with the -n and -v options,
will display information about the soft partitons existing in a given slice.
# metarecover -v -n /dev/rdsk/c1t0d0s0 -p
# metarecover -v -n d0 -p
