I tried enabling SSH a few days ago, to no avail. I got sidetracked on a couple of other projects and got back to it a few minutes ago.

I tried starting the SSH server - nothing. I have port 22 open in the firewall.

Then I tried stopping and restarting MIS - still nothing, so I nmap'd it - Here's what I've got:

Starting Nmap 7.70 ( https://nmap.org ) at 2019-09-08 05:41 PDT
Nmap scan report
Host is up (0.000030s latency).
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
23/tcp open telnet
| fingerprint-strings:
| GenericLines:
| [8;25;80t
| [1;25r
| [1;1H
| [1;1H
| [?1000h
| Mystic BBS v1.12 A43 for Linux Node 1
| Copyright (C) 1997-2019 By James Coyle
| Detecting terminal emulation:
| [6nASCII detected.
| Ascii (No Color)
| Ansi (Color)
| Graphics Mode ->
| NULL:
| [8;25;80t
| [1;25r
| [1;1H
| [1;1H
| [?1000h
| Mystic BBS v1.12 A43 for Linux Node 1
| Copyright (C) 1997-2019 By James Coyle
|_ Detecting terminal emulatio

So... Does Mystic even include an SSH Daemon? My boxes OS has SSHD running and listening on a non-standard port, but that's not for the BBS. If Mystic accepts SSH connections through some kind of hook using the host's Daemon I can just install and run a separate instance of OpenSSH, but wanted to check here first to make sure I don't clobber port 22.

Thanks :)

So... Does Mystic even include an SSH Daemon?

Yes, it does. It requires that you have cryptlib installed. I forget the details but there is a writeup in the wiki that explains it.

It's a newer addition to Mystic and I haven't tested it much.

My boxes OS has SSHD running an listening on a non-standard port, but that's not for the BBS.

That's not a problem. Mystics ssh server can also run on another port.

--- BBBS/Li6 v4.10 Toy-4
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

On 09-08-19 06:18, Bradley D. Thornton wrote to All <=-

So... Does Mystic even include an SSH Daemon? My boxes OS has SSHD running and listening on a non-standard port, but that's not for the
BBS. If Mystic accepts SSH connections through some kind of hook using the host's Daemon I can just install and run a separate instance of OpenSSH, but wanted to check here first to make sure I don't clobber
port 22.

Yes, Mystic has its own SSH server. You have to enable a SSH server in Mystic's setup.

Now, are you starting Mystic as root or an ordinary user? By default, ordinary users can't bind ports below 1024 on Linux. You either have to start Mystic as root (it will run as the user that owns its directory once it has bound its ports), or give the mis binary permission to bind privileged ports. I've tried both ways successfully, but now do the latter, because it's more convenient.


... The rich will do anything for the poor but get off their backs.
=== MultiMail/Win v0.51
--- SBBSecho 3.03-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

Re: Re: Mystic SSHD won't start? Is there an SSH server?
By: Tony Langdon to Bradley D. Thornton on Mon Sep 09 2019 09:09 am

On 09-08-19 06:18, Bradley D. Thornton wrote to All <=-

So... Does Mystic even include an SSH Daemon? My boxes OS has SSHD running and listening on a non-standard port, but that's not for the
BBS. If Mystic accepts SSH connections through some kind of hook using the host's Daemon I can just install and run a separate instance of
OpenSSH,
but wanted to check here first to make sure I don't clobber
port 22.

Yes, Mystic has its own SSH server. You have to enable a SSH server in Mystic's setup.

Thanks Tony :)

Yes I enabled the SSH server, and it didn't appear to start. I did a quick restart of mis, checked again, and still nothing - but I think I was just impatient since, when I came back a few minutes later to scan the port saw that it was open, and logged in. Yay! :)

It seemed a little funky, as far as how it went through the login process when I tried it (once), but I'll check on it later, I'm sure I've just got to get used to it.

So for now I've got port 23 open for telnet and port 22 open (running Mystic's SSHD). I'm glad that I didn't have to install and run another OpenSSHD and figure out how to pass that through or if it could be done. Like I inferred, although perhaps not clearly enough, I already have SSHD listening on another, non-standard port for regular user access to the host, i.e., there are two SSH daemons listening now, Mystic on 22 and OpenSSH on another :)

Now, are you starting Mystic as root or an ordinary user? By default, ordinary users can't bind ports below 1024 on Linux. You either have to start
Mystic as root (it will run as the user that owns its directory once it has bound its ports), or give the mis binary permission to bind privileged
ports.

I start mis as root. Actually, since that part of testing is over now, I start it as the non-priv'd user who owns the dir with a sudo - one of the use cases where I believe in using sudo ;) For that, I don't add the user to the sudo group, because any breakouts could afford a script kiddie to wreak havoc with impunity, so the user running "mis" (Not mystic) is only allowed to run mis.

I try to avoid letting non-privileged users run daemon's on privileged lower ports, but with some software, do sometimes. This isn't one of those times ;)

Now, that begs another question. If someone breaks out of Mystic... that's always a concern, so what SSH implementation does Mystic use? I ask because I want to know how confident I should be that port 22 (Mystic's SSHD) is as secure as OpenSSH is on the host.

Thanks again! I'm going to work on getting echomail setup tonight later, I think I'll start with Fsxnet. Then Fidonet, Then you won't all have to read messages from me via Rob's server ;)

If I'm once again a SysOP, then I should be sending Echomail from my own system lolz.

.

On 09-08-19 22:02, Bradley D. Thornton wrote to Tony Langdon <=-

Yes I enabled the SSH server, and it didn't appear to start. I did a quick restart of mis, checked again, and still nothing - but I think I was just impatient since, when I came back a few minutes later to scan the port saw that it was open, and logged in. Yay! :)

Cool, sounds good. :)

It seemed a little funky, as far as how it went through the login
process when I tried it (once), but I'll check on it later, I'm sure
I've just got to get used to it.

SSH works fine. I've used it. :)

So for now I've got port 23 open for telnet and port 22 open (running Mystic's SSHD). I'm glad that I didn't have to install and run another OpenSSHD and figure out how to pass that through or if it could be
done. Like I inferred, although perhaps not clearly enough, I already have SSHD listening on another, non-standard port for regular user
access to the host, i.e., there are two SSH daemons listening now,
Mystic on 22 and OpenSSH on another :)

Yep I run 3 SSH daemons here:

OpenSSH on port 22 all IPs
Mystic on port 222 on selected IPs
Synchronet on port 222 on a different set of selected IPs.

:)

I start mis as root. Actually, since that part of testing is over now,
I start it as the non-priv'd user who owns the dir with a sudo - one of the use cases where I believe in using sudo ;) For that, I don't add
the user to the sudo group, because any breakouts could afford a script kiddie to wreak havoc with impunity, so the user running "mis" (Not mystic) is only allowed to run mis.

Using sudo is still "running as root".

I try to avoid letting non-privileged users run daemon's on privileged lower ports, but with some software, do sometimes. This isn't one of those times ;)

