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>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/43c010f6e246b6131d393c7d
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Only log that we're waiting for channel type the first time.

The other 500 times are implied.

---
â–  Synchronet â–  Vertrauen â–  Home of Synchronet â–  [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/7bfb1ef12e482ecfb30a9648
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Guard against answer() being called before the first channel is created.

In this case, just accept whatever we get info on as the "first" one.

Likely fixes #728

---
â–  Synchronet â–  Vertrauen â–  Home of Synchronet â–  [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/dc04dba2dd1317000fcbc79e
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Early-out of the channel type loop for channel errors.

If there's an error setting the channel or getting the channel
type, give up on the session immediately.

---
â–  Synchronet â–  Vertrauen â–  Home of Synchronet â–  [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/bf25c42be169b69e9a0e2051
Modified Files:
src/sbbs3/answer.cpp
Log Message:
TRUE -> true

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/84c90ed98b83651479a8ece0
Modified Files:
src/sbbs3/answer.cpp
Log Message:
client_on() still accepts a BOOL (not bool), so TRUE (not true) is correct

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/ccce5a7c40c325f3e0628fe1
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Initialize sbbs_t::client and call client_on() as expected for logins

See sbbs_t::logon() for example

Note: the client.protocol is still "SSH" here (not "SFTP"). Perhaps that
should be changed?

Does any client actually support simultaneous "SSH" and "SFTP" sessions over the same socket?

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/479c00be08fcee60913272a4
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Fix issue when third SSH authentication attempt succeeds

Because the session is activated on the *next* time through the
loop, if the third attempt to authenticate (including public key)
fails, it would leave the session inactive and fail to log in with
a confusing error about an obsolete cryptlib.

On success, decrement ssh_failed to ensure another pass through
the loop.

Also, add more debug logging around the auth so you can clearly
see each failure, and log client_socket each time so it's clearly
grouped.

---
â–  Synchronet â–  Vertrauen â–  Home of Synchronet â–  [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/83fa4577d127ff775202a0a8
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Fix indentation of one line.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/ddf7e3af07a181a1ad0bff84
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Change ANSI-color to black on black to obscure garbage in term-detect sequence

Pretty up the initial connection for non UTF-8 ANSI terminals, at least.

Also removed what looks like an extraneous underscore after the return to normal ANSI attribute (CSI 0m) sequence - I'm not sure. It's been there since Synchronet v2 so it's possible that some terminal needed it for some reason
but that reason has been lost to time (maybe WIP/DCTerm detection?).

Fixes issue #996

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/ea53ddfb3812f95a9480865e
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Fix extra [Hit a key] prompt when connecting with PETSCII

Another regression in the "New Terminal Abstration" fixed.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/114c3dfdee48db651bf568fa
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Fix potential deadlock in specific case

If the telnet client sends an IP address as a Location, and that
IP address is in a filter file, the input thread mutex would not
be unlocked.

This oddball feature was suggested on Reddit here: https://www.reddit.com/r/synchronet/comments/khuyey/ftelnetwebsocketservicejs/

And implemented in Synchronet here: https://gitlab.synchro.net/main/sbbs/-/commit/2bbe824c0656176d0314f2d48558b322a69b9e32

It appears that it's been broken the whole time.

Found by some LLM (ChatGPT?) and reported by nelgin.

---
â–  Synchronet â–  Vertrauen â–  Home of Synchronet â–  [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/4b53b6a54d1944eb698f19af
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Re-arrange the unlock's of the input_thread_mutex to make more sense

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/d0accc6f3d4dda6fa4d811a1
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Log a msg to the node/system log when new user registration is canceled

Yeah, one 'l'.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f6746e937c8b888e60114770
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Don't execute login module if user already disconnected

which might log the (new) error message: Error -1 executing login module

Users can easily disconnect before the login module is executed (e.g. during
a pause prompt while displaying text/answer.*).

We still might need more disconnection detection in login.js or lower the severity of the logged error if login.js still gets auto-terminated due to disconnection (which results in a -1 exit code if ungracefully terminated).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/91273407cb15becbfd22ee5a
Modified Files:
src/sbbs3/answer.cpp
Log Message:
Remove extra blank line after copyright notice when connecting with PETSCII

This was added in the New Terminal Abstraction for unknown reason

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net