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.
The user generates a key pair on the client machine with ssh-keygen -t rsa; the so generated public key is stored in ~/.ssh/id_rsa.pub, while the corresponding private key is stored in ~/.ssh/id_rsa. The user can then use ssh-copy-id server to add their public key to the ~/.ssh/authorized_keys file on the server, or, if SSH access hasn't been enabled yet, they have to ask the administrator to add their key manually.
If the private key was not protected with a “passphrase” at the time of its creation, all subsequent logins on the server will work without a password. Otherwise, the private key must be decrypted each time by entering the passphrase. Fortunately, ssh-agent allows us to keep private keys in memory to not have to regularly re-enter the password. For this, you simply use ssh-add (once per work session) provided that the session is already associated with a functional instance of ssh-agent. Debian activates it by default in graphical sessions, but this can be deactivated by changing /etc/X11/Xsession.options and commenting out use-ssh-agent. For a console session, you can manually start the agent with 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
Vice-versa the clients can also be configured to trust the host key signed by the same authority, making it easier to maintain the known_hosts file (even system wide via /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.
