Instalar y configurar Jitsi de forma más segura

Hace unos días publiqué una entrada sobre la instalación de Jitsi en un servidor propio. Aunque conseguí llegar a ello, me quedaron muchas dudas sobre sel funcionamiento de la parte más privada, porqué no funcionaban bien la parte de usuario y contraseña… en fin, muchas dudas.

Tras unas cuantas horas y experimentos más, ya lo tengo bastante más claro. Por un lado, toda la documentación explica que montes un sistema cerrado, y a la vez que también tengas uno abierto. La verdad es que lo veo bastante inútil ya que si quieres tener una versión cerrada, probablemente no quieras tener una abierta. Aún así, voy a explicar parte de esta opción en este nuevo manual.

Por otro lado, lo que también me ha quedado claro es que Jitsi es un sistema pobre en cuanto a determinada funcionalidad y control de la plataforma. Es algo generalista pensado para que mucha gente entre y haga lo que quiera con auto-control. Esto significa que a la hora de moderar las salas la cosa se complica. En resumen: peca de falta de funcionalidad (a mi parecer). Incluso, hablando con alguna gente la conclusión era aprovechar funcionalidad de nginx para limitar determinadas cosas, que es una buena idea, pero dice poco de Jitsi.

Configurando el sistema

La configuración básica será sobre Ubuntu 18… en esta parte no voy a entrar mucho en detalle.

$ timedatectl set-timezone UTC
$ timedatectl set-ntp on
$ apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove
$ apt -y install software-properties-common curl vim

Instalamos nginx

Lo mismo, poco voy a explicar aquí.

$ add-apt-repository -y ppa:ondrej/nginx
$ apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove
$ apt -y install nginx
$ systemctl stop nginx.service
$ systemctl enable nginx.service
$ systemctl start nginx.service

Instalación de Jitsi

Sigo un poco la linea, aquí tampoco hay mucho misterio…

$ wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
$ sh -c "echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list"
$ apt -y update && apt -y upgrade && apt -y dist-upgrade && apt -y autoremove
$ apt -y install apt-transport-https jitsi-meet

