I wanted to enable access to V'Ger via Mosh, and I've been testing and
failing at every turn:

~$ mosh --ssh="ssh -p 22" -p 60050 vger.cloud
Unable to negotiate with UNKNOWN port 65535: no matching cipher found. Their offer: aes128-cbc,aes256-cbc,3des-cbc
/usr/bin/mosh: Did not find mosh server startup message.

and:

~$ mosh -p 60050 vger.cloud
Unable to negotiate with UNKNOWN port 65535: no matching cipher found. Their offer: aes128-cbc,aes256-cbc,3des-cbc
/usr/bin/mosh: Did not find mosh server startup message.

and:

~$ mosh vger.cloud
Unable to negotiate with UNKNOWN port 65535: no matching cipher found. Their offer: aes128-cbc,aes256-cbc,3des-cbc
/usr/bin/mosh: Did not find mosh server startup message.

and the same result if I try it with "username@vger.cloud".

My setup is as follows:

MIS on Debian/64 Bullseye

sshd: mystic@pts/22
sshd: OpenSSH (some other TCP port)

Connecting to V'Ger via mosh is without incident, when using the SSH port
that OpenSSH is listening to. Trying to initiate a Mosh session over the standard SSH port of TCP 22, where Mystic is listening doesn't work for me at all and no matter what, I get the errors above.

Your thoughts, suggestions?

Eventually, I want to completely EOL and eliminate Telnet access, but right now, considering it's really confusing for anyone to attempt to create a new account on the BBS via SSH I think it best to wait until g00r00 can
affect a bugfix for it.

Why?

Because, as it stands now, the [new] user has to login twice when attempting
to create a new account - the first time could be any combination of uid/pwd such as a username of 'uid' and a password of 'pwd', or new/new or new/pass
or whatev. It's not used anyway.

The second time they log in theyre actually creating their account but this
is not intuitive, so I'm leaving Telnet listening on TCP port 23 for the time being.

After someone has an account, there's some sort of pass-through, so they only have to go through two login sequences if they mis-type their username or password. If they get it right the first time, they are logged into the BBS
no problem.

I'm wondering if that is part of the problem related to why I can't login via Mosh?

I would really like to hear opinions on this and as to why I'm unable to use mosh to login, so if you've got any ideas, that would be awesome :)

Again, logging on to V'Ger the UNIX host works like a charm, but logging on
to V'Ger the BBS errors out.

I'm going to install a small Asterisk server on this box in about a month and start playing with dialup - or at least that's the time frame I'm looking at being ready to do that. If successful there, I'll prolly deploy a half dozen
or so DIDs from large metropolitan areas in various countries, but this SSH matter is kinda bothering me and I would really like to get rid of Telnet as soon as is practical, but that may include waiting until Netrunner w/SSH is
out of beta and in general release (SyncTerm and Qodem already support SSH).

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Vger.Cloud - NOMAD Internetwork (21:2/104)

On 10 Dec 2019, tallship said the following...

I wanted to enable access to V'Ger via Mosh, and I've been testing and failing at every turn:

~$ mosh --ssh="ssh -p 22" -p 60050 vger.cloud
Unable to negotiate with UNKNOWN port 65535: no matching cipher found. Their offer: aes128-cbc,aes256-cbc,3des-cbc
/usr/bin/mosh: Did not find mosh server startup message.

Connecting to V'Ger via mosh is without incident, when using the SSH port that OpenSSH is listening to. Trying to initiate a Mosh session over the standard SSH port of TCP 22, where Mystic is listening doesn't work for
me at all and no matter what, I get the errors above.

When attempting to connect via Windows Powershell, same (similar) thing:

PS C:\Users\tallship> ssh vger.cloud
Unable to negotiate with 2a01:4f9:c010:1eca::1 port 22: no matching cipher found. Their offer: aes128-cbc,aes256-cbc,3des-cbc
PS C:\Users\tallship>

And again,when attempting to connect to a UNIX shell (at the port number that OpenSSH is listening to) works without issue.

Your thoughts, suggestions?

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Vger.Cloud - NOMAD Internetwork (21:2/104)

And again,when attempting to connect to a UNIX shell (at the port
number that OpenSSH is listening to) works without issue.

Your thoughts, suggestions?

Probably cryptlib related. Cryptlib is behind in algorithms and doesn't
support the latest ones.

Andrew

--- MagickaBBS v0.13alpha (Linux/x86_64)
* Origin: HappyLand - telnet://magickabbs.com:2023/ (21:1/126)

Hello tallship!

On 10 Dec 2019, tallship said the following...

And again,when attempting to connect to a UNIX shell (at the port number that OpenSSH is listening to) works without issue.

Your thoughts, suggestions?

Must have something to do with Cryptlib -- I experienced the same thing with PuTTY and ssh, whereas SyncTERM works fine (but at what price?)...

Best regards
Zip

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (21:1/202)

On 11 Dec 2019, Zip said the following...

And again,when attempting to connect to a UNIX shell (at the port num that OpenSSH is listening to) works without issue.

Must have something to do with Cryptlib -- I experienced the same thing with PuTTY and ssh, whereas SyncTERM works fine (but at what price?)...

Yes, between apam and yourself suggesting this is the likely culprit, I tend
to think such is the case and there really isn't much I can do except wait until there are some updates to cryptlib.

As for myself, things are alittle weird in PuTTY/KiTTY and Powershell and
even from the UNIX shell using the OpenSSH SSH client through Bash or Ksh. SyncTerm, just seems to pass on through with one logon attempt - provided you login with an existing account and don't botch the password.

Someone here in fsxNet,, and I can't recall who or which BBS, posted a really nice piece on connecting via SSH in an article on their BBSes website.

When you first read it, it comes off like nonsense because it kinda doesn't seem to make sense (because it shouldn't act that way) until you actually try to create a new account on the MysticBBS, and then you realize it really does
act that way annd you really do need to complete two login sessions.

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Vger.Cloud - NOMAD Internetwork (21:2/104)

When attempting to connect via Windows Powershell, same (similar) thing:

PS C:\Users\tallship> ssh vger.cloud
Unable to negotiate with 2a01:4f9:c010:1eca::1 port 22: no matching
cipher found. Their offer: aes128-cbc,aes256-cbc,3des-cbc
PS C:\Users\tallship>

Mystic supports some pretty old ciphers. Its ssh implementation isn't all
that secure. Powershell won't work because it's biasing toward realistic security.

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: monterey bbs (21:1/168)

On 11 Dec 2019, ryan said the following...

When attempting to connect via Windows Powershell, same (similar) thi

Mystic supports some pretty old ciphers. Its ssh implementation isn't all that secure. Powershell won't work because it's biasing toward realistic security.

Powershell actually did work - to my surprise, although without ANSI support
it was rather ugly :)

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Vger.Cloud - NOMAD Internetwork (21:2/104)