VNC Too Many Security Failures? Clear the Lockout and Find the Cause

Your VNC server has blacklisted the address you're connecting from. TigerVNC and RealVNC Server both send this exact text, and both block an address for 10 seconds at first, doubling every time it gets back in and fails again, so retrying is what keeps you out. On TigerVNC, five connections from one address that don't log in are enough, and the block lands before your viewer gets as far as a password prompt.

There are three ways back in. Stop everything that's retrying and make one careful attempt once the block runs out. Restart the server, which empties the list at once but on TigerVNC also ends the desktop session. Or, when the server takes connections on another address you can reach, come in from one that isn't blocked. Then read the session log to see what made those connections, because a wrong password is only one of the things that count.

What the server does when it sends this

TigerVNC keeps its blacklist in the server process's memory, keyed on the client's IP address. Every connection the server accepts puts a mark against that address, and only a successful login wipes the address's marks. Once an address is blocked, the server answers its next connection with an RFB 3.3 failure carrying the reason Too many security failures, then hangs up. That happens before any security type is agreed, which is why you never see a password prompt. TigerVNC Viewer 1.15 reports it as Failed to authenticate with the server. Reason given by the server: with Too many security failures underneath, and older viewers word the dialog differently but end with the same reason.

Three Xtigervnc parameters run the scheme, and x0vncserver (X0tigervnc on Debian) takes the same three with the same defaults:

Parameter	Default	What it controls
`BlacklistThreshold`	5	Unauthenticated connections allowed from one address before it’s blocked
`BlacklistTimeout`	10	Seconds of the first block
`UseBlacklist`	on	Whether blocking happens at all

The count belongs to the address, not to a user. Five connections pass, the fifth starts the 10-second block, and a sixth inside that window gets the error.

What counts toward the block

The threshold counts unauthenticated connections, not wrong passwords. A port check against 5901 adds a mark, so does a scanner, and so does a viewer you closed at the password prompt. The session log on the Debian 13 worked run below tells them apart:

What tripped it	What the session log shows
The wrong password, tried again and again	`Accepted:` from your address, then `Authentication error: Authentication failed` and `Closing <peer>: Authentication failed`
A monitoring check, `nc -vz` or a scanner	Many `Accepted:` and `Closing <peer>: Clean disconnection` pairs from one address in quick succession, with no authentication line between; a probe that sends something other than an RFB greeting logs `Closing <peer>: Reading version failed, not an RFB client?`
Several people behind one address	`Accepted:` and `Authentication error` lines from one NAT address, or from loopback (`127.0.0.1` or `[::1]`) when everyone tunnels in over SSH
Someone outside guessing passwords	`Accepted:`, `Authentication error` and finally `Blacklisted:` lines for an address you don’t recognise

The tunnel row catches people out. ssh -L makes the connection to the VNC port from the server machine itself, so the server sees every tunnelled user as loopback. The default listener takes both 127.0.0.1 and [::1], and the server keeps one count per address, so tunnelled users share at most two counts. Debian's default listener only takes loopback connections, so there that's every remote user you have, and one person's typos can lock out the rest.

Read the session log first

The worked run is Debian 13 with TigerVNC 1.15 on display :1, port 5901, run by the tigervncserver@:1 service. The service starts the tigervncserver wrapper, which writes the session log to ~/.config/tigervnc/<host>:1.log in the session user's home, where <host> is the machine's full hostname. The default log level already records connections, blocks and failed logins, so you don't need to turn anything up. As the session user:

read the session log first

grep -E 'Accepted|Closing|Blacklisted|Authentication error|password file' ~/.config/tigervnc/*:1.log

A line reading Connections: Blacklisted: <your-address> confirms the block. The lines above it tell you what led there, matched against the table: Authentication error lines mean wrong passwords, while a run of Closing <peer>: Clean disconnection lines from one address with no authentication line between them points at a check or a scan. One such line on its own can just be a normal logout, because a successful login prints nothing this grep matches.

To see which address made the connections, count them:

read the session log first

grep -hoE '(Accepted|Blacklisted): [^ ]+' ~/.config/tigervnc/*:1.log | sed 's/::[0-9]*$//' | sort | uniq -c | sort -rn

Each output line is a count, the event and an address, busiest first. The sed strips the port the server logs after :: on each Accepted: line, so connections from one address add up instead of splitting by port. An IPv6 peer is logged in brackets, [::1]::<port>, and the same sed leaves [::1].

Get back in: wait, restart or switch address

Switching address costs nothing when it's open to you, so check that first. Otherwise pick by what's running in the session: if the apps on it matter more than the wait, wait, and if you need in now and can lose the session, restart.

Wait it out. Stop everything that's trying: viewers left on retry, scripts with a stale password, the monitoring check. When a block runs out, the server lets one connection through and at the same moment arms the next block at double the length. If that connection fails too, you're looking at 20 seconds, then 40, then 80. Ten failed tries after the first block and you're at 10,240 seconds, close to three hours, which is how a forgotten script keeps an address locked all afternoon. Once everything is quiet and the block has run out, connect once, the way you normally come in. On the default Debian listener, which only takes loopback connections, that's through SSH: