As all of you, I too ran a BBS in the 90s, some of you earlier, and have very good memories of that time.
Nowadays, with all the advances in information security, why are we still using a plaintext protocol like telnet to access a BBS?
Browsing the synchronet BBS list, I find only a handfull of BBSs that offer SSH access.
As far as I can tell, correct me if I'm wrong, Synchronet maybe using outdated/obsolete cryptography in it's SSH implementation.
I'm running Debian Linux and I know that I can use a better client, such as SyncTerm, but the fact that BBSs advertise their access through an insecure protocol like telnet is not safe, shouldn't we switch to a secure form of communication?
Al wrote to Pedro Silva <=-
@TZ: c1e0
Re: Telnet vs SSH
By: Pedro Silva to All on
Sat Sep 24 2016 10:18 pm
I guess we transitioned from dial-up to telnet and things have more or less stayed that way. I should advertise RLogin and SSH as well as
telnet.
I almost always use syncterm for times when I want to login with ssh simply because I have zmodem and friends at my disposal. If it was possible to login with ssh proper, how would we transfer files?
Hello All,
I tried using a standard ssh client (openssh) and was unable to connect to any Synchronet BBS through SSH. The problem was always the same: Handshake failed. From what I could see, today's Linux Distributions have blacklisted some types of cryptos due to the fact that they are no longer secure.
Even browsing the BBS through a web browser can be configured to use a free SSL certificate, such as letsencrypt.org, to encrypt all the traffic between the BBS and the user.
Al wrote to Pedro Silva <=-
@TZ: c1e0
Re: Re: Telnet vs SSH
By: Pedro Silva to Al on
Sun Sep 25 2016 12:44 am
Even browsing the BBS through a web browser can be configured to use a free SSL certificate, such as letsencrypt.org, to encrypt all the traffic between the BBS and the user.
I hadn't even thought of that. How do I get a certificate, and once I
have it how do I install it in the server?
Hemo wrote to Pedro Silva <=-
@TZ: c168
Re: Telnet vs SSH
By: Pedro Silva to All on
Sat Sep 24 2016 10:18 pm
Hello All,
I tried using a standard ssh client (openssh) and was unable to connect to any Synchronet BBS through SSH. The problem was always the same: Handshake failed. From what I could see, today's Linux Distributions have blacklisted some types of cryptos due to the fact that they are no longer secure.
strange. I've had no issues connecting to various systems using ssh
from PuTTY or openssh from linux command line.
Are you forcing your connection to use only a single protocol ?
Hello All,
I tried using a standard ssh client (openssh) and was unable to
connect to any Synchronet BBS through SSH. The problem was always
the same: Handshake failed. From what I could see, today's Linux
Distributions have blacklisted some types of cryptos due to the fact
that they are no longer secure.
strange. I've had no issues connecting to various systems using ssh
from PuTTY or openssh from linux command line.
No, let me show it:
$ ssh -vv guest@vert.synchro.net
OpenSSH_7.3p1 Debian-1, OpenSSL 1.0.2h 3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
OpenSSH_7.3p1 Debian-1, OpenSSL 1.0.2h 3 May 2016
71.95.196.34 port 22:2: Handshake failed Disconnected from 71.95.196.34 port 22
If I explicit use KEX algorithm diffie-hellman-group1-sha1, I can connect: $ ssh -o KexAlgorithms=diffie-hellman-group1-sha1 guest@vert.synchro.net The authenticity of host 'vert.synchro.net (71.95.196.34)' can't be established.
Are you sure you want to continue connecting (yes/no)? yes guest@vert.synchro.net's password:
From what I understand, by default, Synchronet uses a deprecated SSH algorithm, which openssh can only use if forced.
From the OpenSSH legacy page (http://www.openssh.com/legacy.html): "OpenSSH implements all of the cryptographic algorithms needed for compatibility with standards-compliant SSH implementations, but since some of the older algorithms have been found to be weak, not all of them are enabled by default."
Hemo wrote to Pedro Silva <=-
@TZ: c168
Re: Re: Telnet vs SSH
By: Pedro Silva to Hemo on
Sun Sep 25 2016 09:33 am
again.. I guess it's in semantics. legacy is not the same as
deprecated. On the most recent release notes for OpenSSH, they are
stating a future deprication, for now it is legacy and to get users accustomed to a future deprecation, they disable it by default. But
only on new installations.
[1m[34mRe[0m[34m: [1m[36mRe: Telnet vs SSH
[34mBy[0m[34m: [1m[36mPedro Silva [34mto [36mHemo [34mon
[36mSun Sep 25 2016 09:33 am[0m
again.. I guess it's in semantics. legacy is not the same as
deprecated. On the most recent release notes for OpenSSH, they are
stating a future deprication, for now it is legacy and to get users
accustomed to a future deprecation, they disable it by default. But
only on new installations.
Hemo, thank you for your feedback.
You're right, semantics. They are legacy on their way to deprication. Does Synchronet handle the SSH connections or is there an SSH server that relays the connections to Synchronet?
What's your opinion on advertising telnet access to the boards in 2016?
Hemo wrote to Pedro Silva <=-
What's your opinion on advertising telnet access to the boards in 2016?
I think it depends on a lot of variables. A lot of the boards don't
have anything going on that requires anything extra-secure, and those
that do likely aren't advertising themselves in the BBS List.
I myself am leaning towards removing telnet access, simply because it
will greatly reduce the number of login attempts from scripted bots
that are looking to exploit unsecured routers, etc.
I myself am leaning towards removing telnet access, simply because it
will greatly reduce the number of login attempts from scripted bots
that are looking to exploit unsecured routers, etc.
25 Sep 16 15:22, you wrote to Pedro Silva:
I myself am leaning towards removing telnet access, simply because
it will greatly reduce the number of login attempts from scripted
bots that are looking to exploit unsecured routers, etc.
just change the default port... you will have the same problems on other default ports for other protocols, too...
Hello All,
As all of you, I too ran a BBS in the 90s, some of you earlier, and have very good memories of that time.
Nowadays, with all the advances in information security, why are we still using
a plaintext protocol like telnet to access a BBS?
Browsing the synchronet BBS list, I find only a handfull of BBSs that offer SSH
access.
As far as I can tell, correct me if I'm wrong, Synchronet maybe using outdated/obsolete cryptography in it's SSH implementation.
I tried using a standard ssh client (openssh) and was unable to connect to any
Synchronet BBS through SSH. The problem was always the same: Handshake failed.
From what I could see, today's Linux Distributions have blacklisted some types
of cryptos due to the fact that they are no longer secure.
I'm running Debian Linux and I know that I can use a better client, such as SyncTerm, but the fact that BBSs advertise their access through an insecure protocol like telnet is not safe, shouldn't we switch to a secure form of communication?
Looking forward to talking about this with you.
Best regards,
Pedro Silva
Ragnarok wrote to Pedro Silva <=-
Synchronet use cryplib to get the ssh secure protocol. I'm package SyncTerm for deban and i can't make that are acepted due several
problems including the cryptlib usage =(
Pedro Silva wrote to All <=-
Hello All,
As all of you, I too ran a BBS in the 90s, some of you earlier, and
have very good memories of that time.
Nowadays, with all the advances in information security, why are we
still using a plaintext protocol like telnet to access a BBS?
Browsing the synchronet BBS list, I find only a handfull of BBSs that
Hemo wrote to Pedro Silva <=-
@TZ: c168
Re: Telnet vs SSH
By: Pedro Silva to All on
Sat Sep 24 2016 10:18 pm
Hello All,
I tried using a standard ssh client (openssh) and was unable to connect to any Synchronet BBS through SSH. The problem was always the same: Handshake failed. From what I could see, today's Linux Distributions have blacklisted some types of cryptos due to the fact that they are no longer secure.
strange. I've had no issues connecting to various systems using ssh from PuTTY or openssh from linux command line.
Are you forcing your connection to use only a single protocol ?
No, let me show it:
$ ssh guest@vert.synchro.net
Received disconnect from 71.95.196.34 port 22:2: Handshake failed Disconnected from 71.95.196.34 port 22
$ ssh -vv guest@vert.synchro.net
OpenSSH_7.3p1 Debian-1, OpenSSL 1.0.2h 3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "vert.synchro.net" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to vert.synchro.net [71.95.196.34] port 22.
debug1: Connection established.
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.3p1 Debian-1
debug1: Remote protocol version 2.0, remote software version cryptlib debug1: no match: cryptlib
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to vert.synchro.net:22 as 'guest'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh -sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffi e-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group- exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext- info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa- sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com, ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nis tp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-s ha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,ae s256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc ,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,ae s256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc ,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha 2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.co m,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac- sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha 2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.co m,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac- sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha256,diffie-hellman- group-exchange-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa
debug2: ciphers ctos: 3des-cbc,aes128-cbc,blowfish-cbc
debug2: ciphers stoc: 3des-cbc,aes128-cbc,blowfish-cbc
debug2: MACs ctos: hmac-sha2-256,hmac-sha1,hmac-md5
debug2: MACs stoc: hmac-sha2-256,hmac-sha1,hmac-md5
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-cbc MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-cbc MAC: hmac-sha2-256 compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent
Received disconnect from 71.95.196.34 port 22:2: Handshake failed Disconnected from 71.95.196.34 port 22
If I explicit use KEX algorithm diffie-hellman-group1-sha1, I can connect:
$ ssh -o KexAlgorithms=diffie-hellman-group1-sha1 guest@vert.synchro.net
The authenticity of host 'vert.synchro.net (71.95.196.34)' can't be established.
RSA key fingerprint is SHA256:ykpQTWSMSyqkLXyWlNC7zfWvnxtt0wGCGk0ZLyWALog. Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'vert.synchro.net,71.95.196.34' (RSA) to the list of known hosts.
guest@vert.synchro.net's password:
Synchronet BBS for Win32 Version 3.17
Connection from: 77.54.101.23
Resolving hostname...
<snip>
From what I understand, by default, Synchronet uses a deprecated SSH algorithm, which openssh can only use if forced.
From the OpenSSH legacy page (http://www.openssh.com/legacy.html):
"OpenSSH implements all of the cryptographic algorithms needed for compatibility with standards-compliant SSH implementations, but since some of the older algorithms have been found to be weak, not all of them are enabled by default."
| Sysop: | Ragnarok |
|---|---|
| Location: | Dock Sud, Bs As, Argentina |
| Users: | 136 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 43:36:59 |
| Calls: | 15,172 |
| Calls today: | 1 |
| Files: | 19,861 |
| D/L today: |
24 files (4,260K bytes) |
| Messages: | 1,693,094 |