Jitsi Meet cuenta con dos controles de protección independientes: la autenticación del servidor determina quién puede crear una reunión, mientras que la contraseña de la sala impide que quienes la desconozcan se unan. Estos controles resuelven problemas distintos. En un servidor autohospedado, la configuración anterior de "dominio seguro" de Prosody puede requerir un nombre de usuario y una contraseña para crear salas, permitiendo a la vez la entrada de invitados. El manual actual de Jitsi indica que este método está obsoleto para nuevas instalaciones y recomienda la autenticación basada en tokens. Los administradores actuales pueden usar el procedimiento que se describe a continuación como guía de compatibilidad, pero deben planificar las nuevas implementaciones en función de una configuración de token o proveedor de identidad compatible.
Las contraseñas de sala son una función independiente que se utiliza durante la reunión y resultan útiles junto con la autenticación del servidor. Establezca una contraseña después de que la sala haya comenzado, compártala a través de un canal privado y pruebe el proceso de acceso desde un segundo navegador antes de invitar a los participantes.
| Meta | Usar | Lo que hace |
|---|---|---|
| Controla quién puede crear salas | Autenticación del servidor | Se requiere una cuenta o token de Jitsi aprobado para crear una sala. Dependiendo de la configuración de los invitados, otras personas podrían unirse como invitados. |
| Mantenga la privacidad de una habitación existente. | Contraseña de la habitación | Requiere que quienes se unan después de que se haya establecido la contraseña la ingresen. No elimina a los participantes que ya se encuentran en la sala. |
| Mantenga a los huéspedes hasta que llegue el anfitrión. | Función de sala de espera o de espera del anfitrión | Añade un paso de admisión independiente. La contraseña de la habitación por sí sola no establece la identidad ni verifica quién la recibió. |
Para una reunión pequeña, un nombre de sala único y una contraseña pueden ser suficientes. Si su organización necesita crear salas mediante cuentas, configure también la autenticación del servidor. Para implementaciones nuevas autoalojadas, revise la guía de autenticación actual de Jitsi y la configuración de autenticación por token correspondiente antes de elegir una implementación.
Inicie la reunión, abra el menú de seguridad u opciones de reunión en la barra de herramientas, seleccione la opción de contraseña e ingrese una contraseña segura para la sala. El nombre y el icono del menú pueden variar según la versión del cliente. Si la reunión ya está en curso, establecer una contraseña afectará a las futuras incorporaciones; las personas que ya hayan entrado no serán eliminadas automáticamente. Envíe la contraseña por separado del enlace de la reunión cuando la confidencialidad sea importante.
Las preguntas frecuentes de Jitsi explican que la contraseña de una sala se elimina al finalizar la reunión, por lo que no se debe asumir que las reuniones recurrentes la conservan. Configúrela de nuevo para cada reunión nueva y verifique su comportamiento en su propia implementación. Cualquier persona que reciba o a la que se le reenvíe la contraseña podría acceder, por lo que una contraseña no es lo mismo que una lista de acceso de usuarios con nombre. Consulte las preguntas frecuentes oficiales de Jitsi sobre la protección de reuniones .
En el diseño clásico de "dominio seguro", Prosody autentica a los creadores de salas con cuentas locales. Jitsi permite que los participantes no autenticados se conecten a través de un dominio de invitado. Esto resulta útil cuando solo el personal debe crear salas, pero los asistentes no necesitan cuentas. No obliga a todos los participantes a iniciar sesión. Si todos los usuarios deben autenticarse, el acceso de invitado debe deshabilitarse o reemplazarse por la política de identidad y acceso de su sistema de autenticación actual.
La documentación de Jitsi indica que este método antiguo de dominio seguro está obsoleto para nuevas instalaciones. Continúe solo si comprende esta limitación y mantiene un servidor compatible existente. Antes de editar, identifique cómo se instaló Jitsi, anote el nombre de host de Jitsi Meet, haga una copia de seguridad de los archivos de configuración de Prosody, Jicofo y web, y mantenga una sesión de administrador o consola activa disponible en caso de que un error de sintaxis interrumpa el servicio.
Abra el archivo Prosody correspondiente a su nombre de host Jitsi, normalmente /etc/prosody/conf.avail/jitsi.example.com.cfg.lua. Reemplace el nombre de host de ejemplo que aparece a continuación con el dominio real. En el host virtual principal, cambie el modo de autenticación a contraseñas internas cifradas. Añada el host virtual invitado a continuación:
VirtualHost "jitsi.example.com"
authentication = "internal_hashed"
VirtualHost "guest.jitsi.example.com"
authentication = "jitsi-anonymous"
c2s_require_encryption = falseConservar las demás opciones y módulos existentes. No crear registros DNS ni un certificado público para guest.jitsi.example.com; en esta configuración es un dominio interno de Jitsi.
Abra el objeto existente /etc/jitsi/meet/jitsi.example.com-config.jsy agréguelo dentro del mismo . Conserve las entradas existentes y las demás, y revise cuidadosamente las comas:anonymousdomainhostsdomain
hosts: {
domain: 'jitsi.example.com',
anonymousdomain: 'guest.jitsi.example.com'
},Editar /etc/jitsi/jicofo/jicofo.conf. Agregue la configuración de autenticación dentro de su bloque existente jicofo; no cree un bloque de nivel superior duplicado:
jicofo {
authentication {
enabled = true
type = XMPP
login-url = "jitsi.example.com"
}
}Si el archivo ya contiene una jicofosección, incorpore estas propiedades. La sintaxis de configuración y los archivos generados pueden variar según la versión del paquete, por lo que conviene comparar el resultado con la página del manual correspondiente a su instalación antes de reiniciar los servicios.
Tras comprobar los cambios, reinicie los servicios como administrador:
sudo systemctl restart prosody
sudo systemctl restart jicofo
sudo systemctl restart jitsi-videobridge2Regístrate como creador de salas en Prosody. Sustituye los marcadores de posición; nunca uses el dominio de ejemplo ni una contraseña débil en un servidor en producción.
sudo prosodyctl register <username> jitsi.example.com <strong-password>Cada cuenta está asociada al nombre de host de Jitsi. Cree cuentas individuales en lugar de compartir una única credencial de administrador si necesita revocar el acceso posteriormente. La documentación de dominio seguro de Jitsi enumera las rutas de configuración específicas del paquete y el comando de registro. También indica explícitamente que este método está obsoleto.
No edite archivos dentro de contenedores en ejecución ni copie las rutas de los paquetes Debian en una implementación de Docker. En la configuración oficial de Docker Compose, la autenticación se configura mediante el archivo de entorno de la implementación. El manual documenta estos valores relevantes para la autenticación de cuentas internas:
ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internalMantén habilitado el acceso de invitados si los asistentes deben poder unirse sin tener una cuenta propia. Con el acceso de invitados habilitado, los usuarios no autenticados pueden unirse según el comportamiento de invitados configurado; no se convierten en creadores de salas autenticados. Aplica los cambios de entorno mediante el flujo de trabajo de Compose para tu implementación e inspecciona los registros si los servicios no se inician correctamente.
Cree un usuario interno a través del servicio Prosody en lugar de modificar la configuración del contenedor generado. El manual oficial muestra cómo abrir una consola en el contenedor Prosody y registrar un usuario con prosodyctl. La ruta de configuración y el dominio XMPP dependen de la versión de Compose; en la imagen Docker documentada, la configuración de Prosody se encuentra en /config/prosody.cfg.lua, y el dominio XMPP de ejemplo es meet.jitsi. Utilice el comando y los valores exactos documentados para su versión descargada. Consulte la guía oficial de Docker para autoalojamiento para obtener información sobre variables de entorno, creación de cuentas y comportamiento de la configuración generada.
Si no aparece la solicitud de inicio de sesión, revise los nombres de host de Prosody, el bloque Jicofo, anonymousdomainel valor del cliente y los registros de servicio. Un error de configuración común es usar un dominio de invitado que no coincide entre Prosody y el servidor config.js, o agregar un segundo bloque Jicofo en lugar de extender el existente. Si los invitados no pueden unirse, verifique que el acceso de invitados se haya habilitado intencionalmente y que el dominio de invitado configurado coincida con el nombre de host principal.
No inicie una nueva implementación con la receta de dominio seguro obsoleta a menos que tenga una razón específica de compatibilidad. El material actual de Jitsi para el autoalojamiento recomienda la autenticación por token para las nuevas instalaciones, mientras que su guía de autenticación más amplia documenta la integración de proveedores de identidad más recientes. Estos enfoques requieren configuración adicional del emisor, la firma o el proveedor de identidad; no son intercambiables con una contraseña de sala de Prosody. Elija el modelo que se ajuste a sus requisitos y, a continuación, utilice contraseñas de sala o un lobby como controles independientes a nivel de reunión cuando corresponda.
En resumen: usa la autenticación por cuenta o token para controlar quién puede crear salas y establece una contraseña para restringir el acceso posterior a quienes la conozcan. Prueba ambas opciones de forma independiente, ya que habilitar una no habilita automáticamente la otra.
Compara 10 herramientas de escaneo de ping para la detección rápida de redes LAN, el escaneo multiplataforma y la gestión de direcciones IP. Descubre qué puede (y qué no puede) revelarte un escaneo.
Compare seis herramientas de gestión de red para la monitorización del rendimiento, incluyendo la cobertura SNMP, la asignación de mapas, las alertas, los modelos de implementación y las ventajas y desventajas en cuanto a costes.
Compara las mejores aplicaciones de análisis Wi-Fi para Windows, iPhone y Android, incluyendo herramientas para la congestión de canales, la cobertura de la señal, los mapas de calor y la resolución de problemas de red.
Compara siete monitores de ping gratuitos y de código abierto, desde suites de red completas hasta sondas de latencia específicas, y elige el que mejor se adapte a tus necesidades en cuanto a disponibilidad, pérdida de paquetes e historial.
Aprenda qué significa QoS en redes, cómo las marcas DSCP y las colas de tráfico priorizan las aplicaciones de voz, vídeo y empresariales, y qué problemas no puede solucionar la QoS.
Compare siete herramientas de administración de direcciones IP para el descubrimiento de subredes, la coordinación de DNS y DHCP, el inventario de red y la gestión de direcciones IP de código abierto.
Compara software de servidor SFTP fiable para Windows y Linux, incluyendo OpenSSH, Bitvise, SolarWinds y SFTPGo. Encuentra la solución ideal para tus necesidades de seguridad y transferencia de archivos.
Cree un sistema práctico de monitorización de red con una cobertura clara de los dispositivos, métricas de rendimiento útiles, alertas procesables y una comparación de SolarWinds NPM, PRTG y OpManager.
Compare las herramientas de escaneo de red para la detección rápida de dispositivos, escaneos de IP multiplataforma y gestión de direcciones IP (IPAM) empresariales, con orientación sobre cómo adaptar cada opción a su red.
Utilice la opción --traceroute de Nmap para asignar saltos a un host autorizado, comprender la salida de saltos y RTT, y solucionar problemas de respuestas faltantes sin realizar un escaneo excesivo.
