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

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

Likely fixes #728

If the SSH_ANYAUTH option is set, the server will accept the "none"
authentication method, and not even suggest the client send a
password or public key.

The client must still send a user ID, but we just ignore it
completely and don't even log it.

This blindly accepts whatever authentication the remote offers, but
does not log into the BBS, dropping the user at the login prompt
instead.

Closes #726

You're welcome Keyop.

The other 500 times are implied.

Don't corrupt UTF-8 strings with SAFECOPY() (use new SAFECOPY_UTF8).

Some terminals (notably, Windows Terminal) display zero width UNICODE chars
as a single column-wide space. <sigh> Auto-detect the zero-width "width"
(1 or 0) of the terminal during connection and UTF-8 auto-detection.

getstr() works a lot better now with UTF-8 strings with wide chars (e.g.
emojis), but likely much more to do.

handler it.

Previously, once a pubkey was attempted, you could not use a password.

328:25: warning: ‘pubkey’ may be used uninitialized

Just running git commit --amend doesn't do -a it seems. :)

This should fix a long-standing issue where someone could connect to
the SSH port and do nothing, which would prevent other incoming
terminal sessions from being accepted until it times out.

Unfortunately, this means that Synchronet can't send any data until
authentication is completed, which means useful messages about why
you're being disconnected (ie: "Sorry, all terminal nodes are in use or otherwise unavailable.")
as well as usless information nobody ever cares about (ie: The IP
you're connecting from, that it is resolving your hostname, etc).
can no longer be sent to the user.

comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]

SSH channels, I noticed that I hand't ever finished the terminal
type/size "stuff", and while fixing that, I noticed that the hack
for SyncTERM was done wrong.

Fix the whole thing, and now Synchronet and SyncTERM both properly
support terminal type and size over SSH.  It also looks trivial to
support the SSH window size change message, but I'm not doing that
tonight.

Unfortunately, this is a patch on a patch, so is a bit fragile.
It should really have the patches merged at some point.

- New keys in [BBS] section of sbbs.ini:
  MaxLoginInactivity (default: 10 minutes)
  MaxNewUserInactivity (default: 60 minutes)
  MaxSessionInactivity (default: none/unlimited)
- Each configured external program/door in SCFG can have its own maximum inactivity setting (or else the session max inactivity is applied)
- moved node-specific sec_hangup to system-wide/shared max_getkey_inactivity (configured in SCFG->System->Advanced)
- moved node-specific sec_warn (seconds of inactivity before sending warning) to inactivity_warn (a percentage of elapsed max inactivity before sending warning), also configured in SCFG->System->Advanced and used for both socket and getkey inactivity detection
- Renamed JS console.inactivity_hangup to console.max_getkey_inactivity (old name remains as alias)
- Renamed JS console.timeout to console.last_getkey_activity (old name remains as alias)
- Removed JS console.inactivity_warning
- Added JS console.max_socket_inactivity (current input_thread inactivity threshold)
- New text.dat string: InactivityAlert (just contains 3 ^G/BELLs by default) used for non-visual inactive-user warning

The MaxLoginInactivity setting in particular solves the problem of custom scripts (e.g. animated pause prompts) that just poll indefinitely for user input and never time-out  - these will no longer cause nodes to be tied-up with inactive/bot users at login.

You may ask yourself, how did I get here? No, you may ask yourself: why configure these socket inactivity max values in sbbs.ini? The reason is consistency: sbbs.ini is where the MaxInactivity is configured for all the other TCP servers and services.

This fixes issue #534 for Krueger in #synchronet

Mostly [s]printf format fixups

