Re: Binary to read file /var/log/failedlogin

Hi,

If have remote access and not just console access with an Internet exposed OpenBSD box, I strongly suggest some proactive ssh defense, including rate limiting connections.  You will see MANY repetitive connection attempts as standard accounts/guessable passwords are tried (in your ssh logs).  It will simplify your system in the event of an audit or forensics!

It all depends on your users (if any) that are accessing your system, but I have my ssh configured to disconnect after 2 failed log in attempts, with root not allowed to log in via ssh.

PermitRootLogin no
MaxAuthTries 2

In PF, I only allow 3 attempts to log in in a 90 second period.  So that's a maximum of 6 attempts to log in before the IP address is permanently blocked.  I am the only one accessing my system and these are working for me.  It may not work for other user bases.  Caps Lock accidentally being on has almost gotten me a couple of times, but I know about the 90 seconds, so just wait 5 minutes before I try again.  
table <bad-hosts> persist file "/var/spamd/bad-hosts/bad-hosts.txt"
block quick log on egress from <bad-hosts>
...
pass in on egress inet proto tcp from any to (egress) port ssh keep state \
        (max-src-conn-rate 3/90, overload <bad-hosts> flush global)

** Caveat - this is ancient PF code, it may not be 100% consistent with the current "best practices", but it just keeps working!

I have had over 3000 ip addresses in my bad-hosts table.  I let them accumulate by having a crontab that dumps the bad-hosts table to a file hourly.  That way when the system reboots, it has a relatively recent list of the "bad-hosts" that it initializes with.

pfctl -t bad-hosts -T show > /tmp/bad.$$
if [ $? -eq 0 ]; then
  cp /tmp/bad.$$ /var/spamd/bad-hosts/bad-hosts.txt
  rm -f /tmp/bad.$$
  exit 0
fi
rm -f /tmp/bad.$$
exit 1

I hope this information is useful, and if anyone sees anything wrong with my logic, please let me know!  I've been using OpenBSD since 2.7 and I don't always keep up to date with all the changes that make life simpler and better :)

Cheers,
Steve W.

On 1/19/2026 5:30 AM, Crystal Kolipe wrote:

On Mon, Jan 19, 2026 at 07:52:34AM -0500, Nick Holland wrote:  

(some will advocate moving SSH to a different port.  That is NOT a security  improvement...but it can significantly reduce the size of your logs, which  may be a good thing.  

  If you have IPv6 connectivity from everywhere that you want to connect from,  then making SSH IPv6 exclusive is also quite effective at reducing junk  traffic to the server.    It also has the side benefit that you usually don't need any special config to  avoid idle SSH connections from dropping due to the NAT server timing out the  connection.  (Unless you are using NAT over IPv6, which is uncommon.)