open https://gitlab.synchro.net/main/sbbs/-/issues/1239

I am running Synchronet BBS v3.22a (Linux) OS Linux Mint

I had a PITA user, I deactivated their account. (I did not want to delete and have them just remake the account)

The user tried to log in 4 times via telnet(how they had been logging in) without success. (The user got the account not active message while trying to log in via telnet)

The user then tried logging in via SSH and was able to log in without an issue.

I then replicated the same scenario by creating a test user account. I logged in and out. I then deactivated the test user account. I then tried to log in via telnet and I was NOT able to log in. I then tried to log in via SSH and I logged right in.

Another Synchronet BBS Sysop (running Windows) tried the same test and had the same results I did. (unable to log in via telnet, was able to log in via SSH)
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1239#note_10311

was able to duplicate on x-bit bbs running win32 v3.22
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1239#note_10313

I was also able to replicate this with the sbbs321e build that I run. So this raises concerns about the scope of this issue and its severity for all Synchronet BBS’s.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1239#note_10314

It sounds like a bug in the SSH server. Most Synchronet BBSes don't have deactivated user accounts, so the "scope of this issue" is likely pretty small in reality.

Seems like a one-line fix.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1239#note_10315

The scenario we are talking abut is not just scoped because the user is disabled. The reason the user is disabled is because they are logging onto the BBS and causing problems. To remedy this, the Sysop disables the user account. Because the user is crafty, they switched from using telnet to SSH and bypassed this security measure. Why would this be any different on any other Synchronet BBS? That’s what drove my reasoning behind the scope remark.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1239#note_10316

