Nothing serious, but nevertheless a bit annoying. I get this error when logging into IPFire using Windows terminal:
Received disconnect from 192.168.0.1 port 222:2: Too many authentication failures
Disconnected from 192.168.0.1 port 222
The source is obvious, in my case, I’ve played a bit with a FTP client to log into IPFire using a public/private key.
This failed for some reasons and I cannot connect anymore to IPFire using a console.
How would one solve this issue?
ssh is on port 22 and you have to enable it in the WEB GUI and I recommend disabling it once your done because its not a good thing to have SSH enabled all the time
Sorry for not being precise with my question.
I’ve a working setup for SSH connection but after various false tries to connect, IPfire locked the access and I’ve no clue how to unlock user root again, ATM.
Do you?
Usually too many false tries with a password login has a time period after which it allows you to access it again. I can’t remember what is used as the default value.
I would expect that 12 hours should be enough.
Do you have the guardian addon installed? If yes, then the default, unless you changed it would be 24 hours.
Yes, I’ve Guardian running here, however, the PC where the block happened yesterday, is white listed ( aka ignored host) there.
Today, I can use SSH again.
Nevertheless, I would like to know where the blocking happened and how to unlock before the lock period expires 
I am not sure that is coming from IPFire if it is not Guardian as IPFire does not use pam_faillock which is the method normally used to block users with shadow unless you are on Debian when pam_tally2 is used but this is also not installed in IPFire
I checked and those pam modules are not installed and the only login locking mentioned in searches beyond those pam modules is fail2ban, which is Guardian.
Maybe create a new user and then use a false password to login and confirm that Guardian blocks it. Then remove it from the block list and whitelist it and confirm that the whitelisting is working.
Unfortunately I haven’t been able to find any other process that would cause login blocking beyond the above mentioned methods.
If anyone else has knowledge of other login blocking methods then they can be checked against the IPFire git repo to see if they are installed.
Perhaps other settings may be in the /etc/ssh/sshd_config file ?
No nothing that would block you.
There is a grace period of 30 secs to complete your login before it terminates that login but then you can start the login process again.
There is nothing else in the file about number of logins before blocking.
I will check on the sshd default options to see if I find anything but the sshd config was not highlighted in any of my searches on locked login attempts.
Exactly, just checked the config, too.
There is a MaxAuthTries option which has a value of 6 per connection.
This is per connection and not per IP address.
So if this is exceeded, all you need to do is turn of the connection.
Maybe try to force the problem on a vm system and then try disabling and then enabling the ssh access on the WUI page. That should remake the connection and that would test out if MaxAuthTries is the problem.
If it is MaxAuthTries then at 3 attempts, sshd will start logging the attempts (half of the MaxAuthTries value).
I found a small hint
The sshd -T command shows the current SSH server settings
https://www.cyberciti.biz/tips/checking-openssh-sshd-configuration-syntax-errors.html
There is a new option that has come in with openssh-9.8 in CU187 called persourcepenalties that works on IP and covers a range of things being done, including excessive login attempts but also too many failed to complete logins etc.
However this has the default values and the max block time is 10 minutes which does not match up with your experience of several hours being blocked.
Have you thought about using public key authentication rather than password based authentication. It is much stronger and once set up you don’t get failed logins occurring.
are you trying to log in using that method: public/private key?
because you generate the keys on the remote computer (windows in your case) and copy the public key into the server (ipfire) because there is no session control in ssh on a server. That is why you suppose to close the SSH session with the exit command when you use username/password method (which is preferred if you are on a green network connected computer) using the key method only makes sense if you are remotely connecting from a different internet connection.
Also, there are no services on port 222
My apologies, i had missed that you were accessing via a public key already.
YES - that’s the case and works as already said.
As mentioned, too, I’m using UltraEdit (UE) to login in via SSH to edit some files and tried to setup SSH within UE with a private key. For unknown reasons, I guess it’s a bug in UE, the app uses the private key wrong and locked me out from IPFire.
This is the real story behind my initial question. Hence I’ve asked how to unlock my root user again without waiting for any period to pass.
Have you placed multiple keys into the IPFire ssh directoryor just the one?
Just one indeed in authorized_keys.
Then I have no idea at all as to why you were getting blocked.
Having a large number of keys can cause the MaxAuthTries to be exceeded when ssh scans through each of them looking for the one you want if the identity option is not specified.
However only one key should just work without problems.
I have no idea what UltraEdit is and have never used it and have no idea what it might be triggering to block you.
What shows up in the ssh logs from IPFire. If IPFire is blocking you because of failures in ssh authentication then it should give some clue to when it was triggered and what action it took.
This, many times:
error: maximum authentication attempts exceeded for root from 192.168.21.1 port 52423 ssh2 [preauth]
Its not a question about why authentication might fail, this is obvious and with some exceptions cause by myself (intentionally). It’s more a question about how to unblock the user. Restarting SSHD did not help, so I guess the block is handled in an (unknown) file.
Could you show the exact path to this file?