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.
Solucione los problemas de OOM de Matrix Synapse durante /sync comprobando la presión de la memoria, ajustando cuidadosamente las cachés, aislando la sincronización inicial y supervisando los procesos de trabajo.
Habilite el cifrado del lado del servidor de Nextcloud de forma segura con el modo de clave maestra, el bloqueo APCu, Redis o Valkey, y un despliegue gradual que minimice el impacto en el rendimiento.
Solucione los errores de administrador de sala Matrix M_FORBIDDEN comprobando la membresía, los niveles de poder, el rango del usuario objetivo y las opciones de recuperación del administrador del servidor Synapse, como make_room_admin.
¿Tu correo web de Zimbra acepta tu inicio de sesión pero muestra una página en blanco? Separa los problemas del navegador de los fallos del buzón o del proxy, revisa los registros correspondientes y verifica la recuperación de forma segura.
Detecta el problema del servicio Jitsi Meet que se queda atascado reiniciándose, lee el registro de errores y soluciona las causas comunes de Docker, como contraseñas faltantes, montajes incorrectos y configuraciones incompatibles.
Aprende en qué se diferencia la autenticación de cuentas de Jitsi Meet de las contraseñas de sala, configura el método de dominio seguro heredado y verifica los controles de acceso de forma segura.
Solucione los problemas con las tareas en segundo plano de ownCloud que no se ejecutan cambiando al modo Cron y programando occ system:cron con un temporizador systemd; a continuación, verifique el temporizador y los registros.
Monta un bucket de Amazon S3 como almacenamiento externo en ownCloud Server 10. Habilita el backend, configura las credenciales y las opciones de punto final, restringe el acceso y verifica la conexión.
Aprenda a diagnosticar la corrupción del índice de búsqueda de buzones de Zimbra, a ejecutar zmprov rim de forma segura, a supervisar el progreso, a verificar los resultados y a saber cuándo la reindexación no es suficiente.
Configure la federación de Matrix Synapse con HTTPS, DNS, un proxy inverso, delegación de servidor, reglas de firewall y pruebas de federación. Incluye ejemplos de configuración verificados.
