• Mosh

    From tallship@21:2/104 to All on Tue Dec 10 10:14:05 2019
    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)
  • From tallship@21:2/104 to All on Wed Dec 11 03:05:30 2019
    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)
  • From apam@21:1/126 to tallship on Wed Dec 11 21:42:38 2019

    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)
  • From Zip@21:1/202 to tallship on Thu Dec 12 02:36:59 2019
    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)
  • From tallship@21:2/104 to Zip on Wed Dec 11 20:27:43 2019
    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)
  • From ryan@21:1/168 to tallship on Thu Dec 12 02:42:42 2019
    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)
  • From tallship@21:2/104 to ryan on Fri Dec 13 03:39:23 2019
    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)