9.2. Inici de sessió remot

É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.

VOCABULARI Autenticació, xifratge

Quan cal donar a un client la capacitat de dur a terme o activar accions en un servidor, la seguretat és important. Cal assegurar la identitat del client; això és, l'autenticació. Aquesta identitat normalment consisteix en una contrasenya que s'ha de mantenir en secret, o qualsevol altre client podria obtenir-la. Aquest és el propòsit de l'encriptació, que és una forma de codificació que permet a dos sistemes intercanviar informació confidencial a través d'un canal públic al mateix temps que la protegeix de ser llegible per altres.

L'autenticació i l'encriptació s'esmenten sovint juntes, tant perquè s'utilitzen sovint juntes, com perquè s'apliquen normalment amb conceptes matemàtics similars.

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 és una ordre interactiva, similar a ftp. En una sola sessió, sftp pot transferir diversos fitxers, i és possible manipular fitxers remots (suprimir, reanomenar, canviar permisos, etc.).

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.

TORNAR A LES BASES Bifurcació («fork»)»

Una “bifurcació” (o «fork» en anglès), en l'àmbit del programari, significa un nou projecte que comença com un clon d'un projecte existent, i que competirà amb ell. A partir d'aquí, tots dos programes solen divergir ràpidament en termes de nous desenvolupaments. Una bifurcació és sovint el resultat de desacords dins de l'equip de desenvolupament.

L'opció de bifurcar un projecte és un resultat directe de la mateixa naturalesa del programari lliure; una bifurcació és un esdeveniment saludable quan permet la continuació d'un projecte com a programari lliure (per exemple en cas de canvis de llicència). Una bifurcació derivada de desacords tècnics o personals és sovint un balafiament de recursos humans; una altra resolució seria preferible. Les fusions de dos projectes que prèviament havien passat per una bifurcació anterior no són inaudits.

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)).

SEGURETAT Protecció de la clau privada

Qualsevol que tingui la clau privada pot accedir al compte així configurat. Aquesta és la raó per la qual l'accés a la clau privada està protegit amb una contrasenya. Algú que obtingui una còpia d'un fitxer de clau privada (per exemple, ~/.ssh/id_rsa) encara li cal saber aquesta contrasenya per poder utilitzar-la. No obstant això, aquesta protecció addicional no és infalible, i si creieu que aquest fitxer ha estat compromès, és millor desactivar aquesta clau en els ordinadors en els quals s'hagi instal·lat (eliminant-la dels fitxers authorized_keys) i substituint-la per una nova clau generada.

CULTURA Error OpenSSL a Debian Etch

La llibreria OpenSSL, tal i com es va proporcionar inicialment a Debian Etch, tenia un greu problema en el seu generador de nombres aleatoris (RNG). De fet, el mantenidor de Debian hi havia fet un canvi de manera que les aplicacions que l'utilitzaven ja no generarien avisos quan fossin analitzades per eines de prova de memòria com valgrind. Malauradament, aquest canvi també va significar que l'RNG només emprava una font d'entropia corresponent al nombre de procés (PID) els 32.000 valors possibles del qual no ofereixen suficient aleatorietat.

→ https://www.debian.org/security/2008/dsa-1571

Específicament, cada cop que s'usava l'OpenSSL per generar una clau, sempre generava una clau dins d'un conjunt conegut de centenars de milers de claus (32.000 multiplicat per un petit nombre de longituds de clau). Això va afectar les claus SSH, les claus SSL i els certificats X.509 utilitzats per nombroses aplicacions, com OpenVPN. Un «cracker» només havia de provar totes les claus per obtenir accés no autoritzat. Per reduir l'impacte del problema, el dimoni SSH es va modificar per rebutjar les claus problemàtiques que s'enumeren en els paquets opensh-blacklist i opensh-blacklist-extra. Addicionalment, l'ordre ssh-vulnkey permet la identificació de possibles claus compromeses al sistema.

Una anàlisi més exhaustiva d'aquest incident posa de manifest que és el resultat de múltiples (petits) problemes, tant dins del projecte OpenSSL com amb el mantenidor del paquet Debian. Una llibreria àmpliament usada com l'OpenSSL no hauria — sense haver-se modificat — de generar avisos quan es prova amb vagrind. A més, el codi (especialment les parts tan sensibles com el RNG) hauria d'estar millor comentat per evitar aquests errors. Per part de Debian, el mantenidor volia validar les modificacions amb els desenvolupadors de l'OpenSSL, però simplement va explicar les modificacions sense proporcionar el pedaç corresponent per revisar, i no va esmentar el seu paper dins de Debian. Finalment, les decisions de manteniment van ser “subòptimes”: els canvis fets al codi original no estaven clarament documentats; totes les modificacions es van desar efectivament en un repositori Subversion, però van acabar tots en un sol pedaç durant la creació del paquet d'origen.

