Jitsi is a video conferencing application that is fully open source, and allows you to easily build and deploy your own video conferencing server. This guide will show you how to set up a secure Vultr hosted virtual server that runs Jitsi – you can be video conferencing in less than an hour!
The first thing you need for this guide is an account set up with Vultr (or Digital Ocean) – if you click on the Vultr link below, you can sign up using my referral code which gets me a few bucks for the referral – thanks!
SPECIAL OFFER! With my Vultr link – you currently get $100.00 FREE CREDIT towards your virtual servers for signing up! Click the Vultr logo below or use this link: https://www.vultr.com/?ref=8473585-6G
*** NOTE: As I said, the rest of this document will be focused on a Vultr install. I will be keeping this guide up to date periodically as things change with the setup – check back if you ever find that something isn’t working, and comment below if you have any trouble with any of the steps!
Also – here’s a Digital Ocean referral link if that floats your boat (pun intended): https://m.do.co/c/6de2bc2df3b8
Already have a Vultr and/or Digital Ocean account? You can always:
Part 1 – Install Vultr Virtual Server
Log into Vultr and get to the main dashboard. Click on ‘Products’ from the left hand menu followed by the blue circled ‘+’ symbol in the upper right. This will bring you to the new server setup page.
Make sure you have selected ‘Cloud Compute’ and then select your location. Pick whichever data center you want – I however, tend to choose the data center closest to my (or my client’s) geographic location. In this case, I’m going to pick Seattle.
The next step is where we select our server type. Click on Ubuntu and choose ‘19.10 x64’ from the drop-down.
Next, select your server size. Jitsi will run on anything in the $5.00/month size or higher. For a production system with a lot of usage however, you may want to bump this up to a higher tier.
Finally, you can select any options (Auto Backups are highly recommended for a production server), and then give your server a hostname. Hostname should be something like jitsi.company.com. For our demo, we’re going to use jitsi.crosstalksolutions.com. This step is NOT optional – we’ll be using a Let’s Encrypt certificate to secure HTTPS access to this server.
Click ‘Deploy Now’ and you’re off to the races! You are taken back to the server summary screen. It will take 1-2 minutes for the server to spin up, so be patient. Once the ‘Status’ changes from ‘Installing’ to ‘Running,’ you should wait about another 30 seconds, and then you’re good to go. Click on the name of your server to see its detail screen.
Once the server is in a ‘Running’ state, you’ll see your IP address. Copy or make note of that IP address – we’re going to use it to create our DNS A record in the next step. You’ll also want to make note of or copy your default root password. (We will change that password immediately upon logging in). You can show the password by clicking the ‘eye’ icon, or simply copy it to your clipboard by clicking the copy icon.
Part 2 – Create DNS A Record
Since you now know your IP address, you should log into your DNS hosting provider or DNS server and create a new A record that points the hostname that you created in Step 1 to the IP address of your Vultr server. This will be needed in the future to connect to the server and to set up Let’s Encrypt.
Part 3 – Log into your new server
At this point, you should have your Vultr username (root) and password from the server details. Copy the password to your clipboard and then open up PuTTY.
Enter in the IP address or hostname of your server and then click ‘Open.’
PuTTY will open up a terminal window and first ask you if you want to accept the new host (click ‘YES’). Then you will be given a login prompt. Use the information from the Vultr server properties:
User: root
Password: (the password from the Vultr server properties – you can do SHIFT+INS or right-click to paste it in)
The very first thing that you should do is change your root password.
passwd root
You will be asked to enter your root password twice – make sure it is a STRONG password. We will be disabling root access to this box later in this guide, but you will still need to know the root password in order to run sudo commands.
Part 4 – Create New User
Most Linux machines in the world have root as the default user. The first line of defense is to create a separate login account with the same privileges and then disable root.
Start by creating a new user – for simplicity, for this exercise, our username will be ‘jitsiadmin‘:
adduser jitsiadmin
This command will have you set a password for the new user, and you can also optionally enter in some additional information such as their real name and contact info.
Next give root (sudo group) privileges to the newly created user:
usermod -aG sudo jitsiadmin
This new user will now be able to use the ‘sudo’ command to run commands as root.
At this point, we have created our new user, but we haven’t yet disabled root – we will do that in a moment. First, we will enable private key authentication as a second line of defense.
Part 5 – Create Private Key Pair
Let’s now create our public and private key pair. The public key lives on the server, and the private key will be used to unlock access from any device that needs it.
ssh-keygen
When asked where to put the file, take the default. You can choose whether or not to enter in a passphrase – having a passphrase means that you need both the private key and passphrase to gain access. It provides an additional layer of security.
Once your keys have been created, you will find them in /home/root/.ssh – there should be id_rsa (private key) and id_rsa.pub (public key) files in that directory.
Next, we need to copy that key to the newly created user’s account:
ssh-copy-id jitsiadmin@[server IP]
Choose ‘yes’ when asked if you want to continue, and enter jitsiadmin’s password when prompted.
This command will copy the public key to the jitsiadmin user’s ~/.ssh directory as an authorized_keys file. You can now use the private key to authenticate with this server as user jitsiadmin.
Part 6 – Modify SSH Settings
The next step is to modify the SSH settings so that we will both disable root user access and password authentication. Start by editing the SSH configuration file:
nano -w /etc/ssh/sshd_config
Start by changing the default SSH port from 22 to something non-standard.
Find the line that says:
#Port 22
And change it to:
Port [different port number]
You can use any port number for your SSH connection, but I typically use port 2222 when I change to something non-standard.
Now scroll down until you find the line that says:
PermitRootLogin yes
And change ‘yes’ to ‘no’:
PermitRootLogin no
This disables root user login. Next scroll down further and find:
#PasswordAuthentication yes
Remove the # at the beginning and again change ‘yes’ to ‘no’:
PasswordAuthentication no
This disables password based authentication. (Private key authentication should already be enabled by default – you can verify this by ensuring that PubkeyAuthentication is set to ‘yes’ in the SSH config file).
Press CTRL+X followed by ‘Y’ and ‘Enter’ to save and exit.
*** NOTE: This next command commits these changes. If you lose connectivity because you made any mistakes, you should just destroy the Vultr server and start over. ALSO – keep this original PuTTY session open as you go through the next few steps…even after we restart SSH, this session will still be connected, so if you can’t connect in with the private key, you still have the opportunity to make changes.
Restart SSH with:
systemctl reload sshd
Part 7 – Download Private Key File
Now we need to download our private key file. Start by showing the contents of the id_rsa file:
cat ~/.ssh/id_rsa
Select the entire contents of the file with your mouse and press CTRL+INS to copy the text to your clipboard.
Next, open up a text editor such as Notepad and paste the entire block of text into a blank file. Save this file in a secure location.
Once saved, you can delete the id_rsa file from the server (though, you should probably test connectivity first if this is your first time making these changes):
rm ~/.ssh/id_rsa
Part 8 – Covert Private Key to PuTTY format
Before you can use your private key with PuTTY, you need to convert it to .PPK format. To do this, we’ll use another free program from the creators of PuTTY called PuTTYgen (you can download it from the same link as PuTTY above).
First, run PuTTYgen and click the ‘Load’ button. Browse to the private key file that you saved in step 7. When browsing for your private key, change the file type you are searching for from ‘PuTTY Private Key Files (*.ppk)’ to ‘All Files (*.*).’
Open your private key file, and you should receive a notice that the private key was successfully imported. Click OK to get off of this notification.
Now, click the ‘Save private key’ button and save your private key as a .ppk file (I usually just use the same directory that I used to save the original private key). You can now close PuTTYgen.
Part 9 – Log in as New User
Start a new PuTTY session – you can do this from the existing window by clicking the PuTTY icon in the upper left-hand corner and choosing ‘New Session.’
In the PuTTY window, enter the hostname of the server in the Host Name field and also change the SSH port to the port you changed SSH to in Part 6 of this guide.
Then, in the left-hand menu, expand the ‘SSH’ section underneath ‘Connection.’ Then click on ‘Auth.’ Here you will see a place to browse to your PuTTY .PPK private key file. Click ‘Browse…’ and find the .PPK file we created in Part 8.
Once you have the file loaded, click back on ‘Session’ at the top of the left-hand menu.
If you want to SAVE these connection details, you should now enter in a friendly name into the ‘Saved Sessions’ box and click the ‘Save.’ button.
Now click ‘Open,’ and you should get a ‘Login as:’ prompt. Enter in the name of the user that you created in Part 4 (in our case, it was jitsiadmin) and you should now connect to the server. If you have a passphrase on your private key pair, you will also be prompted for that passphrase.
Part 10 – Enable UFW Firewall
At this point, we have now secured our SSH connection pretty well. Now, let’s secure our server even more by using some firewall rules to lock everything down.
Ubuntu uses the UFW firewall, however it is not enabled by default. First, we are going to add all of the firewall rules that we need to connect to Jitsi, and then we will turn it on.
First, let’s allow our new SSH port and lock it down so that connections to this port are only allowed from our IP address:
sudo ufw allow from [IP address] to any port [SSH port number]
In this example, if your IP address is 1.2.3.4, and your SSH port is 2222, the command should be:
sudo ufw allow from 1.2.3.4 to any port 2222
Let’s also add a rule for Cockpit – which is an optional server monitoring GUI (don’t add this rule if you don’t plan on running Cockpit – it is optional…more info on Cockpit in Part 16 below):
sudo ufw allow from 1.2.3.4 to any port 9090
Once again, substitute 1.2.3.4 with your own IP address.
Next, let’s open up access to the ports that Jitsi needs. We’re going to allow connections to this server on HTTP, HTTPS, and UDP 10,000-20,000.
sudo ufw allow http sudo ufw allow https sudo ufw allow in 10000:20000/udp
At this point, we will now turn on our UFW firewall and take a look at the rules that we created.
sudo ufw enable
When prompted whether or not to proceed, choose yes.
Let’s take a look at our rules:
sudo ufw status
You should see something similar to this:
The firewall is now running, and if you test your PuTTY connection again, you should still be able to connect. But – if you test connecting in on the standard SSH port 22, you will not be able to connect.
Part 11 – Update Server
Now that access to the server is secured, let’s run our system updates.
sudo apt update sudo apt upgrade -y sudo apt dist-upgrade -y
It’s possible that no updates will be needed, but if you are asked whether or not to proceed on any of these steps, just answer Y.
Part 12 – Configure Time Zone
Set up your Time Zone by running:
sudo dpkg-reconfigure tzdata
A pink bordered window will appear – select your geographic area (use America for United States) and then select your city/time zone from the list. You can press TAB, arrow keys, and SPACE to move around these screens and make selections.
Once your time zone has been selected, press OK, and you’re done with Step 6.
Part 13 – Configure NTP
NTP (Network Time Protocol) can be installed by running:
sudo apt install ntp
You can make sure the NTP service has started and is running by typing:
service ntp status
You should see that NTP is ‘active (running).’ If you type:
date
Your local time should show correctly (in 24-hour format).
Part 14 – Install Cockpit (optional)
Next we are going to install Cockpit – Cockpit is a system monitoring software for viewing CPU/RAM/Disk space. You can read more about Cockpit here: https://cockpit-project.org/
Install Cockpit by running:
sudo apt install cockpit -y
Once installed, you should be able to browse to https://[server IP or FQDN]:9090. Log in with the credentials you created in Part 4. Note that this service may get blocked in Google Chrome (try FireFox).
Part 15 – Set up autoremove
As you run updates to your server, older versions of the Linux kernel are no longer needed, and they can potentially fill up your boot volume. To prevent this from happening, we can run:
sudo apt autoremove -y
(Go ahead and run this now). This clears out older versions that are no longer necessary, but this command should also be scheduled to run on a regular basis. To do this,
sudo sh -c 'echo "sudo apt autoremove -y" >> /etc/cron.monthly/autoremove'
This creates a new file called ‘autoremove’ in the /etc/cron.monthly directory which will automatically run once a month – but in order to run, this file must be made executable:
sudo chmod +x /etc/cron.monthly/autoremove
Now we’re good to go.
Part 16 – Install Jitsi
Finally it’s time to install Jitsi! First, we will add the Jitsi package repository and GPG key with these two commands:
sudo wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add - sudo sh -c "echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list"
Next update your package list:
sudo apt update
And finally install the full Jitsi package (I say full Jitsi package because it is possible to install various Jitsi components separately – however, that is beyond the scope of this guide):
sudo apt install jitsi-meet -y
During installation, you will be asked for the hostname of the server – enter in your hostname (ie. jitsi.crosstalksolutions.com).
You will also be asked if you want to generate a new self-signed certificate, or if you want to use your own certificate. Choose option 1 since we will be installing Let’s Encrypt in the next step.
Installation should only take about 1 minute or so. Once complete, run this command to install Let’s Encrypt:
sudo /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
You will be prompted for your email address – enter it and press ENTER.
You have now successfully installed Jitsi! Let’s test it out. Open your browser and navigate to https://[your Jitsi FQDN] – you should see a screen like this:
Type a name for your conference in the box (or take one of their randomly generated names) and then press ‘GO.’ Your video conference has now started!
As the moderator of the Jitsi conference, use the ‘i’ info box in the bottom right-hand corner of the screen to copy your Jitsi link and share it with others. You can also add a password for your Jitsi video conference if you want (recommended).
That’s it – you’re up and running – enjoy your new Jitsi server!
If you found this guide helpful, you can always:
Now that you’ve set up your Jitsi server – how about adding some authentication so that it’s not open to the whole wide world? Check out my other blog post How To: Jitsi Server Authentication!
Comments 57
Running SSH on a non-privileged port ( any port >= 1024 ) is a security risk. This is because non-root users are allowed to open ports at 1024 and above. In practice, this means that if a non-root user account could manage to get SSH to terminate, they could start a modified SSH daemon to capture your next login session and use that knowledge to elevate their own privileges.
I’m a big fan of non-port 22 SSH, but I always use a port below 1024.
Agreed, plus security through obscurity is best avoided too. Personally I’d leave SSH on port 22 (since it’s trivial to run nmap or similar to find where sshd is listening) and enforce MFA on sshd.
Chris, it’d be useful if you mentioned when setting up ufw that if your home IP address is not static then it’s a risk to only allow SSH access from your current WAN IP address. When the inevitable happens and your IP address changes you’re locked out of the VM and whilst you can most likely get back into the VM via the Vultr (or similar) control panel it may not be ovious at first why you can’t ssh into the VM.
This command line will give you all the free port numbers not used in the /etc/services file…
cat /etc/services | awk ‘{ print $2 }’ | tr -d ‘./[:alpha:]’ | sort -n | uniq | awk ‘$1<1024' | \grep "\S" | awk '$1!=p+1{print p+1"-"$1-1}{p=$1}'
…and this shows you which port numbers are used…
cat /etc/services | awk '{ print $2 }' | tr -d './[:alpha:]' | sort -n | uniq | awk '$1<1024' | \grep "\S"
🙂
Paully
How to prevent anyone knowing the url from using the server for their conferencing?
nano /etc/prosody/conf.avail/jitsi.example.com.cfg.lua
authentication = “internal_plain”
nano /etc/jitsi/jicofo/sip-communicator.properties
org.jitsi.jicofo.auth.URL=XMPP:jitsi.example.com
prosodyctl register yourusernamehere jitsi.example.com Password
systemctl restart prosody
systemctl restart jicofo
systemctl restart jitsi-videobridge2
nano /etc/prosody/conf.avail/jitsi.example.com.cfg.lua
VirtualHost “guest.jitsi.example.com”
authentication = “anonymous”
c2s_require_encryption = false
Reference “https://nerdonthestreet.com/wiki?find=Host+a+Jitsi+Meet+Server”
hi, how integrated with asterisk for call.
What port number do you use below 1024
Thank you for this guide.
If you would like to have a valid LetsEncrypt certificate for the cockpit webinterface so you can use Chrome/Chromium again here is how you do it.
Find out where cockpit is looking for certificates.
“Cockpit will load a certificate from the /etc/cockpit/ws-certs.d directory. It will use the last file with a .cert extension in alphabetical order. The .cert file should contain at least two OpenSSL style PEM blocks. First one or more BEGIN CERTIFICATE blocks for the server certificate and the intermediate certificate authorities and a last one containing a BEGIN PRIVATE KEY or similar. The key may not be encrypted.”
https://cockpit-project.org/guide/172/https.html#https-certificates
Now we simply have to put the generated LetsEncrypt certificates inside the cockpit certificate directory.
As cockpit is looking for one(!) single *.cert file we have to make that one first though.
cd /etc/letsencrypt/live/your.domain.tld/
ls
README cert.pem chain.pem fullchain.pem privkey.pem
cp fullchain.pem fullchain_plus_privkey.cert
cat privkey.pem >> fullchain_plus_privkey.cert
We now have the necessary single cert file for the cockpit certificate directory.
You can now copy the single cert file to the cockpit certificate directory.
cp /etc/letsencrypt/live/your.domain.tld/fullchain_plus_privkey.cert /etc/cockpit/ws-certs.d/
or link to it from the cockpit certificate directory.
cd etc/cockpit/ws-certs.d/
ln /etc/letsencrypt/live/your.domain.tld/fullchain_plus_privkey.cert your.domain.tld.cert
Either way you have to remove the self signed cert and reload the cockpit service.
I like to rename the self signed cert instead of deleting it. Just in case.
mv 0-self-signed.cert 0-self-signed.cert.bak
systemctl restart cockpit
Please note. As fullchain_plus_privkey.cert is a copy of the living LetsEncrypt certificates THIS WILL BREAK the next time certbot is doing a renewal of your certificates.
The better option would be to have a link from the cockpit certificate directory to the living LetsEncrypt certificates. However in the short time I was unable to find a simple way how to create a single link out of two files.
If anyone knows a good way how to do it, that would be great!
All the best
Steve
You, sir, are very much appreciated! Thanks for your comment! Easy to follow! I suppose one way you could fix the cert eventually getting old and needing to be replaced would be to make a script to remove the old cert and replace it when Letsencypt does its thing and updates. Not saying I know how to do it, but I am sure I could google my way around to finding that answer.
@Moderator. Please delete my previous posting. I mixed something up.
This is the fixed version. Thanks!
——————————————————————————-
Ok I got it!
Took me a bit of digging and experimentation as well as the help of a couple of friends. Nevertheless it works now.
So what we want to do is basically automate the process we did earlier manually.
Copy fullchain.pem to fullchain_plus_privkey.cert and append privkey.pem to it.
Putting a simple script together with the commands described in my previous post and letting it run via cron, it would certainly do the job, however there are a few caveats to be aware of.
1. Depending on the number of times you run the script you might face some period with an invalid certificate on your cockpit webpage.
2. Running it more often (eg. every minute) solves this problem. However it introduces unnecessary writes to the harddisk. Which probably has no real impact with a file this small. But we’re not savages. So no!
What do we want?
We want to check if the SOURCE is newer than DESTINATION. And if so, do the cp and cat command.
This will minimize the amount of writes on the harddrive which in returns mean you can tune up your cron interval and therefore have a very short timespan of an invalid cockpit certificate.
Luckily Ubuntu 18.04 has a built in program that can do just that. It is called “test”.
Run “man test” to see the manpage for it. In there you will find the parameter ‘-nt’.
———-
FILE1 -nt FILE2
FILE1 is newer (modification date) than FILE2
———-
So create your script. But first get root privileges.
sudo su
touch make_single_cert_for_cockpit.sh
put the following code into it with any editor you may fancy.
———-
#!/bin/bash
# This script is designed to run inside the LetsEncrypt certificate directory /etc/letsencrypt/live/your.domain.tld/
# It combines fullchain.pem and privkey.pem into one single file, fullchain_plus_privkey.cert.
# This is necessary because cockpit is looking for one single cert file.
# It does so only when the the modification date has been changed and therefore probably the certificate being renewed.
# It uses the Ubuntu built in “test” program. See “man test”.
cd “$(dirname “$0″)”; # If called from another directory the script runs from there. This line makes sure the folder containing the script will always be the root folder.
if [ fullchain.pem -nt fullchain_plus_privkey.cert ]
then
cp -u fullchain.pem fullchain_plus_privkey.cert
cat privkey.pem >> fullchain_plus_privkey.cert
fi
———-
make your script executable.
chmod +x make_single_cert_for_cockpit.sh
run it
./make_single_cert_for_cockpit.sh
Tell cron to run it every minute.
crontab -e
add
———-
* * * * * /bin/bash /etc/letsencrypt/live/your.domain.tld/make_single_cert_for_cockpit.sh
———-
Have a look at
https://crontab.guru/
for a good ressource on cronjob intervalls
That’s it. You should be good to go.
Final note. If you followed my previous post and copied the single cert instead of linking it you should probably fix that now 😉
Hope this helps.
All the best. Steve
hey Steve and all,
proxying Cockpit over Apache with LetsEncrypt is the best option imho.
Port 9090 not in use, chrome or any other browser works well with it. it’s secured!
DNS A record and CNAME to be added for http://www.cockpit.yourdomain.com then you good to go! Setup virtual host, get certificate, set up Apache reverse proxy and enjoy! =)
using it on Ubuntu 18.04.5 LTS – great tool, works fine!
Thanks for the step-by-step instructions. your guides and videos make life easy 🙂
can you also make video/ instructions on jitsi and jigasi integration?
Thank you.
A video on setting up Jigasi would be awesome. Got Jitsi up and running but stuck on Jigasi. Thanks for the great video
Did you find any content to setup Jigasi on Jitsi, Dear Bob?
Thanks for the great walk though on this. I find the online documentation to jitsi really fragmented for running your own server and this was a good starting point. Still looking for ways to secure my server don’t want to have a public jitsi server currently. Looks like there are lots of options in the /usr/share/jitsi-meet/interface_config.js file that I need to explore.
Their instructions on that are here: https://github.com/jitsi/jicofo#secure-domain. They seem to work for me.
Thank you!!! Got it up and running and only had to delete the server and start over once! Victory 🙂
Can’t wait to try it out for our first video chat!!
HI Chris.
Great job. I was not so good to have only restarted once. In fact I restarted 2 additional time because the first rebuild I simply said re-install and Vulture did not seem to give me everything needed like a sudo group! The second time I terminated the server and restarted another and all went well. Not bad for a really old guy 🙂
I have tested it with my kid who live far from us… it worked just fine.
Thanks for the video and blog .pdf
My main concern is the ability to have the jitsi page with no restriction access. Anyone can run the video conference and transmit malicious content and now is under your environment if you are the one hosting it…
Any comments?
@Steve – Thanks for the Cockpit Let’s Encrypt tutorial. We had exactly that issue and your guide resolved the matter.
Q: Will this need to be re-run when the Let’s Encrypt certificate expires?
I follow the guide and host the server, everything work fine except now when I created a meeting and shared the link with the other party we are not able to communicate no video no audio.
Managed to get all steps up to sudo apt install jitsi-meet -y
but it failed with below error message
Setting up nginx-core (1.16.1-0ubuntu2.1) …
Job for nginx.service failed because the control process exited with error code.
See “systemctl status nginx.service” and “journalctl -xe” for details.
invoke-rc.d: initscript nginx, action “start” failed.
● nginx.service – A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2020-04-09 22:11:45 -04; 19ms ago
Docs: man:nginx(8)
Process: 27486 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited,
status=1/FAILURE)
abr 09 22:11:45 arvychile-laptop systemd[1]: Starting A high performance web server and a reverse p
roxy server…
abr 09 22:11:45 arvychile-laptop nginx[27486]: nginx: [emerg] open() “/etc/letsencrypt/options-ssl-
nginx.conf” failed (2: No such file or directory) in /etc/nginx/sites-enabled/default:152
abr 09 22:11:45 arvychile-laptop nginx[27486]: nginx: configuration file /etc/nginx/nginx.conf test
failed
abr 09 22:11:45 arvychile-laptop systemd[1]: nginx.service: Control process exited, code=exited, st
atus=1/FAILURE
abr 09 22:11:45 arvychile-laptop systemd[1]: nginx.service: Failed with result ‘exit-code’.
abr 09 22:11:45 arvychile-laptop systemd[1]: Failed to start A high performance web server and a re
verse proxy server.
dpkg: error processing package nginx-core (–configure):
installed nginx-core package post-installation script subprocess returned error exit status 1
Setting up jitsi-meet-prosody (1.0.3969-1) …
Generating RSA private key, 2048 bit long modulus (2 primes)
How can I clean any reference to letsencrypt so I can
There is a problem with the instructions. I had to use the repos and commands from this page to get jitsi to install.
https://jitsi.org/downloads/ubuntu-debian-installations-instructions/
Could you put Jitsi server to respond to a custom HTTPS port like: https://myjitsi.domain.com:9792
At the moment there is an small problem with lets encrypt.
https://community.jitsi.org/t/lets-encrypt-problem/32857
For an new installation you need to run:
mkdir -p /etc/letsencrypt/renewal-hooks/deploy/
touch 0000-coturn-certbot-deploy.sh
chmod +x 0000-coturn-certbot-deploy.sh
before you use /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
Moritz, thank you. Had to kill and reinstall for the 5th time (2 times were user errors), but this fixed the issue I had, which was anyone else trying to come in to a meeting via a web browser could not because of the certificate error. Users connecting with the Jitsi Meet app on their phone/tablet did not have the issue.
Even after successful Let’s encrypt cert, I am still getting Warning: Potential Security Risk Ahead. However when I view the cert it is a Let’s encrypt cert. Any thoughts?
I have followed the install and have it successfully up and running, including the info in the second video.
Now my question is what happened, or what do I need to install.
If you go to a https://meet.jit.si/ and enter your meeting you are shown a box (“I”) with the meeting code, call in number, password, etc.
When I go to my site https://jitsi.abc.com/ and I name my meeting, I get the same box but with only a meeting code. Why does it not look the same?
Thanks
carltonb
Hi
Thank you for the super guide! 😀
Is it possible to run the jitsi on a different port, than 443?
How many places, do need to be modified for this?
Is it then possible for the let’s encrypt to verify the server?
I followed your excellent instructions but the one issue I’m seeing immediately is that I can’t set a password for the new session.
It opens fine, others can follow the link but when I click the ‘i’ I get the link but am not able to set the password even though I’m the one who set up the room and am the first person in it.
Any ideas?
Hi KB,
If you on SSH, check the prosody log here : /var/log/prosody/
prosody.err
prosody.log
Thank you so much for these Jitsi tutorials. They are brilliant. If you’re going to do some more then I’d love some guidance on setting up the Jibri component for recording and livestreaming.
Many Tx
Mark
puttygen couldn’t load private key unrecognised key type
Chris, thank you for the step-by-step instructions. Some readers may know they don’t have a static IP, and be tempted to skip your suggestion of only allowing SSH from their current WAN IP address, without realizing they still need to explicitly allow SSH access, in this case through “sudo ufw allow 2222,” or they will be locked out of their server as soon as they enable the firewall.
Hi,
We followed your instartuction and the video worked great as long as we were on the same network.
We run jitsi on xcp-ng behind a pfSense firewall and we had to add this line for it to work
> vi /etc/jitsi/videobridge/sip-communicator.properties
—
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=
—
In pfSense also set NAT to ‘pure NAT’
Then it worked.
Hope this help someone here
So i set this up on a VM my own internal network. Works great internally but when someone connects from outside the internal network they can connect but we get no video or audio. I’m doing DNAT on a edgerouter. Oh yeah one other thing, if i enable ufw in the VM nothing works.
Thank you for these tutorial. I have a difficulties to connect the SFTP for this server. i find this error :
Authentication log (see session log for details):
Using username “…..”.
Authentication failed
can someone help with this?
I tried Cockpit for the first time with your manual – a great tool. Which resources (CPU/RAM) are optimal for Jitsi meet?
Hi,
Great instructions, by the way – worked 1st time for me!
Problem is – as soon as anyone tries to enter the room, I get an error message:
“Unfortunately something went wrong. We’re trying to fix this……”
What is the issue?
Thanks for posting. I’m using this as a complete newbie on linux and your idea looks like a great project to learn and experiment! I ran into a roadblock and wonder if you have any pointers. So I I tried the same steps using Oracle Cloud Free tier, and everything succeeds until I get to Cockpit step. After installing cockpit, https://[server IP or FQDN]:9090 on my browser returns a time out error. My best guess is there is something wrong with the firewall. To confirm it was this VM and not the Oracle Cloud config in general, I created a second instance with same subnet etc with RHEL and could successfully deploy nginx and cockpit and hit via browser. Therefore, I strongly suspect something about Ubuntu any tips/thoughts how to proceed?
Thought I would post the answer for Oracle Cloud. Apparently UFW sits on top of iptables and oracles defaults are getting in the way. Followed the step by step here to fix for Oracle Cloud Ubuntu instance:
https://stackoverflow.com/questions/54794217/opening-port-80-on-oracle-cloud-infrastructure-compute-node
Maybe this will help some other poor soul working on similar.
Then I ran these rules to effectively disable iptables by allowing all traffic through:
$ iptables -P INPUT ACCEPT
$ iptables -P OUTPUT ACCEPT
$ iptables -P FORWARD ACCEPT
$ iptables -F
Hi,
I have followed all steps provided as above. In the last steps “sudo /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh” received error
########################################
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for vedantaexim.co.in
Using the webroot path /usr/share/jitsi-meet for all unmatched domains.
Waiting for verification…
Challenge failed for domain vedantaexim.co.in
http-01 challenge for vedantaexim.co.in
Cleaning up challenges
Some challenges have failed.
########################################
I have check through IP and Domain name accessible the server perfectly. Due to this error certificate not created for Jitsi server
Thanks,
Pravin Mori
80
443
ports are not allowed in this case
Hi everybody , I have some issue when I did the apt update after add the jitsi repository key just show me 5th line
Hit:5 https://download.jitsi.org stable/ InRelease
the other line
Hit:5 https://download.jitsi.org stable/ Packages does not show, so when I try to install jitsi show an error with jitsi-meet-prosody, jitsi-meet-turnserver and jitsi-meet packages. How I can add that line in my update command??
Thank you Crosstalk Solutions!
This is the best guide I have found on the net. My first trial and everything worked fine, moreover a lot of things I have had my own options due to some limitations and desires; such as having Nginx installed and approaching ufw from that angle, and skipping certain restrictions, such as single IP login.
My system worked fine, for about 2 of 3 sessions and since then, there is no audio. But when I speak, I see the “equaliser” showing that audio is being recieved. In fact, I even get the warning about too much noise on my microphone sometimes, but nothing is heard on the other end of communications.
I looked into the logs and found some errors to do with exceptions. Below are some lines
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
at sun.security.validator.Validator.validate(Validator.java:260)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1496)
… 13 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
… 19 more
What should I do to rectify the audio issue?
Regards,
Robert
Hi,
Thank you for this guidance and very clear tutorial.
In the step 2, in order to create a DNS A record, is that necessary to create a domain to support jitsi.company.com ? the domain name should be the same ?
Sorry for this stupid question but I am pretty new with all of this and your answer would be very appreciated.
Thanks,
Best,
Anthony
If we want to install Jitsi on the primary domain rather than the subdomain how do we go about doing that?
All the tutorials and instructions that I’ve found walk you through the hostname/fqdn configuration to install it at meet.example.com
I want to know how to only configure it for install at example.com where there is no website hosted?
For those using this tutorial (Excellent BTW) on Ubuntu 20.04 you will run into a problem at the Let’s encrypt stage.
certbot-auto is deprecated and will not run on Focal Fossa.
This guide: https://community.jitsi.org/t/script-for-ssl-certificate-creation-broken-on-20-04-focal-fossa/43555 did the trick for me.
TL;DR (install certbot and update the install script to use that instead of ./certbot-auto)
I have my own SSL certificate, how do i move away from the lets encrypt certificate on the server?
Any help for a noob setting up the Jitsi server from a cloned repo?
Followed the tutorial but when testing, the second I added a second person the server puked, “Unfortunalely something went wrong’ and reconnects but Pukes again as soon as the 2nd device joins. I HATE NGinX, I want Apache to do this, what a waste of a day (I had to restart three times as I installed Let’s encrypt and a LAMP stack first.
I’d hire you but can’t afford you. Oh well it was just supposed to be a zoom replacement but it’s not important enough and no one would use it enought to justify the frustration of getting this piece of junk working
made it all the way through to the end of step 9 but am not able to log into the server “Putty Fatal Error Network error connection timed out” reinstalled the server and started from scratch and the same deal….
Hello , thanks for the great tutorial. I have installed and use very well for almost 7 months but after I upgraded my droplet from ubuntu 18 to 20, I am not enable to communicate with any participant to whom I send the invitation. I can send the invitation and wait to see the other side connect but the other side when connect still also wait for me to connect. How can solved this any idea, please? thanks
Just to add also I am getting disconnect after few second
I cannot seem to get started on the right foot. When I login with putty or on the server, the prompt says : root@localhost not root@jitsi though I have name jitsi as a subdomain. What am I doing wrong? Any help anyone
Hello
Has anyone gotten this error when running command “wget -qO – https://download.jisti.org/jitsi-key.gpg.key | apt-key add -” ???
“Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
gpg: no valid OpenPGP data found.”
If so, do you know a resolution?
Hi
I am facing below issue , kindly help
root@meet-uat:~# apt install jitsi-meet -y
Reading package lists… Done
Building dependency tree
Reading state information… Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
jitsi-meet : Depends: jitsi-meet-prosody (= 1.0.6776-1) but it is not going to be installed
Recommends: jitsi-meet-turnserver (= 1.0.6776-1) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
root@meet-uat:~# apt install jitsi-meet* -y
Reading package lists… Done
Building dependency tree
Reading state information… Done
Note, selecting ‘jitsi-meet-turnserver’ for glob ‘jitsi-meet*’
Note, selecting ‘jitsi-meet-web’ for glob ‘jitsi-meet*’
Note, selecting ‘jitsi-meet’ for glob ‘jitsi-meet*’
Note, selecting ‘jitsi-meet-web-config’ for glob ‘jitsi-meet*’
Note, selecting ‘jitsi-meet-tokens’ for glob ‘jitsi-meet*’
Note, selecting ‘jitsi-meet-prosody’ for glob ‘jitsi-meet*’
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
jitsi-meet-prosody : Depends: prosody (>= 0.11.7) but it is not going to be installed or
prosody-trunk but it is not installable or
prosody-0.12 but it is not installable or
prosody-0.11 but it is not installable
Depends: lua-inspect but it is not installable
jitsi-meet-tokens : Depends: prosody-trunk but it is not installable or
prosody-0.11 but it is not installable or
prosody-0.12 but it is not installable or
prosody (>= 0.11.7) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
root@meet-uat:~# apt install jitsi-meet-prosody -y
Reading package lists… Done
Building dependency tree
Reading state information… Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
jitsi-meet-prosody : Depends: prosody (>= 0.11.7) but it is not going to be installed or
prosody-trunk but it is not installable or
prosody-0.12 but it is not installable or
prosody-0.11 but it is not installable
Depends: lua-inspect but it is not installable
E: Unable to correct problems, you have held broken packages.