SASLError using SCRAM-SHA-1: not-authorized - on Debian buster system with existing prosody

sudo apt-get purge jigasi jitsi-meet jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-turnserver jitsi-meet-web jicofo jitsi-videobridge2

As from

No errors from purge

Just wanted to report that this did not solve the problem for me.

Quick Install on a clean Ubuntu 18.04

I am not sure what fixed it in the end, unfortunately. I fired up an internal test VM, using KVM on my home machine - with slightly mixed results - I suspect as it did not have a real certificate (and being on a 192.168 address behind NAT, but with other systems already using the 443 port it would be tricky to get one. I compared its clean install values with those on my externally hosted server, and could not see anything which could be the problem, so I rebooted my server and after the reboot it seems to be working, so I am going to start inviting people to meetings to test

Thank you so much for your help

I have the exact same problem on a linux mint 18.3 machine. Trying to run it next to an existing website as
Tried installing it on a seperate server also running mint 18.3 with same result.

says no users setup! Do I need to create one?
prosodyctl passwd

Hi, guys, thanks for your support so far. I’ve ran in to this issue as well after the upgrade from jvb to jvb2 (stable debian packages) and indeed prosody passwd resolved this error. However, a new one arose: The jvb log now shows:

org.jivesoftware.smack.SmackException: No supported and enabled SASL Mechanism provided by server. Server announced mechanisms: . Registered SASL mechanisms with Smack: [SASL Mech: GSSAPI, Prio: 100, SASL Mech: SCRAM-SHA-1-PLUS, Prio: 100, SASL Mech: SCRAM-SHA-1, Prio: 110, SASL Mech: DIGEST-MD5, Prio: 200, SASL Mech: CRAM-MD5, Prio: 300, SASL Mech: PLAIN, Prio: 400, SASL Mech: X-OAUTH2, Prio: 410, SASL Mech: EXTERNAL, Prio: 500, SASL Mech: ANONYMOUS, Prio: 500]. Enabled SASL mechanisms for this connection: null. Blacklisted SASL mechanisms: [SCRAM-SHA-1-PLUS].

The end result by the way is just the same: No video bridge, so no video conference. Participants get kicked out.

This happens on an (upgraded) debian stable package (now with videobridge2).

Our setup is using SSL offloading at the loadbalancer so the prosody does not have the ‘real’ certificate, just a bunch of snakeoil - Feels like that might be related. I did set org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true

Hope the community can provide a hint as to how I can resolve this?


Have you checked prosody logs for errors?

@florianoverkamp When you did the upgrade, which prosody version were you running? Have you created the jvb user in the past?

@damencho thanks for following up.

  • Yes the jvb user was already created with the previous stable release, so from jvb1.
  • The prosody logs did not show any errors, here is a snippet when starting jvb2:
Mar 31 09:26:37 warn Session filters applied
Mar 31 09:26:37 c2s562a9ed25f70 info Client connected
Mar 31 09:26:37 c2s562a9ed25f70 info Stream encrypted (TLSv1.3 with TLS_AES_256_GCM_SHA384)
Mar 31 09:26:37 c2s562a9ed25f70 info Authenticated as

Then things got weird. I think I left the jvb2 down for about a minute, before restarting, and now I can no longer reproduce the error. Some stale sessions maybe?

Did I mention I hate it when things ‘magically’ start working again? Anyhow, thanks, and if I find this issue again I’ll follow up…

Hi, I can confirm your exactly same problem and your exactly same solution (randomness).

Broken from 2 days, this morning:

  • commented the server section in


  • restart nginx
  • changed jvb password in my previous local installation (first time I tried) and my current installation (already tried many times)

prosodyctl passwd jvb@auth.mylocalip
The host ‘auth.mylocalip’ is not listed in the configuration file (or is not enabled).
The user will not be able to log in until this is changed.

prosodyctl passwd

  • I restarted every related service and after some times it works
1 Like

Thanks for the solution Oquegfapziofh!
I’m very puzzled what caused this time the problem of passwords not matching. That shouldn’t happen since I reinstalled all completely — actually many times from stable repository i.e. everything should have been initialized. Weird.
I have two setups: One installed earlier & in good shape while this time the installation was really pain. I can’t understand what was changed in the mean time. Both servers are exactly same Ubuntu 18.04.4 LTS. The other server is actually 100% clone of the first server image, just domain etc updated.

About visible symptom of my problem: First user was able to connect, the next one connecting killed both.

How i solved (seems to) this problem , if it can help
my case: i updated to JVB2 on a debian 10, 2 days ago. (and prosody to 11.5)
Its not the password that is wrong, it’s may be the user !

I had the same error in prosodylog, loop of disconnexion

my subdomain is, in secure_domain

then i saw after trying many other things (but its in red in my nano ) that in a part (at the end) that was not in my JVB1 config !!! :
and most important: with demo admin user !!!

admins = { "", "" }

=> “focusUser@” => my old config was “focus@”

so i corrected and restart :

Component "" "muc"
    storage = "memory"
    modules_enabled = { "ping"; }
    admins = { "", "" }

it worked for me

1 Like

Finally this solved our issue…Thank you.
@damencho please note that there should be an issue with the auto-configuration when using quick install.
that’s why the passwords are incorrect.

Not sure what to adjust now and where to run the prosodyctl against … with what password, the one in /etc/jitsi/videobridge/config?

The snippet for the muc is already at focus@ and jvb@ (storage=none though).

@sanjayas What we found and it is already fixed:


Installed new version and now it works! :blush:

1 Like

I had the same problem when updating. I think this error might arise if your jvb config is not the ‘default’ one and/or have been tweaked after installing coturn.

The easiest fix would be to open both:

And search for the line that says:

Make sure it matches with the one in

restart the service and profit!


Tnx, that helps (and works), now on to fixing other issues we have with one of our installs (the jvb2 one)

Thank you. It is works for me. :slightly_smiling_face:

So summarizing:

rm -rf /var/lib/prosody/auth%2eyourdomain%2eorg

or for the brave simply:

rm -rf /var/lib/prosody/*%2e*

It removes incompatible cruft from prosody and it works again the next time.