Es esencial para el administrador poder conectarse a un equipo de forma remota. Los servidores, aislados en su propia habitación, rara vez están equipados con monitores y teclados permanentes — pero están conectados a la red.
9.2.1. Inicio seguro de sesión remota: SSH
El protocolo SSH (interprete de órdenes seguro: «Secure SHell») fue diseñado pensando en la seguridad y la confiabilidad. Las conexiones que utilizan SSH son seguras: la otra parte es autenticada y se cifran todos los datos intercambiados.
SSH también ofrece dos servicios de transferencia de archivos. scp es una herramienta para la terminal que puede utilizar como cp excepto que cualquier ruta a otro equipo utilizará un prefijo con el nombre de la máquina seguido de dos puntos («:»).
$ scp archivo equipo:/tmp/
sftp es un programa interactivo similar a ftp. En una sola sesión sftp puede transferir varios archivos y es posible manipular archivos remotos con él (eliminar, renombrar, cambiar permisos, etc.).
Debian utiliza OpenSSH, una versión libre de SSH mantenida por el proyecto OpenBSD (un sistema operativo libre basado en el núcleo BSD enfocado en seguridad) que es una bifurcación («fork») del software SSH original desarrollado por la empresa SSH Communications Security Corp de Finlandia. Esta empresa inicialmente desarrolló SSH como software libre pero eventualmente decidió continuar su desarrollo bajo una licencia privativa. El proyecto OpenBSD luego creó OpenSSH para mentener una versión libre de SSH.
OpenSSH está dividido en dos paquetes: la parte del cliente se encuentra en el paquete openssh-client y el servidor en el paquete openssh-server. El metapaquete ssh depende de ambas partes y facilita la instalación conjunta (apt install ssh), mientras que el task-ssh-server, a menudo elegido durante la instalación inicial, depende del paquete servidor solamente.
9.2.1.1. Autenticación basada en llaves
Cada vez que alguien inicia sesión a través de SSH, el servidor remoto pide una contraseña para autenticar al usuario. Esto puede ser problemático si desea automatizar la conexión o si utiliza una herramienta que necesita conexiones frecuentes sobre SSH. Es por esto que SSH ofrece un sistema de autenticación basada en llaves.
El usuario genera un par de llaves en la máquina cliente con ssh-keygen -t rsa; la llave pública generada se almacena en ~/.ssh/id_rsa.pub, mientras que la llave privada correspondiente se almacena en ~/.ssh/id_rsa. El usuario puede utilizar entonces ssh-copy-id server para agregar su llave pública al archivo ~/.ssh/authorized_keys en el servidor o, si el acceso SSH aún no se ha habilitado, tiene que pedirle al administrador que agregue su clave manualmente.
Si la clave privada no estaba protegida con una "contraseña" en el momento de su creación, todos los inicios de sesión posteriores en el servidor funcionarán sin contraseña. De lo contrario, la clave privada debe descifrarse cada vez ingresando la contraseña. Afortunadamente, ssh-agent nos permite mantener las claves privadas en la memoria para no tener que volver a ingresar la contraseña con regularidad. Para esto, simplemente usar ssh-add (una vez por sesión de trabajo) siempre que la sesión ya esté asociada a una instancia funcional de ssh-agent. Debian lo activa por defecto en sesiones gráficas, pero esto se puede desactivar cambiando /etc/X11/Xsession.options y comentando use-ssh-agent. Para una sesión de consola, puede iniciar manualmente el agente con eval $(ssh-agent).
9.2.1.2. Autenticación basada en certificado
Las teclas SSH no se pueden proteger por una contraseña (o no). Una característica a menudo desconocida es que también se pueden ser firmar mediante certificado, tanto el anfitrión como las claves del cliente. Este enfoque tiene varias ventajas. En lugar de mantener un archivo
authorized_keys por usuario como se describe en la sección anterior, se puede configurar el servidor SSH para que confíe en todas las claves del cliente firmadas por el mismo certificado (ver también
Sección 10.2.2, “Infraestructura de llave pública: easy-rsa”) usando las directivas
TrustedUserCAKeys y
HostCertificate en
/etc/ssh/sshd_config.
TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub
HostKey /etc/ssh/ssh_host_ecdsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
Por otro lado, los clientes también pueden configurarse para confiar en la clave del equipo firmada por la misma autoridad, lo que facilita el mantenimiento del archivo known_hosts (incluso en todo el sistema a través de /etc/ssh/known_hosts).
@cert-authority *.falcot.com ssh-rsa AAAA[..]
Tanto la autenticación mediante clave pública como la autenticación mediante certificado se pueden utilizar conjuntamente.
9.2.1.3. Utilización aplicaciones X11 remotas
El protocolo SSH permite redirigir datos gráficos (sesión «X11» por el nombre del sistema gráfico más utilizado en Unix); el servidor luego mantiene un canal dedicado para estos datos. Específicamente, el programa gráfico ejecutado remotamente puede mostrarse en el servidor X.org de la pantalla local y toda la sesión (datos ingresados y lo que sea mostrado) será segura. De forma predeterminada, esta funcionalidad está desactivada porque permite que aplicaciones remotas interfieran con el sistema local. Puede activarla especificando X11Forwarding yes en el archivo de configuración del servidor (/etc/ssh/sshd_config). Finalmente, el usuario también debe solicitarlo agregando la opción -X al ejecutar ssh.
9.2.1.4. Creación de túneles cifrados con redirección de puertos
Las opciones
-R y
-L le permiten a
ssh crear «túneles cifrados» entre dos equipos, redirigiendo de forma segura un puerto TCP local (revise el recuadro
VOLVER A LOS CIMIENTOS TCP/UDP) a un equipo remoto o viceversa.
ssh -L 8000:servidor:25 intermediario establece una sesión SSH con el equipo
intermediario y escucha en el puerto local 8000 (revise la
Figura 9.3, “Redirección de un puerto local con SSH”). Para cualquier conexión en este puerto,
ssh iniciará una conexión desde el equipo
intermediario al puerto 25 de
servidor y unirá ambas conexiones.
ssh -R 8000:servidor:25 intermediario también establece una sesión SSH al equipo
intermediario, pero es en este equipo que
ssh escuchará en el puerto 8000 (revise la
Figura 9.4, “Redirección de un puerto remoto con SSH”). Cualquier conexión establecida en este puerto causará que
ssh abra una conexión desde el equipo local al puerto 25 de
servidor y unirá ambas conexiones.
En ambos casos, se realizan las conexiones en el puerto 25 del equipo servidor, que pasarán a través del túnel SSH establecido entre la máquina local y la máquina intermediario. En el primer caso, la entrada al túnel es el puerto local 8000 y los datos se mueven hacia la máquina intermediario antes de dirigirse a servidor en la red «pública». En el segundo caso, la entrada y la salida del túnel son invertidos; la entrada es en el puerto 8000 de la máquina intermediario, la salida es en el equipo local y los datos son dirigidos a servidor. En la práctica, el servidor generalmente está en la máquina local o el intermediario. De esa forma SSH asegura la conexión un extremo a otro.
9.2.2. Utilización de escritorios gráficos remotos
VNC (computación en redes virtuales: «Virtual Network Computing») permite el acceso remoto a escritorios gráficos.
Esta herramienta se utiliza más que nada para asistencia técnica; el administrador puede ver los errores con los que se enfrenta el usuario y mostrarle el curso de acción correcto sin tener que estar a su lado.
Primero, el usuario debe autorizar compartir su sesión. El entorno gráfico de escritorio GNOME incluye esa opción a través de → (en contra de versiones anteriores de Debian, donde el usuario tuvo que instalar y ejecutar vino). Para que esto funcione network-manager debe estar administrando la red utilizada (por ejemplo, habilitar el modo managed para dispositivos manejados por ifupdown en /etc/NetworkManager/NetworkManager.conf). KDE Plasma todavía requiere usar krfb para permitir compartir un período de sesiones existente sobre VNC. Para otros entornos gráficos de escritorio, los comandos x11vnc or tightvncserver sirven al mismo propósito y proporcionan el paquete virtual vnc-servidor; puede poner cualquiera de ellos a disposición del usuario con un menú explícito o entrada de escritorio.
Cuando la sesión gráfica está disponible a través de VNC, el administrador debe conectarse a ella con un cliente VNC. Para ello GNOME posee vinagre y remmina, mientras que el proyecto KDE proveekrdc (en el menú → → ). Hay otros clientes VNC que utilizan la línea de comandos, como xtightvncviewer del paquete homónimo o xtigervncviewer del Paquete Debian tigervnc-viewer. Una vez conectado, el administrador puede ver lo que está pasando, trabajar en la máquina remotamente, y mostrar al usuario cómo proceder.