Umm, why? Back in the old days, there were lots of users (as in actual people with individual UNIX accounts) and only one sysadmin. In that environment, it makes sense not to allow non root users to bind privileged ports - you wouldn't want a user taking over the SMTP port, for example. Today it's more common to have Linux boxes with only one actual (human) user - the sysadmin, and any "users" are simply accounts to isolate processes from one another. Allowing these users to run a specific application that can bind privileged ports means they don't have to start the application as root, with a (very) small increased potential for a root compromise, if a flaw can be triggered before it drops privileges.

Now, that begs another question. If someone breaks out of Mystic... that's always a concern, so what SSH implementation does Mystic use? I ask because I want to know how confident I should be that port 22 (Mystic's SSHD) is as secure as OpenSSH is on the host.

I'm not sure tbh.

Thanks again! I'm going to work on getting echomail setup tonight
later, I think I'll start with Fsxnet. Then Fidonet, Then you won't all have to read messages from me via Rob's server ;)

If I'm once again a SysOP, then I should be sending Echomail from my
own system lolz.

Yes, it's nice to have your own system running echomail. :)



... Reality is for those who can't handle computers.
=== MultiMail/Win v0.51
--- SBBSecho 3.03-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

Yep I run 3 SSH daemons here:

OpenSSH on port 22 all IPs
Mystic on port 222 on selected IPs
Synchronet on port 222 on a different set of selected IPs.

For security reason you may want to change your ssh port to above 20,000.

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Mystic.dynu.net 2025 (1:275/201.1)

On 09-10-19 01:19, Phil Taylor wrote to Tony Langdon <=-

Yep I run 3 SSH daemons here:

OpenSSH on port 22 all IPs
Mystic on port 222 on selected IPs
Synchronet on port 222 on a different set of selected IPs.

For security reason you may want to change your ssh port to above
20,000.

Yeah to keep my logfiles empty :)


... "Hello, World!" 17 Errors, 31 Warnings....
=== MultiMail/Win v0.51
--- SBBSecho 3.03-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

