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 is an interactive command, similar to ftp. In a single session, sftp can transfer several files, and it is possible to manipulate remote files with it (delete, rename, change permissions, etc.). Many FTP clients, including filezilla, support it.
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. Combining authentication methods
Besides the already mentioned password based, key based, and the certificate based authentication, other methods like using a TOTP exist as well. Not only is this an abundance of options. They can also be combined. On the server side, the AuthenticationMethods directive can define an order of authentication methods a user has to successfully pass, before they are allowed to enter the system. It is even possible to define multiple alternative sequences:
AuthenticationMethods publickey,password publickey,keyboard-interactive:pam
This setting, for example, allows users to login after initially completing the public key authentication, followed by either a successful password authentication or entering a valid TOTP set up via PAM. On the user side, the sequence of methods can be defined using the PreferredAuthentications directive.
9.2.1.4. Utilización aplicaciones X11 remotas
The SSH protocol allows forwarding of graphical data (“X11” session, from the name of the most widespread graphical system in Unix); the server then keeps a dedicated channel for those data. Specifically, a graphical program executed remotely can be displayed on the X.org server of the local screen, and the whole session (input and display) will be secure. Since this feature allows remote applications to interfere with the local system, it is disabled by default. You can enable it by specifying X11Forwarding yes in the server configuration file sshd_config(5) or by prepending the public key with the X11-forwarding keyword in the authorized_keys(5) file. Finally, the user must also request it by adding the -X option to the ssh command-line.
9.2.1.5. 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.