En aquestes condicions és difícil trobar les mesures correctives per a evitar que aquests incidents es repeteixin. La lliçó que s'ha d'aprendre aquí és que cada divergència que Debian introdueix al programari original ha d'estar justificada, documentada, presentada al projecte original quan sigui possible, i àmpliament divulgada. Des d'aquesta perspectiva es va desenvolupar el nou format de paquet de fonts (“3.0 (quilt)”) i el servei web de les fonts de Debian fou desenvolupat.

→ https://sources.debian.org

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. Usar aplicacions X11 remotes

El protocol SSH permet la redirecció de dades gràfiques (sessió “X11”, pel nom del sistema gràfic més estès a Unix); el servidor manté un canal dedicat per a aquestes dades. Específicament, un programa gràfic executat remotament es pot mostrar al servidor X.org de la pantalla local, i tota la sessió (entrada i pantalla) serà segura. Com que aquesta característica permet que les aplicacions remotes interfereixin amb el sistema local, no està habilitada per defecte. Podeu habilitar-la especificant X11Forwarding yes al fitxer de configuració del servidor (/etc/ssh/sshd_config). Finalment, l'usuari també ho ha de sol·licitar afegint l'opció -X a la línia d'ordres de l'ssh.

ANANT MÉS ENLLÀ “galetes” màgiques a .Xauthority

Quan un usuari es connecta a través d'SSH i inicia una sessió remota X11, es crea el que s'anomena magic cookie (“galeta màgica”) i s'emmagatzema al fitxer .Xauthority al directori inicial de l'usuari que ha iniciat la connexió. Aquesta galeta és utilitzada per xauth per autenticar l'usuari durant la sessió X. Si l'usuari suplanta un altre usuari del sistema, per exemple utilitzant su o sudo, llavors la galeta no es copia automàticament a l'usuari de destinació i el servidor X refusarà iniciar aplicacions gràfiques sota el context de l'usuari de destinació. Haureu de copiar la galeta màgica al directori inicial de l'usuari de destinació (exportant i reimportant la galeta mitjançant xauth) per permetre que un altre usuari iniciï programes gràfics també durant la sessió X.

9.2.1.4. 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.

VOCABULARI Túnel

Internet, i la majoria de les xarxes locals (LAN) que hi estan connectades, operen en mode de paquets i no en mode de connexió, el que significa que un paquet emès d'un ordinador a un altre s'aturarà en diversos encaminadors intermedis per trobar un camí a la destinació. Tot i així, podeu simular una operació connectada on el flux s'encapsula en paquets IP normals. Aquests paquets segueixen la seva ruta habitual, però el flux es reconstrueix sense canvis a l'arribada. Anomenem això un “túnel”, analogament a un túnel de carretera en el qual els vehicles condueixen directament des de l'entrada (entrada) a la sortida (sortida) sense trobar interseccions, en contraposició a un camí en la superfície que implicaria interseccions i una direcció canviant.

Es pot utilitzar aquesta oportunitat per afegir xifratge al túnel: el flux que corre a través d'ell esdevé llavors irrecognoscible des de l'exterior, però es retorna en forma desencriptada a la sortida del túnel.

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.

Figura 9.3. Reenviament d'un port local amb SSH

Figura 9.4. Reenviament d'un port local amb SSH

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 Paràmetres → Compartició (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ú K → Internet → Client d'escriptori remot). 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.

SEGURETAT VNC sobre SSH

Si us voleu connectar usant VNC, però no voleu que les vostres dades s'enviïn en text clar a la xarxa, és possible encapsular les dades en un túnel SSH (vegeu Secció 9.2.1.4, «Creació de túnels encriptats amb reenviament de ports»). Senzillament cal saber que VNC utilitza per defecte el port 5900 per a la primera pantalla (anomenada “localhost:0”), 5901 per a la segona (anomenada "localhost:1"), etc.

L'ordre ssh -L localhost:5901:localhost:5900 -N -T equip crea un túnel entre el port local 5901 a la interfície «localhost» i el port 5900 de la màquina equip. El primer «localhost» restringeix SSH a escoltar només aquesta interfície a la màquina local. El segon “localhost” indica la interfície de la màquina remota que rebrà el trànsit de xarxa entrant a “localhost:5901”. Així, vncviewer localhost:1 connectarà el client VNC a la pantalla remota, tot i que heu indicat el nom de la màquina local.

Quan tanqueu la sessió VNC, recordeu també tancar el túnel sortint de la corresponent sessió SSH.