Re: Re: Has anyone received one of these?
By: Bradley D. Thornton to Todd Yatzook on Thu Sep 05 2019 01:18 pm

On 09-08-19 22:02, Bradley D. Thornton wrote to Tony Langdon <=-

So for now I've got port 23 open for telnet and port 22 open (running Mystic's SSHD). I'm glad that I didn't have to install and run another
OpenSSHD and figure out how to pass that through or if it could be done. Like I inferred, although perhaps not clearly enough, I already have
SSHD listening on another, non-standard port for regular user
access to the host, i.e., there are two SSH daemons listening now, Mystic on 22 and OpenSSH on another :)

Yep I run 3 SSH daemons here:

OpenSSH on port 22 all IPs
Mystic on port 222 on selected IPs
Synchronet on port 222 on a different set of selected IPs.

:)

Hm... If I want to also run a Syncrhonet instance I could just bind it to a different IP, but Is it possible to share the filebase between the two internally? I suppose I could do it with a symlink. I had thought about doing it on another machine and then just making it available via an NFS mount on the private network. I'll need to ponder that later.

Thanks for bringing that up!

I start mis as root. Actually, since that part of testing is over now, I start it as the non-priv'd user who owns the dir with a sudo - one of
the use cases where I believe in using sudo ;) For that, I don't add the user to the sudo group, because any breakouts could afford a script
kiddie to wreak havoc with impunity, so the user running "mis" (Not mystic)
is only allowed to run mis.

Using sudo is still "running as root".

Well.... Okay ;) Yes it is, but I'll address that below.

I try to avoid letting non-privileged users run daemon's on privileged lower ports, but with some software, do sometimes. This isn't one of
those
times ;)

Umm, why? Back in the old days, there were lots of users (as in actual people with individual UNIX accounts) and only one sysadmin. In that
environment, it makes sense not to allow non root users to bind privileged ports - you wouldn't want a user taking over the SMTP port, for example.
Today it's more common to have Linux boxes with only one actual (human) user - the sysadmin, and any "users" are simply accounts to isolate processes
from one another. Allowing these users to run a specific application that can bind privileged ports means they don't have to start the application as
root, with a (very) small increased potential for a root compromise, if a flaw can be triggered before it drops privileges.

Actually, and I do understand what you're saying, but with respect to SMTP specifically, and I know I gave an example of Bind as well, there are [once] common use cases for allowing a user to do that.

For example, I have users that manage their own email users for their domains as well as the DNS for those particular zones the users have. Bind picks up the zonefiles for that user's domains from their say, ~/dns/sld.tld.db file. The user is free to add and delete whatever records they need to, and up the serial for their zonefile, but they still need a way to HUP named, ergo, visudo:

joeuser ALL=(ALL:ALL) NOPASSWD: /sbin/reload-dns.sh

where reload-dns.sh is chmod'd 644

#!/bin/sh
# reload-dns.sh
/etc/rc.d/rcnamed reload

Or some version of kill -HUP named, etc.

The same to hash the include of sendmail.cf in their ~ tree.

I know the thang nowadays is to sudo command for everything from the one person who is the admin on their own machine, but that's so freakin' redundant and unneccesary it just drives me nuts - even when I read it in Howtos. Yes, I get the idea, and this didn't come into common usage until Windows folks starting coming over the UNIX and Ubuntu really popularized it. In that Windows world, there isn't really an 'su -' per se', so what 'should' normally be a non-priv'd user is dropped into the Local Administrator or Domain Administrator group to administer machines on the network and have SSO convenience - that's just never been the way it was done in UNIX - su to root, and get back out after you do root stuff.

Effectively, 'sudo command' is the same, but all that typing just drives me nuts. I know when I want to do root stuff and I know when to ^d back out. I understand why it's been popularized in recent years not to do it that way but.... an explitive came to mind so my rant should stop there lol.

The first thing I had to get my head around when I started in the MCSE program when it was first launched was coming to terms with being a regular user and a god user at the same time - that's just freakin' wrong. Microsoft has never had an su equivalent, with the semi exception of being able to choose running certain things as Administrator - like powershell, etc. There I go again. Apologies.

Back to the security of it, if someone were to break out into the system, by allowing the user only a single root command, and effectively only commit a DOS, in this case.

In the rare cases where I would allow a non-priv'd user to start a job that could bind to a lower port, I would first make sure that user has no shell, maybe /bin/false or whatever, in /etc/passwd, so for them to start that service they would (root would, actually):