Previously, many servers and services didn't support login by real name
(e.g. issue #469) even if the sysop had that option enabled in SCFG.

Move login control settings from node.ini to system (main.ini -> login)

The 3 node toggle options:
- Allow Login by User Number
- Allow Login by Real Name
- Always Prompt for Password

... have been now moved from SCFG->Nodes->Node x->Toggle Options to
SCFG-System->Toggle Options.

If you upgraded to v3.20a before now, you'll want to double-check these
settings to make sure they're how you want them set. New upgraders that run
upgrade_to_v320.js (e.g. via 'jsexec update') will get these settings migrated
automatically.

Added some error detection/logging to upgrade_to_v320.js when failing to open
.cnf files.

Constified some more user/login related function args and return types.

This addresses issue #459 (Synchronet never allowed SSH-auth via real name)

Also, localize the "valid real name" checking logic into a single new function:
check_realname()

Also resolved some 32 vs 64-bit 'long' issues/ambiguities that have long-remained. :-)

This commit also removes logon.lst file support.

There's a TODO block remaining in js_user.c for setting portions of a user's birthdate (e.g. just the year or month or day).

As Andre pointed out while documenting this setting on the wiki, the option seemed confusing: if a sysop could not login with "system operator access", how could they login at all? Answer: they could not.

This setting used to be called "Allow Remote Sysop Logins", back when there was the concept of a "local login", so setting this option to "No" would mean that user accounts with sysop access could only be used for *local* login. But in Synchronet v3, there's really no such concept as a "local login", so it was changed to just "Allow Sysop Logins" (period) and not a lot of thought given to how/why a sysop would actually set to this "No" or what the implications would be (presumably, nobody ever sets this to "No").

So rather than just get rid if the option altogether, I changed it to mean: an account with sysop access (i.e. level 90+) can still login, but any action that normally requires the system password will not be allowed. This includes the sysop-actions available in the FTP server when authenticating with <user-pass>:<system-pass> as the password. The sysop-user can still authenticate (and login), but none of those sysop-actions will be available to them.

Feature 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.

In preparation for node-spy applications that can support multiple terminal sizes/types (none exist yet). The file is updated whenever there is new/updated information about the client's terminal.

Exposed as JS method: console.term_updated().

This 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.

This 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.

automatically revert to Raw/TCP mode. This resolves the issue of users that
connect using modem/serial emulators over TCP that do not actually support Telnet and then either try to transfer files, which usually will not work due to escaped (or unescaped) IAC (0xFF) characters, or the user may be sent Telnet Go Ahead (GA) sequences which may display as periodic garbage in their terminal program.

This seemed like a better solution than having (yet another) dedicated terminal server port for "raw" connections over TCP, though a "raw" port still might not be a bad idea for a future enhancement. RLogin is already super close to "raw", so it's probably not really necessary to have another port configured/listening.

- hot spots are clickable screen areas (e.g. in menus and prompts) that   generate key-strokes
- commands may be from 1 to 127 ASCII-characters in length
- currently using the X10 mouse reporting mode, may change
- all mnemonics strings (~Example) are automatically hot-spots
- The new ~ @-code defines a hot spot
- Any screen-clear operation clears all hot spots
- sbbs now tracks the current screen (cursor position) row
- eliminated the old "tos" (top-of-screen) boolean (row == 0 indicates "tos")
- created an sbbs_t::ungetstr() method
- keep track if in pause (hit a key) prompt, for special mouse behavior

new JS console object:
- row property
- tos property is now read-only (and deprecated)
- new methods:
  add_hotspot()
  clear_hotspots()
  scroll_hotspots()

redrwstr() gets some UTF8 touch-ups as part of this commit. <shrug>

Fixed bug: for RLogin and SSH, if an invalid (e.g. blank) passsword was
provided during the handshake, an "Invalid Logon" would be displayed followed
by a "Passowrord: " prompt, giving the user an opportunity to reenter the
correct password. Only problem: this only worked for sysop accounts. Normal
users would just be disconnected after they entere (any) password, correct
or not.

This bug is very old in the RLogin support and appears to have been copy/pasted
for the SSH Login bit too.

and RLogin attempts.
It looks like someone copy/pasted the wrong lines from login.cpp.