Cloudron Forum

As far as I understand those CVEs they are not relevant in that context. For the first, we don't use those affected configs and the second is for the ssh-agent.

Given that the Ubuntu team usually knows what they do and are working closely together with upstream projects, there seems no need here to go beyond their recommendations of versions they push out via security updates.

I was about to write a long time ago that the parameter for resetting SSH has changed:

sudo systemctl restart ssh.socket

@Dreamcatch22 said in Disconnected: No supported authentication methods available (server sent: publickey):

But here was the error I was getting from the unresponsive wordpress app:

Inactive - Error getting IP of redis-3e2e5aad-1513-4b65-bb24-5eaafc998daa service

Services -> Redis -> Restart . Then, try the repair. Think it should work after that.

We haven't added a way to add custom persistent iptables rules . For SSH though, just move it port 202 and disable root auth and password auth. This usually cuts down all bots to 0.

In Ubuntu 24.04 the restart does not work with "systemctl restart sshd", but only with "systemctl restart ssh.service".

@humptydumpty
Not only on home servers, also OVH and Vultr. Additional files will definitely be with local providers.

In this file "50-cloud-init.conf" as it actually is, I simply delete the line 😄

@girish got it, thanks 🙂

@Ritesh yeah, I would disable it. It's not required for a Cloudron install.

Glad it worked out in the end, and thanks for sharing the insights here!

Interesting. So, from @necrevistonnezr's like the hosts.allow/hosts.deny may not work in the future. "Note: this might not be an option on modern distributions, as support for tcpwrappers was removed from OpenSSH 6.7"

Yeah. I know what you mean. Ok I will start afresh 🙂
With this information now it will be ok to configure from scratch.

Many thanks

Jan

Glad it worked out in the end, even if we don't know why.

Glad you sorted it out. And interesting that your second attempt was 202 which is also what you picked as a default alternative to 22 🙂

Feels nice, thank you guys !

Yes, that was the problem. I was logged in under a second test user account that I had assigned admin role. Logged out and back in as my original cloudron owner account and all good on that front. Thanks.

@W1LMS See it as two levels of security. Firewall at DC level and at server level is also best practice.

Ok. I will doublecheck this. Give me a few hours for this.
Thanks for the moment 🙂

Update: Solution work fine! Thanks a lot. 👍

@nebulon Thank you, I will investigate today and let you know.

@skippsterr Why do you want to edit the sshd_config file in the container? I think the original solution was to edit the sshd_config in the target ubuntu machine that you will connect to (not Cloudron server).

Also, see https://forum.cloudron.io/topic/3237/remote-sql-support-on-a-per-app-basis?_=1652377131316 on how one can connect with a SSH tunnel.