su jouser -s $SHELL -lc "
/path/to/command
/some/other/command
/bind/daemon/to_port:123
"

And this would be required:

#CapabilityBoundingSet=CAP_NET_BIND_SERVICE #AmbientCapabilities=CAP_NET_BIND_SERVICE

Now, that begs another question. If someone breaks out of Mystic... that's always a concern, so what SSH implementation does Mystic use? I ask
because I want to know how confident I should be that port 22 (Mystic's SSHD) is as secure as OpenSSH is on the host.

I'm not sure tbh.

Here's what I got from a quick port scan. Not much info, which is good actually.

PORT STATE SERVICE VERSION
22/tcp open ssh APC AOS cryptlib sshd (protocol 2.0)
23/tcp open telnet
| fingerprint-strings:
| GenericLines:
| [8;25;80t
| [1;25r
| [1;1H
| [1;1H
| [?1000h
| Mystic BBS v1.12 A43 for Linux Node 1
| Copyright (C) 1997-2019 By James Coyle
| Detecting terminal emulation:
| [6nASCII detected.
| Ascii (No Color)
| Ansi (Color)
| Graphics Mode ->
| NULL, tn3270:
| [8;25;80t
| [1;25r
| [1;1H
| [1;1H
| [?1000h
| Mystic BBS v1.12 A43 for Linux Node 1
| Copyright (C) 1997-2019 By James Coyle
|_ Detecting terminal emulation:


Thanks for your feedback Tony!

Re: Re: Mystic SSHD won't start? Is there an SSH server?
By: Tony Langdon to Bradley D. Thornton on Mon Sep 09 2019 05:14 pm

On 09-08-19 22:02, Bradley D. Thornton wrote to Tony Langdon <=-

Yes I enabled the SSH server, and it didn't appear to start. I did a quick restart of mis, checked again, and still nothing - but I think I was
just impatient since, when I came back a few minutes later to scan the port saw that it was open, and logged in. Yay! :)

Cool, sounds good. :)

Hey Tony?

I wanted to ask you, what editor or offline reader are you using that quotes with lines with the person's initials? I like that.

Thanks :)

On 09-10-19 20:46, Bradley D. Thornton wrote to Tony Langdon <=-

I wanted to ask you, what editor or offline reader are you using that quotes with lines with the person's initials? I like that.

Multimail. Bluewave also does it from memory. :)


... The universe is. It is mankind that attaches meaning to it.
=== MultiMail/Win v0.51
--- SBBSecho 3.03-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

On 2019 Sep 10 01:19:50, you wrote to Tony Langdon:

Yep I run 3 SSH daemons here:

OpenSSH on port 22 all IPs
Mystic on port 222 on selected IPs
Synchronet on port 222 on a different set of selected IPs.

For security reason you may want to change your ssh port to above 20,000.

that's not security... a simple portscan will reveal them in no time at all...

)\/(ark

Once men turned their thinking over to machines in the hope that this would set
them free. But that only permitted other men with machines to enslave them.
... We just wanna get our damned mail through... is that a crime?
---
* Origin: (1:3634/12.73)

Hello Phil,

Yep I run 3 SSH daemons here:

OpenSSH on port 22 all IPs
Mystic on port 222 on selected IPs
Synchronet on port 222 on a different set of selected IPs.

For security reason you may want to change your ssh port to above 20,000.

A simple port scan of Mystic.dynu.net reveals:

Port Type Status Service
21 TCP Filtered ftp
22 TCP Filtered ssh
23 TCP Filtered telnet
25 TCP Closed smtp
53 TCP Filtered domain
80 TCP Open http
110 TCP Filtered pop3
111 TCP Filtered rpcbind
135 TCP Filtered msrpc
139 TCP Filtered netbios-ssn
143 TCP Filtered imap
222 TCP Filtered rsh-spx
389 TCP Filtered ldap
443 TCP Filtered https
445 TCP Filtered microsoft-ds
587 TCP Filtered submission
1025 TCP Filtered NFS-or-IIS
1080 TCP Closed socks
1433 TCP Filtered ms-sql-s
3306 TCP Filtered mysql
3389 TCP Filtered ms-wbt-server
5900 TCP Filtered vnc
6001 TCP Filtered X11:1
6379 TCP Filtered redis
8080 TCP Filtered http-proxy

IOW, port status and availability can be determined quite easily
via FQDN or IP.

Jeff

--- BBBS/Li6 v4.10 Toy-4
* Origin: Fidonet: The Ouija Board - Anoka, MN - bbs.ouijabrd.net (1:282/1031)