Hey, r0ckstars. So I moved 2o to a new x86 server from my Raspberry Pi. Everything about the system, hostname, directory structure, where everything gets mounted and lives - is the exact same.

I have a /mystic/doorparty directory that holds a 20_DP.sh script to 'boot' DoorParty and a /mystic/doorparty/dpc2 directory that holds doorparty-connector; the listener for DoorParty. I had to re-compile that tool because the old one was ARM and this system is x86.

I have a doorparty-connector.service file thats loaded into systemd. Heres the status:

doorparty-connector.service - DoorParty Connector
Loaded: loaded (/etc/systemd/system/doorparty-connector.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2022-06-28 09:51:50 PDT; 3 days ago
Main PID: 428 (doorparty-conne)
Tasks: 7 (limit: 9508)
Memory: 20.9M
CPU: 912ms
CGroup: /system.slice/doorparty-connector.service
ÀÄ428 /home/xxx/mystic/doorparty/dpc2/doorparty-connector

Jul 01 09:43:46 bbs doorparty-connector[428]: 2022/07/01 09:43:46 [20] connecting to RLogin server dp.throwbackbbs.com:513 via SSH tunnel
Jul 01 09:43:46 bbs doorparty-connector[428]: 2022/07/01 09:43:46 [20] starting RLogin session, terminal type:
Jul 01 09:43:46 bbs doorparty-connector[428]: 2022/07/01 09:43:46 [20] connected to RLogin server dp.throwbackbbs.com:513 via SSH tunnel
Jul 01 09:43:46 bbs doorparty-connector[428]: 2022/07/01 09:43:46 [20] disconnected
Jul 01 09:57:02 bbs doorparty-connector[428]: 2022/07/01 09:57:02 Accepted connection
Jul 01 09:57:03 bbs doorparty-connector[428]: 2022/07/01 09:57:03 [20] connected to SSH server dp.throwbackbbs.com:2022
Jul 01 09:57:03 bbs doorparty-connector[428]: 2022/07/01 09:57:03 [20] connecting to RLogin server dp.throwbackbbs.com:513 via SSH tunnel
Jul 01 09:57:03 bbs doorparty-connector[428]: 2022/07/01 09:57:03 [20] starting RLogin session, terminal type:
Jul 01 09:57:03 bbs doorparty-connector[428]: 2022/07/01 09:57:03 [20] connected to RLogin server dp.throwbackbbs.com:513 via SSH tunnel
Jul 01 09:57:03 bbs doorparty-connector[428]: 2022/07/01 09:57:03 [20] disconnected

However, when I try to run DoorParty, or even any DP door game by itself, my users are seeing this error and no DoorParty:

kex_exchange_identification: banner line contains invalid characters
banner exchange: Connection to 127.0.0.1 port 9999: invalid format

??? I first thought this was an SSH issue - because my SSH connections weren't working - but I've since fixed the SSH/Cryptlib error, erased ssl.cert and SSH connections are now working on 2o... but the DoorParty kex_exchange_identification issue is still there.

The 20_DP.sh script is:
#!/bin/bash

prefix="[20]"
user=${1//_/ }

if [ $# -eq 2 ]; then
TERM=$2 rlogin -p 9999 -l "$prefix$user" localhost

else
rlogin -p 9999 -l "$prefix$user" localhost

fi

I thought the user=${1//_/ } line looked wonky, but even if I enter:
rlogin -p 9999 -l "[20]paulie420" localhost

I get the same kex error... where am I missing something? the DP.service is listening on port 9999... this worked perfectly on my old system - but I'm forgetting something or not setting something up thats needed. Any ideas? Thanks for making it to the end with me. UGH. :P

I did one more thing... manually ran the rlogin command thats in 20_DP.sh with a -vv to get the output of WHY theres a kex_exchange issue. I think the details are here... remember, I copied the bbs files from my old machine and ... I'm just not informed enough to read this output... what on my new system am I gonna have to change!! :P:

xxx@bbs:~/mystic/doorparty$ rlogin -p 9999 -vv localhost
OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1n 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolving "localhost" port 9999
debug2: ssh_connect_direct
debug1: Connecting to localhost [::1] port 9999.
debug1: connect to address ::1 port 9999: Connection refused
debug1: Connecting to localhost [127.0.0.1] port 9999.
debug1: Connection established.
debug1: identity file /home/pi/.ssh/id_rsa type 0
debug1: identity file /home/pi/.ssh/id_rsa-cert type -1
debug1: identity file /home/pi/.ssh/id_dsa type -1
debug1: identity file /home/pi/.ssh/id_dsa-cert type -1
debug1: identity file /home/pi/.ssh/id_ecdsa type -1
debug1: identity file /home/pi/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/pi/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/pi/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/pi/.ssh/id_ed25519 type -1
debug1: identity file /home/pi/.ssh/id_ed25519-cert type -1
debug1: identity file /home/pi/.ssh/id_ed25519_sk type -1
debug1: identity file /home/pi/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/pi/.ssh/id_xmss type -1
debug1: identity file /home/pi/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-5 kex_exchange_identification: banner line contains invalid characters
banner exchange: Connection to 127.0.0.1 port 9999: invalid format

|07p|15AULIE|1142|07o
|08.........

--- Mystic BBS v1.12 A48 2022/04/26 (Linux/64)
* Origin: 2o fOr beeRS bbs>>>20ForBeers.com:1337 (21:2/150)

Hello paulie420!

On 01 Jul 2022, paulie420 said the following...

kex_exchange_identification: banner line contains invalid characters banner exchange: Connection to 127.0.0.1 port 9999: invalid format

Not sure (as it mentions the banner line), but could it be due to the receiver (127.0.0.1 port 9999) using ssh-rsa (SHA-1) algorithm?

Please see the following two pages:

https://levelup.gitconnected.com/demystifying-ssh-rsa-in-openssh-deprecation-no tice-22feb1b52acd

https://lwn.net/Articles/821544/

You might want to try adding:

-oHostKeyAlgorithms=+ssh-rsa

...right after "rlogin" in the script to see if that helps.

However OpenSSH providing the rlogin command appears to be kind of a mess (for instance, the man page for rlogin/ssh mentions very little about rlogin)...

If the above doesn't work, maybe the "rsh-redone-client" package would help?

https://packages.debian.org/bullseye/rsh-redone-client

(That one is for Debian Bullseye -- not sure what you are running?)

Then the 'rlogin' command would have to be replaced with 'rsh-redone-rlogin'.

Hoping some of this helps. =)

Best regards
Zip

--- Mystic BBS v1.12 A48 2022/04/26 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

kex_exchange_identification: banner line contains invalid characters banner exchange: Connection to 127.0.0.1 port 9999: invalid format

Not sure (as it mentions the banner line), but could it be due to the receiver (127.0.0.1 port 9999) using ssh-rsa (SHA-1) algorithm?

Yes, it is... I disallow passworld logins, and use rsa keys.

You might want to try adding:
-oHostKeyAlgorithms=+ssh-rsa
...right after "rlogin" in the script to see if that helps.

Tried that - and the outcome was the exact same kex_exchange issue... good idea, but no difference. :P

However OpenSSH providing the rlogin command appears to be kind of a
mess (for instance, the man page for rlogin/ssh mentions very little
about rlogin)...

Not following you, which I really want to because -

If the above doesn't work, maybe the "rsh-redone-client" package would help?
https://packages.debian.org/bullseye/rsh-redone-client
(That one is for Debian Bullseye -- not sure what you are running?)

I'm on Debian, yea... and can you imagine - right after sudo apt install rsh-redone-client, B00M DoorParty fires right up just like normal!!! Super thank yous for all of your suggestions...

I wanna grasp what made you think of this - yer saying that you noticed OpenSSH was handling rlogin? What made you think or find the rsh-redone package?

That was a fix - I never thought to myself that it was the actual rlogin binary that needed attention, and not my setup... I was thinking it had SOMETHING to do with my SSH keys or some keys that I didn't know about.

Regardless, THANK YOU ZIP!!!! w00t w00t; all of 2o's 'things' are fixed and working perfectly [ha] on the new server!

Hoping some of this helps. =)
Best regards
Zip

Mucho mucho gracias - this one was driving me insane. It takes a village - glad you thought of the fix.



|07p|15AULIE|1142|07o
|08.........

--- Mystic BBS v1.12 A48 2022/04/26 (Linux/64)
* Origin: 2o fOr beeRS bbs>>>20ForBeers.com:1337 (21:2/150)

Hello paulie420!

I'm on Debian, yea... and can you imagine - right after sudo apt install rsh-redone-client, B00M DoorParty fires right up just like normal!!!
Super thank yous for all of your suggestions...

That's great! :)

I wanna grasp what made you think of this - yer saying that you noticed OpenSSH was handling rlogin? What made you think or find the rsh-redone package?

I remember trying to use rlogin on my box to connect to Mystic's built-in RLOGIN server, but never getting it to work:

bbs@glimmer:~$ rlogin -vv -p 61513 new@scbbs.nsupdate.info
OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1n 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolving "scbbs.nsupdate.info" port 61513
debug2: ssh_connect_direct
debug1: Connecting to scbbs.nsupdate.info [188.149.153.205] port 61513.
debug1: Connection established.
debug1: identity file /home/bbs/.ssh/id_rsa type -1
debug1: identity file /home/bbs/.ssh/id_rsa-cert type -1
debug1: identity file /home/bbs/.ssh/id_dsa type -1
debug1: identity file /home/bbs/.ssh/id_dsa-cert type -1
debug1: identity file /home/bbs/.ssh/id_ecdsa type -1
debug1: identity file /home/bbs/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/bbs/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/bbs/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/bbs/.ssh/id_ed25519 type -1
debug1: identity file /home/bbs/.ssh/id_ed25519-cert type -1
debug1: identity file /home/bbs/.ssh/id_ed25519_sk type -1
debug1: identity file /home/bbs/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/bbs/.ssh/id_xmss type -1
debug1: identity file /home/bbs/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-5
debug1: kex_exchange_identification: banner line 0: \033[1;1H\033[2J\033[1;1H\033[?1000h\014Mystic BBS Version 1.12 A48
debug1: kex_exchange_identification: banner line 1: Copyright (C) 1997-2022 By James Coyle
debug1: kex_exchange_identification: banner line 2:
debug1: kex_exchange_identification: banner line 3: Detecting terminal emulation: \033[s\033[255BASCII detected.
debug1: kex_exchange_identification: banner line 4:
debug1: kex_exchange_identification: banner line 5: (0) ASCII (no color) debug1: kex_exchange_identification: banner line 6: (1) ANSI (color)
debug1: kex_exchange_identification: banner line 7:
^C
bbs@glimmer:~$

Apparently it got stuck in the ANSI/ASCII detection for some reason.

When checking the man page for rlogin ('man rlogin'), I noticed that this actually brought up the man page for ssh. When checking what the rlogin command led to, I found:

bbs@glimmer:~$ which rlogin
/usr/bin/rlogin

bbs@glimmer:~$ ls -l /usr/bin/rlogin
lrwxrwxrwx 1 root root 24 aug 11 2018 /usr/bin/rlogin -> /etc/alternatives/rlogin

bbs@glimmer:~$ ls -l /etc/alternatives/rlogin
lrwxrwxrwx 1 root root 15 aug 11 2018 /etc/alternatives/rlogin -> /usr/bin/slogin

bbs@glimmer:~$ ls -l /usr/bin/slogin
lrwxrwxrwx 1 root root 3 mar 13 2021 /usr/bin/slogin -> ssh

So it was a path of links which ended up at the ssh command.

This combined with the fact that the man page didn't mention very much at all about rlogin made me think that perhaps the rlogin implementation in ssh wasn't working very well.

Then I googled "Debian bullseye rlogin", which brought me to the Debian package search, and there (https://packages.debian.org/search?suite=bullseye&arch=amd64&searchon=contents
&keywords=rlogin) I found out that the rlogin "file" was provided by multiple packages.

One of them was the package "rsh-client", about which it says that also "openssh-client" provides it, i.e. the OpenSSH package (that the ssh command comes with). So that's where rlogin on my system came from.

I thought that installing one of the alternatives (rsh-client or rsh-redone-client) would work -- at least in a different way! -- and apparently "rsh-redone-client" was the newer one of these, so seemed like a good candidate. :-D

And the reason why this would work without changing the commands in the script is that it uses the "alternatives" selection/linking system for choosing the appropriate command (i.e. choosing rlogin from "rsh-redone-client" instead of rlogin from "openssh-client").

Regardless, THANK YOU ZIP!!!! w00t w00t; all of 2o's 'things' are fixed and working perfectly [ha] on the new server!

Glad to hear that, and glad to be able to help! =)

Best regards
Zip

--- Mystic BBS v1.12 A48 2022/04/26 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

Quoting message from Paulie420 to Zip
on 01 Jul 22 17:15:52 ...

I'm on Debian, yea... and can you imagine - right after sudo apt install rsh-redone-client, B00M DoorParty fires right up just like normal!!! Super thank yous for all of your suggestions...

hahahaha I had this same issue. I think the Doorparty documentation tells you that you need to install this -- because I'm sure as hell not smart enough to figure it out on my own!

Glad you're up and running 100%.

-ZR

... I love cats. On a good night, I can eat 5 or 6 of 'em...

--- Renegade v1.30/DOS
* Origin: AlcoholidayBBS.com / Est. 1995 / Columbia, SC (21:4/177.1)

I remember trying to use rlogin on my box to connect to Mystic's built-in RLOGIN server, but never getting it to work:
debug1: kex_exchange_identification:

Apparently it got stuck in the ANSI/ASCII detection for some reason.

bbs@glimmer:~$ ls -l /usr/bin/slogin
lrwxrwxrwx 1 root root 3 mar 13 2021 /usr/bin/slogin -> ssh

So it was a path of links which ended up at the ssh command.

Then I googled "Debian bullseye rlogin", which brought me to the Debian package search, and there I found out that the rlogin "file" was provided Zi> by multiple packages.

One of them was the package "rsh-client"

I thought that installing one of the alternatives (rsh-client or rsh-redone-client) would work -- at least in a different way! -- and apparently "rsh-redone-client" was the newer one of these, so seemed
like a good candidate. :-D

And the reason why this would work without changing the commands in the script is that it uses the "alternatives" selection/linking system for choosing the appropriate command (i.e. choosing rlogin from "rsh-redone-client" instead of rlogin from "openssh-client").

And b00m, now I know exactly why Debian's rlogin was throwing an error I couldn't figure out. Appeciate the explanation even more than the fix - I think I'd of been tied up over this for a lot longer w/o the help.

It takes a village...

Glad to hear that, and glad to be able to help! =)

:P Very much. Thanks again, kind sir.



|07p|15AULIE|1142|07o
|08.........

--- Mystic BBS v1.12 A48 2022/04/26 (Linux/64)
* Origin: 2o fOr beeRS bbs>>>20ForBeers.com:1337 (21:2/150)

I'm on Debian, yea - right after sudo apt install rsh-redone-client, ZR> P> B00M DoorParty fires right up just like normal!!!

hahahaha I had this same issue. I think the Doorparty documentation
tells you that you need to install this -- because I'm sure as hell not smart enough to figure it out on my own!

You know, that was gonna be my NEXT course of action - RTFM. :P



|07p|15AULIE|1142|07o
|08.........

--- Mystic BBS v1.12 A48 2022/04/26 (Linux/64)
* Origin: 2o fOr beeRS bbs>>>20ForBeers.com:1337 (21:2/150)

Hello paulie420!

On 02 Jul 2022, paulie420 said the following...

:P Very much. Thanks again, kind sir.

You're very welcome! =)

Best regards
Zip

--- Mystic BBS v1.12 A48 2022/04/26 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)