Most Synchronet sysops use other methods besides deactivation to deal with problematic users (the most obvious being to delete the user or give them a bunch of restrictions; disabling a user isn't a thing in Synchronet). Most sysops don't even realize that deactivation is a thing. I'm not saying I'm not going to fix the issue, I'm saying the scope and severity in the editorial comment was exaggerated.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1239#note_10317

The same issue is observed with the rlogin server.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

close https://gitlab.synchro.net/main/sbbs/-/issues/1239
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1239#note_10341

Thank you for addressing, DM!
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1239#note_10342

There's a pretty clear deactivate user menu option in the user editor. I don't understand how sysops wouldn't think that is a viable option for handling a rogue user.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1239#note_10343

I get not alarming the community when there is a rare exploit that only affects 1 or 2 systems, Rob. But that’s not the case here. Disabling thhe user account is the front-line defense used by not just Synchronet, but most other apps that provide user-level access control. Regardless, the feature is there, and so is the vulnerability. Fixing the issue is the correct course of action. Closing this issue feels more like a denial of its existence and an abandonment of the author when Sysops need him the most, whether they realize it or not. I’m not trying to be difficult, but if this was any other software program, I believe this issue would have been handled differently. Support your community and they will return that support.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hey Brian!

On Sat, Sep 12 2026 01:28:10 -0700, Brian Davidson wrote to GitLab note in main/sbbs:

https://gitlab.synchro.net/main/sbbs/-/issues/1239#note_10343

I get not alarming the community when there is a rare exploit that only affects 1 or 2 systems, Rob. But that’s not the case here. Disabling thhe
user account is the front-line defense used by not just Synchronet, but most other apps that provide user-level access control. Regardless, the feature is there, and so is the vulnerability. Fixing the issue is the correct course of action. Closing this issue feels more like a denial of its existence and an abandonment of the author when Sysops need him the most, whether they realize it or not. I’m not trying to be difficult, but
if this was any other software program, I believe this issue would have been handled differently. Support your community and they will return
that support.

You do realize the issue was fixed before the issue was closed, right?

Regards,
Nick

... Take my advice, I don't use it anyway.
--- AmberEdit/linux 0.8.2
# Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/1)
ï¿­ Synchronet ï¿­ _thePharcyde telnet://bbs.pharcyde.org (Wisconsin)
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Nick Boel wrote to Brian Davidson <=-

On Sat, Sep 12 2026 01:28:10 -0700, Brian Davidson wrote to GitLab note
in main/sbbs:

https://gitlab.synchro.net/main/sbbs/-/issues/1239#note_10343

I get not alarming the community when there is a rare exploit that only affects 1 or 2 systems, Rob. But thatª€™s not the case here. Disabling

thhe

user account is the front-line defense used by not just Synchronet, but most other apps that provide user-level access control. Regardless, the feature is there, and so is the vulnerability. Fixing the issue is the correct course of action. Closing this issue feels more like a denial of its existence and an abandonment of the author when Sysops need him the most, whether they realize it or not. Iª€™m not trying to be difficult,

but

if this was any other software program, I believe this issue would have been handled differently. Support your community and they will return
that support.

You do realize the issue was fixed before the issue was closed, right?

Haha! Pretty sure he doesn't... ;-)

Must be new if he thinks Rob needs some training on supporting his community... Sheesh.



... So easy, a child could do it. Child sold separately.
=== MultiMail/Linux v0.52
--- SBBSecho 3.37-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

Re: User-Deactivate account: Still able to log in via SSH
By: Nick Boel to Brian Davidson on Sat Sep 12 2026 09:26 am

On Sat, Sep 12 2026 01:28:10 -0700, Brian Davidson wrote to GitLab note in main/sbbs:

You do realize the issue was fixed before the issue was closed, right?

Actually, I was not aware at the time I wrote that comment. I since removed the comment, not realizing it was broadcast to the entire world.

I apologize for any confusion that this generated. I do not apologize for having to defend the scope of the issuem nor the fact that this fix really needs to be backported to sbbs321e as a prod/fix event, if it hasn't already.

Part of the confusion stems from the fact that the issues screen does not identify that code was committed, or that any merge action was taken. This is why I was mislead into believing I had to continue to defend my position in order to get the fix. I was wrong.

So, "master" builds with the fix confirmed, I'm running that on my BBS. It would be great to hear about sokmeone else running sbbs321e rrelease build and whether or not their answer.cpp got the patch. Beyond that, I end my involvement with this issue.

-Winzlo

===
þ The Down-Lo BBS þ bbs.winzlo.com

...Not tonight honey, ...I feel a modem coming on.
--- SBBSecho 3.37-Linux
* Origin: The Down-Lo BBS * bbs.winzlo.com (1:154/140)

Brian Davidson wrote to Nick Boel <=-

Re: User-Deactivate account: Still able to log in via SSH
By: Nick Boel to Brian Davidson on Sat Sep 12 2026 09:26 am

On Sat, Sep 12 2026 01:28:10 -0700, Brian Davidson wrote to GitLab note in main/sbbs:

You do realize the issue was fixed before the issue was closed, right?

Actually, I was not aware at the time I wrote that comment. I since removed the comment, not realizing it was broadcast to the entire
world.

Well, when you post to an echomail area, that's what happens...

I apologize for any confusion that this generated. I do not apologize
for having to defend the scope of the issuem nor the fact that this fix really needs to be backported to sbbs321e as a prod/fix event, if it hasn't already.

Don't think there was much confusion, other than yours. Methinks you
may have over-reacted a bit.

Part of the confusion stems from the fact that the issues screen does
not identify that code was committed, or that any merge action was
taken. This is why I was mislead into believing I had to continue to defend my position in order to get the fix. I was wrong.

You weren't "mislead" ... you didn't interpret things correctly. FYI
there are ways to follow the commits/merges, such as DoveNet messages
and in the IRC channel.

So, "master" builds with the fix confirmed, I'm running that on my BBS.
It would be great to hear about sokmeone else running sbbs321e
rrelease build and whether or not their answer.cpp got the patch.

A release build doesn't get any "patches", unless the Sysop does it
manually by updating to a development build.

Beyond that, I end my involvement with this issue.

Good idea.



... He does the work of 3 Men...Moe, Larry & Curly
=== MultiMail/Linux v0.52
--- SBBSecho 3.37-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

Hey Dan!

On Sat, Sep 12 2026 10:13:34 -0500, Dan Clough wrote to Nick Boel:

You do realize the issue was fixed before the issue was closed, right?

Haha! Pretty sure he doesn't... ;-)

Might not even see this, since everything is happening via the web these days and they don't intermix.

Must be new if he thinks Rob needs some training on supporting his community... Sheesh.

For all we know, could be a bot even. ;)

Regards,
Accession

... Take my advice, I don't use it anyway.
--- AmberEdit/linux 0.8.2
# Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/1)
ï¿­ Synchronet ï¿­ _thePharcyde telnet://bbs.pharcyde.org (Wisconsin)
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: User-Deactivate account: Still able to log in via SSH
By: Brian Davidson to GitLab note in main/sbbs on Sat Sep 12 2026 01:28 am

https://gitlab.synchro.net/main/sbbs/-/issues/1239#note_10343

I get not alarming the community when there is a rare exploit that only affects 1 or 2 systems, Rob. But that's not the case here. Disabling thhe user account is the front-line defense used by not just Synchronet, but most other apps that provide user-level access control. Regardless, the feature is there, and so is the vulnerability. Fixing the issue is the correct course of action. Closing this issue feels more like a denial of its existence and an abandonment of the author when Sysops need him the most, whether they realize it or not. I'm not trying to be difficult, but if this was any other software program, I believe this issue would have been handled differently. Support your community and they will return that support.

Kindly remove your opinionated hallucinating bot from my GitLab. Thanks,
--
digital man (rob)

Steven Wright quote #16:
When everything is coming your way, you're in the wrong lane.
Norco, CA WX: 86.0øF, 59.0% humidity, 9 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)