That depends on what your definition of lock is. Perhaps you want to block inbound port 22 at packet filter level? Then you need to run sshd under tcpserver.
Keep in mind, sshd alone can't deny connection attempt. That's why it's usually built with TCP wrappers support. You can dynamically append his IP to /etc/hosts.allow but you need to write a script to do that.
Or you can write a script to parse ssh log file and append that IP to tcpserver's sshd file then rebuild sshd.cdb database.
Either way, there shouldn't be any permission problem because sshd need to run as root.

clearification

I appreciate the reply, but I am not sure I expressed my problem correctly.

Lastnight I logged into my collocated FreeBSD box using ssh like alway. I got in successfully, modified a single .html file, then logged out. I then tried to re-login again a little later, messed up the pw initially, then on each successive logon since, I have been unable to get back in. It gives me the message:

Permission denied, please try again.

I even tried logging in from another machine, and I get the same thing. In the past, of course, I have messed up the login from time to time, but I have never been denied like this.

I have made sure of all the usual - caps lock on/off, etc, but to no avail.

The machine is still running, and is serving up webpages like a champ. MySQL is working fine, and as far as I can tell so are the other services.

How come your $HOME has a path of /home/glacier/estrade?
If you have been using publickey auth method in the past it appears that the permission in your $HOME has been modified or changed, and sshd fall back to try password auth but it also fail. You must have done something incorrectly recently causing that kind of permission problem, if it's really a permission issue.
Sorry I have never faced such problem before, really can't provide much help on fixing it.

That's not the original cause of the login failure problem. The main problem is why should it failed in the first place. Prior to that problem which auth type did you use? Interactive or non-interactive? Like I said, it could be a corrupted key to sshd fell back to use password authentication but you have never configured sshd to use password authentication (/etc/pam.conf problem).