You are here
Witzker - Wed, 2024/04/03 - 23:13
Never had problems with your fantastic Core Debian
just installed your Nextcloud ISO - old - just doing update - perfect!
But today:
core installed in ESXi VM as usual
in workstation as remote console - No problem to logging
But no access with Putty, Win SCP and MobaXtrerm
I think the problem is on my side!
But I cannot figure it out!
PLS. Help
Many THX
Forum:
Some stuff to test
Does the result of "ip a" or "ip addr" return results you expect?
Can you ping out to something on your network from the VM's console?
Can you ping the VM from something on the network?
Is the ssh server daemon running?
Is the ssh configuration set to allow your user to log in? (I forget if root is locked out of ssh on core)
Is fail2ban running and is your work machine IP address in fail2ban jail on the VM?
Yeah could be fail2ban in combo with our default SSH config!?
FWIW the combo of the hardened SSH settings we ship with in, combo with fail2ban defaults may be causing this issue?
I'll discuss some ideas below, although please be aware that if you are bein blocked by fail2ban, then you will wait until you get unbanned - Unless you successfully login to your server (e.g. via local terminal on ESXi (assuming that's an option?). IIRC the default fail2ban timeout is 10 minutes.
By default it should not be an issue if you don't have any SSH keys configured in your client and you get the password right first time. I have no idea how this might be done via PuTTY/WinSCP, etc, but certainly is via OpenSSH. If you're using Windows than AFAIK newer versions have OpenSSH installed by default, but if not, then it can be installed.
Using OpenSSH you can check whether that is the issue by making the output of SSH more verbose:
The output of that should show it trying various logins and then falling back to another when that fails.
If you confirm that is the issue, you can force it to use password only via OpenSSH like this:
Or if you have you have multiple keys - with your server configured with only one of them, then you can force use of a specific key:
A short term workaround might be to disable fail2ban (on your server):
Once you have access or using a local VM host terminal, you can change the SSH server defaults to allow more tries to log in. It has security implications, although it could be argued that they are minimal (Debian generally has pretty sane defaults) - certainly minimal on a local VM:
To do that, edit /etc/ssh/sshd_config.d/turnkey.conf and adjust MaxAuthTries. We default that to 3 so bump that and see if that helps. FWIW the Debian default is 6. So if you just want to return that to the default (i.e. 6) you can comment out (i.e. put a # at the start of the line) the MaxAuthTries line in /etc/ssh/sshd_config.d/turnkey.conf
Hope that helps.
Add new comment