pam has been helpful. We can use it to add TOTP to ssh logins, for example. The TOTP will have scratch codes similar to OPIE. There are several ports with pam in the name that might offer some solutions for your favorite logins. We found slapping MFA with a
pam_google_authenticator to pretty much shut down brute force attacks on ssh logins in your average, horribly polluted, public server farm. Adding on some other tricks like cert-based logins, port knocking, and some pf was also useful. Don't forget a banner message if you need it for compliance to tell someone to buzz off and leave your system alone so that they can plainly see that they're wrong.
https://man.freebsd.org/cgi/man.cgi...=FreeBSD+4.7-RELEASE&arch=default&format=html
https://www.freshports.org/search.p...own=asc&search=Search&format=html&branch=head
I suppose one might be able to create a batch of users with random passwords assigned to a similar group. If the group permissions were appropriate and the passwords random enough, then they might server a similar purpose to having OPIE on a commonly used account. This could be done with normal account creation procedures and a little bit of advance planning. If the usernames were sufficiently long and randomized, then knowing the two parts might be sufficiently complex to protect against common brute force attacks.
One technique is to echo a string you can easily remember; send it to openssl to hash it; then use cut to take a specified section of the hash. This will usually be random enough to give you a slice of something you can resurrect later if you remember the clue that fed into the message digest. The cutting will keep the output segment small enough for our weak brains to handle.
Looks like:
echo "CLUEWORD" | openssl HASHNAME | cut -c STARTPOSITION - ENDPOSITION
One trick to make sysadmin a little easier is to add on a pseudorandom string to common service usernames. You will want to pick one that shows the typical name easily, but has enough of a random blob of trash in the name to defy most word lists. Like,
maria_bbb34d3a2ac4 instead of
maria as a username for a service. That'll close a lot of bad logins before they even get started. That's another piece that can be done with no special tools on the base system.
You could always use cron to add or subtract a shell from a user account at a given time interval. Say, every hour on the top of the hour, account name SOMEACCOUNT goes from no login to /usr/bin/sh for five minutes. This would give you a time lock on an account maybe long enough to slip in and take action on your system without keeping it exposed all the time. That could probably also be done on a base with just a little planning.
Or, one might take the technique above, and feed a wordlist into a cron job to change the password on an account every so often. With a known rotation plan of expected outcomes, the effect might be similar in that a shortlist of possible answers could be applied. None of this, though, would have the one time use only effect unless you chose to script it in yourself.
Cert based logins can be built with openssl; but, if I remember right, there was a module in there that was not included with BASE. I think there might be an embargo on one of the parts. In order to generate certs, I think we had to load up the whole package; but, done once, you could always bring that long on subsequent installations. It would not be "one time" like OPIE, but it is better than just a plain password.
If the login is networked, I have found that it is possible to get pf to read from files as a block list. Perhaps some planning could put a distinct user on a block list after a login. This combined with usernames/password pairs, as above, could achieve a similar effect over a network but it would not be pure OPIE.
While not a perfect match, perhaps these suggestions can offer some alternatives to the deprecated OPIE program.
Perhaps with a little conniving and thievery, you won't need another application to help you.
Hope this helps. Good luck.
