https://gitlab.synchro.net/sbbs/sbbs/-/commit/1a51ac2cf81b9497d52cb924
Modified Files:
src/sbbs3/answer.cpp
Log Message:
This "!CLIENT IP NOT LIST in /path/to/rlogin.cfg" message is weirdThis message can be logged when a sysop is prompted for the system password and enters it incorrectly or just disconnects.So lower the log level to DEBUG. And include the IP address that we searched for too.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/sbbs/sbbs/-/commit/2df371fe01859b77a1c69afc
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Manual terminal settings were cleared when logging in via SSH or RLoginThis appears to go back to a change Deuce made in 2004 (rev 1.41) where ANSI, COLOR, RIP and WIP user terminal settings were always cleared when logging in via RLogin.I happened to notice that manually enabling iCE color support wasn't working when logging in via RLogin (the iCE color flag would be cleared every login, but worked fine when logging in via Telnet). Upon investigation, I found that *all* user's manual terminal settings were cleared for either RLogin or SSH logins (copy/pasted bug). So... stop doing that. The method of dynamic terminal capability detection/checking has changed since 2004, so we should not need to mess with the user's misc flags.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/838f67529b17611dd63d48b7
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Apply IP filters to address reported via Telnet Location commandFeature requested (?) by u/jumbotronjim on https://www.reddit.com/r/synchronet/:If the client connection is from a blocked IP address (in ip[-silent].can), but still manages to get through the web server and websocketservice and have their correct IP address reported via Telnet Location, terminate the connection. Seems dubious.
--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/ca239664d95bca090dc4b064
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Reject DELETED/INACTIVE accounts on the SSH, SFTP and RLogin logon paths

An account flagged DELETED or INACTIVE could still log on via SSH, SFTP
or RLogin. Those paths resolve the account name themselves and, on a successful authentication, jump straight to logon(), bypassing login(),
which was the only place the flags were checked. That is why Telnet
correctly refused the same account while SSH let it straight in.

find_login_id() does not filter the flags on the caller's behalf:
matchuser() skips only DELETED accounts, because a deleted account's
alias is blanked in the user index, and the LOGIN_USERNUM shortcut
checks nothing at all.

Test user_is_active() once the account has been resolved. A terminal
session is sent text[UnknownUser] before the disconnect, the same
response Telnet gives, since login() treats a deactivated account as an
unknown one. An SFTP session has no terminal and is refused in the
channel handler instead, before the session is marked on-line and the
logon is counted.

Both sites record the rejection with badlogin(), so repeated attempts accumulate toward the hack and IP filter thresholds, as they already do
in the FTP and mail servers. The password is deliberately not passed
along: it was the correct one, and it would otherwise be written to the
hack log and to the ip.can entry.

GitLab #1239

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)