En el proceso se nos pedirá un dominio (en principio ese dominio, o subdominio, será el que se utilice para «la versión segura», es decir, la que tenga usuarios autenticados. En este ejemplo voy a usar chat.example.com.

Además, como en la ocasión anterior, generaremos un auto-certificado… ya cambiará la cosa, que aquí ha sido otro de los sitios en los que me he estancado bastante.

Configurando Jitsi

Una previa

A partir de aquí empieza un poco lo bueno. Voy a intentar hacer una parada previa para conceptualizar lo que habitualmente ocurre cuando se lee la documentación oficial o la de otra gente (incluso las pruebas que yo había hecho).

Por defecto Jitsi viene pensado para usarse en un sitio. Este sitio por defecto es un sitio abierto al público, es decir, si instalas Jitsi «a pelo» lo que tienes es un sistema en el que cualquiera puede entrar y hacer todo «de forma ilimitada» (entre comillas). Vamos, un descontrol absoluto que no tiene mucho sentido si no es para una red interna, porque dejarlo abierto al público e Internet es un sinsentido.

Por otro lado, habitualmente en los manuales que hay por ahí, justo tras la conversión a un sistema con contraseña, se te invita a explicar cómo configurar un sitio alternativo «en abierto», de forma que, a diferencia de lo que se pueda pensar (que un sitio es para usuarios registrados, y el otro es lo mismo, pero abierto a todos en el que se pueda hacer pero no controlar), en realidad estamos montando dos proyectos, uno abierto y uno cerrado. Aquí me he encontrado mayormente el error y el descontrol. Y reconozco que incluso, haciendo este manual he tenido algunas idas y venidas para entenderlo (y al final, era lo más sencillo).

Por otra parte, la documentación es una locura… el fichero de configuración viene con casi todo comentado y las distintas veces que he entrado ni me había dado cuenta de que la mitad de las cosas de ahí eran opciones. Voy a intentar comentar algunas de estas opciones, aunque lo mejor es entrar en el fichero y repasar todo y activar y desactivar lo que te interese.

Que conste que, después de muchas pruebas, es más simple de lo que lo estaba haciendo (because, why not?)

Adaptando el sistema para crecer

Lo primero que vamos a hacer es retocar un poco el propio Linux.

$ vim /etc/systemd/system.conf

Allí buscaremos estas opciones y les daremos valor.

DefaultLimitNOFILE=65000
DefaultLimitNPROC=65000
DefaultTasksMax=65000

Gracias a esto podremos tener más de 100 usuarios concurrentes en el servidor.

Activando la seguridad (y más)

Lo siguiente que vamos a hacer es decirle al sistema que nuestro sitio va a permitir autenticación. Esto no significa que todos los usuarios tengan que loguearse, si no que para entrar en un canal deberá haber previamente un moderador que necesitará usuario y contraseña de la plataforma.

$ vim /etc/prosody/conf.avail/chat.example.com.cfg.lua

En este fichero veremos que hay un primer VirtualHost y que tiene activado el sistema de autenticación como «anónimo». Lo que haremos es cambiarlo para que tenga la opción de usuarios registrados.

VirtualHost "chat.example.com"
  authentication = "internal_plain"

Pero.

Y aquí es donde vienen las habituales explicaciones paralelas. En todos los manuales siempre te dicen que añadas otro VirtualHost para dejarlo anónimo. Lo importante de esto es que es información interna, por lo que en realidad no es necesario que apuntes DNS ni nada parecido… ese subdominio en realidad no existe (y he de reconocer que esto a mi me estaba confundiendo).

En el caso de que sea así, puedes añadir otro VirtualHost tal que este (para el ejemplo usaré open.chat.example.com):

VirtualHost "open.chat.example.com"
  authentication = "anonymous"
  c2s_require_encryption = false

De esta forma, y que quede claro, el planteamiento es que parece que haya dos sitios, aunque en realidad sólo hay uno, el principal bajo chat.example.com.

Configurando el software en sí

Aquí comienza parte de la chicha. El fichero de configuración del propio Jitsi. Aquí podemos activar y desactivar ciertas funcionalidades. No voy a complicarme mucho, que conste, pero voy a intentar que sea funcional.

Para empezar, abriremos el fichero de configuración.

$ vim /etc/jitsi/meet/chat.example.com-config.js

Lo primero, configuraremos el sudbominio para la gestión interna, hay que añadir esto:

var config = {
  hosts: {
    anonymousdomain: "open.chat.example.com"
  }

Aquí sí que comienza a ser interesante algunas de las opciones. Lo más recomendable es leer su descripción, no nos vamos a engañar… que dentro de lo poco que hay, está comentado.

var config = {
  startSilent: true,
  constraints: {
    video: {
      height: {
        ideal: 480,
        max: 720,
        min: 360
      }
    }
  },
  transcribingEnabled: true,
  useIPv6: true,
  requireDisplayName: true, 
  enableClosePage: true,
  defaultLanguage: 'es',
  enableUserRolesBasedOnToken: true,
  enableFeaturesBasedOnToken: true, 
  lockRoomGuestEnabled: true,
  deploymentInfo: {
    region: "europe",
  },     
  doNotStoreRoom: true,

No voy a entrar mucho en las configuraciones, como digo, ya está documentado en el propio fichero, así que cualquier duda, vais a la sección concreta y leéis lo que es.

Activando el servidor de login

Lo siguiente que hemos de hacer, sí o sí, es activar el sistema de login para que funcione, ya que es un servicio paralelo al propio Jitsi.

Entraremos en este fichero:

$ vim /etc/jitsi/jicofo/sip-communicator.properties

Y añadiremos al final una nueva línea:

org.jitsi.jicofo.auth.URL=XMPP:chat.example.com

Con esto lo que estamos diciéndole es que ha de activar Jicofo como sistema de autenticación.

Creando el certificado para el dominio

Si no quieres complicarte mucho la vida, simplemente sigue las instrucciones…

$ /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

Activando la configuración y poniendo orden

En principio la parte de configuración del Jitsi ya está, pero no está aplicada… así que vamos a aplicarla. Para ello hay que reiniciar los distintos servicios:

$ systemctl restart prosody.service
$ systemctl restart jicofo.service
$ systemctl restart jitsi-videobridge2.service

Creando un usuario

Como el servidor de autenticación ya está activo, lo que podemos hacer antes de seguir es crear un primer usuario.

$ prosodyctl register javier chat.example.com contrasena

Un detalle a tener en cuenta… la contraseña, si le pones símbolos «raros» fallará, ya que no lo acaba de entender bien… así que te recomiendo una contraseña larga (36 caracteres estará bien) aunque sea sólo de mayúsculas, minúsculas y números, sin símbolos.

Cuando entremos en un canal, se nos pedirá un usuario y contraseña. En base a esto que hemos creado, los datos serían:

Usuario/Correo: javier@chat.example.com
Contraseña: contrasena

Hay que tener en cuenta que no es necesario que esta cuenta de correo exista de verdad… es un simple identificador de usuario.

Si queremos eliminar un usuario, deberemos ejecutar algo tal que así:

$ prosodyctl deluser javier@chat.example.com

Y en principio, con esto, ya tendrías acceso a tu sitio con Jitsi en el que sólo se puede entrar en un canal si hay un moderador previamente que lo haya creado. Para ello sólo habría que entrar en https://chat.example.com/.

Y hasta aquí la instalación y configuración… como digo, más sencillo de lo que puede parecer, aunque habría que darle un buen repaso a toda la configuración para encontrar detalles y hacer pruebas… y, espero, en un tiempo, poder hacerlas.

Categorías Internet

1 comentario en “Instalar y configurar Jitsi de forma más segura”

  1. Este post me ayudo a instalar Jitsi con autenticación. Pero ahora me sucede que ni el moderador ni los invitados pueden compartir pantalla. El mensaje que me sale es «Los huéspedes no pueden compartir la pantalla». ¿Te ha pasado?

    Responder

Deja un comentario