Cloudron Forum

Thank you

Is this a typo or did you not mean bare domain? I think bare domain means mydomain.com .

My understanding is that bare domain - it's what Cloudron perceive as bare domain; for that purpose I used to create those special subdomains and used them accordingly.

Do you also have an app installed installed in the bare domain ? the docs explain this is needed

You mean synapse? Yes, sure.
Or do you mean if there are any other apps installed on bare domain? If so, that's impossible, from what I understand?

Right now I have Synapse server installed on my-domain.com and nothing in well-known.

seems like many scripts automations, bots & official sdk no longer works with OIDC - I have to use token for that but I can no longer get token automatically; or I didn't find yet

here is a specific isolated use case that is braking now:

curl -XPOST -d '{"type": "m.login.password", "identifier": {"user": "monitoring.bot", "type": "m.id.user"}, "password": "<reducted>"}' "https://server.com/_matrix/client/r0/login"

Is there any way to avoid that and get locked in LDAP auth?

I'm installing new server of Matrix on a bare domain - matrix.mydomain.com, but the server attaches itself to mydomain.com (as per yml file), wellknown is empty.

To reproduce:

• create wild-card managed sub-domain
• install Synapse
• install it on that sub-domain

That's it.

There are some security updates been released recently.

@nebulon I do and thank you – sending e-mail as we speak.

I've been paying for subscription, but now I'm quite happy with free instance limitations. How do I downgrade it? I can't find that on console and one of my app is not upgrading due to that.

@girish Nessus is a very old security scanner: https://nessus.org/

No ideas, to be honest... that's why I thought to raise it to you.

@girish sure - just run Nessus full security scan against your server.

@girish nop. I also checked that, but there are no differences in the configs (apart from the port number)

@girish thank you!
I was thinking about pro version, but from the links you've mentioned it seems like they have a single code base for all features, thank you!

Can I use / upgrade to Baserow paid options on Cloudron?

@girish yeah, I know.

I wonder why across many similarly configured boxes with the same base ubuntu with the same base sshd only cloudron enabled boxes have that issue.

And since across multiple boxes with the same base os and configs only cloudron produce that kind of message I reported it here.

and a final piece:

The remote SSH server is configured to allow either MD5 or 96-bit MAC algorithms, both of which are considered weak.

The following client-to-server Message Authentication Code (MAC) algorithms
are supported :

hmac-sha1-96

And a few more ssh related configuration things:

The SSH server is configured to support Cipher Block Chaining (CBC) encryption. This may allow an attacker to recover the plaintext message from the ciphertext.

The following server-to-client Cipher Block Chaining (CBC) algorithms
are supported :

3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
cast128-cbc

Pardon, missed the key part:

The following weak key exchange algorithms are enabled :

diffie-hellman-group-exchange-sha1
rsa1024-sha1

Nessus shows that my servers with Cloudron (and only those servers) installed has weak ssh key exchange algorithms enables:

The remote SSH server is configured to allow key exchange algorithms which are considered weak.

This is based on the IETF draft document Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) draft-ietf-curdle-ssh-kex-sha2-20. Section 4 lists guidance on key exchange algorithms that SHOULD NOT and MUST NOT be enabled. This includes:

diffie-hellman-group-exchange-sha1

diffie-hellman-group1-sha1

gss-gex-sha1-*

gss-group1-sha1-*

gss-group14-sha1-*

rsa1024-sha1

Note that this plugin only checks for the options of the SSH server, and it does not check for vulnerable software versions.

See Also
http://www.nessus.org/u?b02d91cd
https://datatracker.ietf.org/doc/html/rfc8732

From what I understood, cloudron only works with the port, but from numerous servers configured the same way from the same Ubuntu, only my servers with Cloudron got this issue.

@timconsidine have nothing against Zulip - thanks for checking in!
Nor self-hosting experience with Zulip either...

@nebulon thank you! I've managed to find a way around to keep automated updates keeping the risk of update failure to a minimum, but - don't you consider using btrfs or zfs's snapshots to work that around on the platform level?