És essencial que un administrador pugui connectar-se a un ordinador remotament. Els servidors, confinats al seu espai, rarament estan equipats amb teclats i monitors permanents, però estan connectats a la xarxa.
9.2.1. Inici de sessió remot segur: SSH
El protocol SSH (Secure SHell) va ser dissenyat amb la seguretat i la fiabilitat en ment. Les connexions que utilitzen SSH són segures: l'altra part està autenticada i tots els intercanvis de dades estan encriptats.
SSH també ofereix dos serveis de transferència de fitxers. scp és una eina de línia d'ordres que es pot utilitzar com cp, excepte que qualsevol camí a una altra màquina està prefixat amb el nom de la màquina, seguit de dos punts (“:”).
$ scp fitxer ordinador:/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 utilitza OpenSSH, una versió lliure d'SSH mantinguda pel projecte OpenBSD (un sistema operatiu lliure basat en el nucli BSD, centrat en la seguretat) i bifurcació («fork») del programa SSH original desenvolupat per l'empresa SSH Communications Security Corp, de Finlàndia. Aquesta empresa inicialment va desenvolupar SSH com a programari lliure, però finalment va decidir continuar-ne el desenvolupament sota una llicència propietària. El projecte OpenBSD va crear llavors l'OpenSSH per mantenir una versió lliure de l'SSH.
L'OpenSSH està separat en dos paquets: la part del client està al paquet openssh-client, i el servidor està al paquet openssh-server. El metapaquet ssh depèn de les dues parts i facilita la instal·lació d'ambdues (apt install ssh), mentre que task-ssh-server, normalment escollit durant la instal·lació inicial, depèn només del paquet del servidor.
9.2.1.1. Autenticació basada en claus
Cada vegada que inicia una sessió amb SSH, el servidor remot demana una contrasenya per autenticar l'usuari. Això pot ser problemàtic si voleu automatitzar una connexió, o si utilitzeu una eina que requereix connexions freqüents sobre SSH. Per això SSH ofereix un sistema d'autenticació basat en claus.
L'usuari genera un parell de claus a la màquina client amb ssh-keygen -t rsa; la clau pública que genera s'emmagatzema a ~/.ssh/id_rsa.pub, mentre que la clau privada corresponent es desa a ~/.ssh/id_rsa. L'usuari pot llavors utilitzar ssh-copy-id servidor per afegir la seva clau pública al fitxer ~/.ssh/authorized_keys al servidor o, si l'accés SSH encara no s'ha activat, s'ha de demanar a l'administrador que afegeixi la clau manualment.
Si la clau privada no estava protegida amb una contrasenya (o «passphrase») en el moment de la seva creació, tots els inicis de sessió posteriors del servidor funcionaran sense contrasenya. En cas contrari, la clau privada ha de ser desencriptada cada vegada introduint la contrasenya. Afortunadament, ssh-agent ens permet mantenir les claus privades en memòria per no haver de tornar a introduir la contrasenya cada cop. Per a això, simplement utilitzeu ssh-add (una vegada per sessió de treball) sempre que la sessió ja estigui associada amb una instància funcional d' ssh-agent. Debian l'activa per defecte en sessions gràfiques, però això es pot desactivar canviant /etc/X11/Xsession.options i comentar use-ssh-agent. Per a una sessió de consola, es pot iniciar manualment l'agent amb eval $(ssh-agent)).
9.2.1.2. Autenticació basada en certificat
Les claus SSH no es poden protegir només amb una contrasenya (o no). Una característica sovint desconeguda és que també es poden signar mitjançant certificat, tant les claus del servidor com les del client. Aquesta aproximació comporta diversos avantatges. En lloc de mantenir un fitxer
authorized_keys per cada usuari com s'ha descrit a la secció anterior, el servidor SSH es pot configurar per confiar en totes les claus de client signades amb el mateix certificat (vegeu també
Secció 10.2.2, «Infraestructura de clau pública: easy-rsa») usant les directives
TrustedUserCAKeys i
HostCertificate a
/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
Recíprocament, els clients també es poden configurar per confiar en la clau de l'amfitrió signada per la mateixa autoritat, fent més fàcil mantenir el fitxer known_hosts (fins i tot a nivell de sistema via /etc/ssh/known_hosts).
@cert-authority *.falcot.com ssh-rsa AAAA[..]
Tots dos, tant la clau pública com l'autenticació de certificat es poden utilitzar simultàniament.
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. Usar aplicacions X11 remotes
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ó de túnels encriptats amb reenviament de ports
Les opcions
-R i
-L permeten a
ssh crear “túnels xifrats” entre dues màquines, redirigint de forma segura un port TCP local (vegeu la barra lateral
TORNAR A LES BASES TCP/UDP) cap a una màquina remota o viceversa.
ssh -L 8000:servidor:25 intermediari estableix una sessió SSH amb la màquina
intermediari i escolta pel port local 8000 (vegeu
Figura 9.3, «Reenviament d'un port local amb SSH»). Per a qualsevol connexió establerta en aquest port,
ssh iniciarà una connexió des de l'ordinador
intermediari cap al port 25 del
servidor, i unirà ambdues connexions.
ssh -R 8000:servidor:25 intermediari també estableix una sessió SSH amb la màquina
intermediari, però és en aquest equip que
ssh escolta pel port 8000 (vegeu
Figura 9.4, «Reenviament d'un port local amb SSH»). Qualsevol connexió establerta en aquest port farà que
ssh obri una connexió des de l'ordinador local cap al port 25 del
servidor, i unirà ambdues connexions.
En tots dos casos es fan connexions al port 25 de l'equip servidor, que passen a través del túnel SSH establert entre la màquina local i la màquina intermediari. En el primer cas, l'entrada al túnel és el port local 8000, i les dades es mouen cap a la màquina intermediari abans de ser dirigida a l'equip servidor a la xarxa “pública”. En el segon cas, l'entrada i la sortida del túnel s'inverteixen; l'entrada és el port 8000 de la màquina intermediari, la sortida és a l'ordinador local, i les dades es dirigeixen a servidor. A la pràctica, el servidor sol ser la màquina local o l'intermediari. D'aquesta manera SSH assegura la connexió d'un extrem a l'altre.
9.2.2. Ús d'escriptoris gràfics remots
VNC (computació en xarxes virtuals o «Virtual Network Computing») permet l'accés remot a escriptoris gràfics.
Aquesta eina s'utilitza principalment per a l'assistència tècnica; l'administrador pot veure els errors als quals s'enfronta l'usuari i mostrar-li el curs correcte de l'acció sense haver d'estar al seu costat.
En primer lloc, l'usuari ha d'autoritzar compartir la seva sessió. L'entorn d'escriptori gràfic del GNOME inclou aquesta opció a través de → (a diferència de versions anteriors de Debian, on l'usuari havia d'instal·lar i executar vino). Perquè això funcioni, el network-manager ha d'estar gestionant la xarxa utilitzada (per exemple, habiliteu el mode maaged per a dispositius gestionats per ifupdown a /etc/NetworkManager/NetworkManager.conf). El KDE Plasma encara requereix l'ús de krfb per permetre compartir una sessió existent sobre VNC. Per a altres entorns d'escriptori gràfics, les ordres x11vnc o tightvncserver (dels paquets Debian amb idèntic nom) o tigervncserver (tigervnc-standalone-server) tenen mateix propòsit i proveeixen el paquet virtual vnc-server; qualsevol d'ells el podeu deixar disponible per a l'usuari amb una entrada de menú o icona a l'escriptori.
Quan la sessió gràfica està disponible via VNC, l'administrador ha de connectar-se amb un client VNC. GNOME té vinagre i remmina per a això, mentre que el projecte del KDE proporciona krdc (en el menú → → ). Hi ha altres clients VNC que utilitzen la línia de d'ordres, com xtightvncviewer del paquet Debian homònim o xtigervncviewer al paquet Debian tigervnc-viewer. Un cop connectat, l'administrador pot veure el que està passant, treballar a la màquina remotament i mostrar a l'usuari com procedir.
