can't login via ssh after fresh 7.5 install
-
Here is how my host looks like from the outside:
PORT STATE SERVICE REASON 22/tcp closed ssh conn-refused 80/tcp open http syn-ack 202/tcp closed at-nbp conn-refused 443/tcp open https syn-ack 3478/tcp closed stun conn-refused 5349/tcp closed stuns conn-refused
Since cloud provider firewall is disabled (double-checked), it looks like a firewall config from Cloudron.
-
I tried this on DigitalOcean and it seems be fine. I think there is something else going on, unrelated to Cloudron installation. Cloudron doesn't change any settings in your sshd_config . Maybe you can try to do a diff before and after install. There is only one comment line which is added saying "Port 202 is the supported port"
-
Just for the sake of truth - it does change SSH config, not in a significant way though:
$ diff /etc/ssh/sshd_config ./sshd-initial
14d13
< # NOTE: Cloudron only supports moving SSH to port 202. See https://docs.cloudron.io/security/#securing-ssh-accessAnd I guess it's exactly the root cause of my issue: I've moved SSH to a completely different port, I did that before installing Cloudron.
A question though - am I right that I can only move SSH to 202, as it's the only other port defined in iptables, as I can see?
-
Probably it's worth adding
grep -E "^Port\s" /etc/ssh/sshd_config
check and if the output is not 22 or 202 - abort the installation?It seems to be an easy thing to do and will prevent someone else from get locked outside of the machine (and save some time thinking if he's going crazy... )
-
-
-
@potemkin_ai said in can't login via ssh after fresh 7.5 install:
Probably it's worth adding grep -E "^Port\s" /etc/ssh/sshd_config check and if the output is not 22 or 202 - abort the installation?
mmm, maybe. Let's see if we get more reports like this.
-
As an experience sharing - why wouldn't you add one line as a first line of the script, if that could save in some - rare - but still possible to happen cases? Is there some 'cons' for that?
Surely understood if you won't respond, but would appreciate if you can share the reasoning behind your decisions, would love to know a bit more about your decisions.
-
@potemkin_ai it's only a question of how common this is. I haven't heard of this issue reported since we launched Cloudron :-), so I just assume it's quite rare.
Adding any line of code needs tests and proper care. For example, the line you gave does not have any output on DigitalOcean since there is no
Port
line in their config. Also, sshd can be configured via files in/etc/ssh/sshd_config.d
as well. So, it's a question of how much time we want to spend on this and testing it across say 10 server providers. It's not a 5 min commit and forget thing -
Even I had it again
Really - some sort of warning would be really of help! -
Hi @girish,
I'm no bot. Just installed Cloudroun on my new server on Sunday and the install went perfect - apart from this issue. The grep command showed the port I have chosen for ssh so this means that either Cloudron expects me to use another port or is blocking the chosen port which is unfortunate. Nevertheless I'm very happy with Cloudron but some kind of warning during setup would be highly beneficial.
-
Wow, LOL, same thing happened to me and when I learned that someone had already reported it and nothing was done to alert others who also follow best practices with common ports, I was shocked. Would have saved me a lot of wasted time if this displayed an extremely simple alert. Oh well, thanks @girish.
I have never used Cloudron so was just testing it out. But seems now I have 2 firewalls, Azure and the built-in OS ufw/iptables seems to have been turned on (hence being locked out of SSH). Not sure how I feel about that. Hoping that can be disabled as I prefer to use my existing VNet security group.
But will play with it and see how I like it.