1. Forum
  2. Fidonet
  3. SYNC SYSOPS

  • User-Deactivate account: Still able to log in via SSH

    From Jerry Reed@1:103/705 to GitLab issue in main/sbbs on Fri Sep 11 08:53:33 2026
    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)
  • From xbit ops@1:103/705 to GitLab note in main/sbbs on Fri Sep 11 08:56:35 2026
    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)
  • From Brian Davidson@1:103/705 to GitLab note in main/sbbs on Fri Sep 11 10:44:24 2026
    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)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Fri Sep 11 11:33:21 2026
    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)
  • From Brian Davidson@1:103/705 to GitLab note in main/sbbs on Fri Sep 11 12:15:30 2026
    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)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Fri Sep 11 13:45:25 2026
    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)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Fri Sep 11 13:45:44 2026
    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)
  • From Rob Swindell@1:103/705 to GitLab issue in main/sbbs on Fri Sep 11 14:41:30 2026
    close https://gitlab.synchro.net/main/sbbs/-/issues/1239
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Jerry Reed@1:103/705 to GitLab note in main/sbbs on Fri Sep 11 18:26:22 2026
    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)
  • From Matthew Asham@1:103/705 to GitLab note in main/sbbs on Fri Sep 11 19:42:19 2026
    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)
  • From Brian Davidson@1:103/705 to GitLab note in main/sbbs on Sat Sep 12 01:28:10 2026
    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)