Three Steps to Unblock Fail2Ban Banned IP address from SSH Jail

I run many internet-facing servers reporting SSH dictionary and DDoS attacks via Fail2Ban to blocklist.de and sometimes end up in a situation where I manage to block myself out from my servers, especially when my residential ISP IP address changes. Here is a recap of what I do to unban a IP from Fail2Ban's SSH jail.

Execute the following three steps to unban (unblock) a IP address banned by Fail2Ban in the SSH jail. Tested on Fail2Ban v0.8.11. These steps do not need arcane fail2ban-client commands and manipulate iptables directly instead.

Step 1

# iptables -n -L --line-numbers | grep <ip address to unban>

Step 2

Note down the line number (rule number) at the beginning of the output of the prior command line.

Step 3

# iptables -D fail2ban-ssh <line number from previous step>

Note: At this point, re-run Step 1. If the IP address still shows up as banned, it is possible the jail name needs to be adjusted:
# iptables -D fail2ban-pam-generic <line number from previous step>

That's it. You can, of course, add the IP to be never banned to jail.local's exclusion list for the ban to not happen again.

If you are looking for a list of great IP blocklists, here is what I use on my pfSense gateway with pfBlockerNG.

Remote X11 X Windows client forwarding over SSH to local X Server: The definitive guide

No more trying to remember "what did I do the last time" every time I deploy yet another real or virtual Unix/Linux system with X11 graphical gizmos! Here is how to enable X11 display forwarding over a SSH login session.

The local machine runs a SSH client and a X server. The remote machine runs a SSH server and a X client application (e.g. xeyes). From the local SSH client, we log on to the remote SSH server, and forward X11 graphics from clients running on the remote machine to the local X Windows server.

1) The remote machine needs to have xauth installed. This is accomplished with the usual package management commands. For remote systems running Linux, the package managers are invoked using "apt-get install xauth" on Debian-based systems (including ubuntu) or "yum install xauth" on Fedora/RedHat/CentOS based systems.

2) The remote machine needs to have IP forwarding enabled in the kernel. This is achieved by making sure /etc/sysctl.conf has the line "net.ipv4.ip_forward = 1". If not, add this line and execute "sysctl -p" for the kernel to re-read sysctl.conf without rebooting the remote system.

3) The remote machine needs to have the following lines in its SSH server daemon's configuration file /etc/ssh/sshd_config :

    AllowTcpForwarding yes
    X11Forwarding yes
    X11UseLocalhost no

Make sure these lines are there with the indicated parameters and not commented out. If not, edit /etc/ssh/sshd_config accordingly and restart the SSH server on the remote using "systemctl restart ssh", "/etc/init.d/sshd restart" or whatever restarts the sshd daemon on the remote system.

5) Open a terminal on the local machine and allow all remote X clients to connect to the local X server using "xhost +"

6) On the local machine running the X server, start a fresh SSH session and login to the remote system via SSH remembering to include the "-X" switch:
    ssh -X <remote-user>@<remote-host>

7) In the SSH session just established, make sure "X11 forwarding request failed on channel 0" is NOT displayed when you entered the password. Only the ssh banner, or motd, or whatever is configured to be shown when logging on to the remote system is displayed. Also, "Warning: No xauth data; using fake authentication data for X11 forwarding." should NOT be displayed since we installed xauth on the remote system. If either is displayed, something went wrong and you need to delve deeper.

That is all that should be needed. In the established ssh session to the remote system, type in "xclock" or "xeyes" or whatever command you want that needs an X11 windows server and the X Windows application should start up. If you get a "cannot open display", again something went wrong and you need to delve deeper. You should not need to export the DISPLAY environment variable containing <your local IP>:0.0 if X11 forwarding works correctly.

The xeyes X-windows application at the top of this post was captured on a Compaq CQ61 laptop running lubuntu 18 logged in over SSH to a virtual IBM S/390 mainframe also running ubuntu 18/s390x port. Here is a remote xclock X11 client displayed on the local laptop from a remote Raspberry Pi running Raspbian stretch.