Proposal: switching from screen(1) to telnet(1) for SIMH console

[Warren Young]

The PiDP-8/I software (both my distribution and Oscar's) use screen(1) to allow attaching and detaching from the simulated PDP-8 terminal after having SSH'd into the Pi or when using the Pi's own console via a keyboard and monitor.

This is all fine as far as it goes, but both the SSH and HDMI alternatives for getting to that console have some associated burdens.

In another thread, someone called my attention to the fact that SIMH has a feature that lets you expose its emulated terminal interface over telnet:

    set console telnet=1968

That would make SIMH listen on TCP port 1968 for telnet connections, which when accepted attach your remote system to the PDP-8's TTY interface.

The upside of switching to this is that it seems more secure, ironically, than SSH'ing into the box, since all you can do over this telnet connection is use the emulated PDP-8. You can't use Ctrl-E to escape to the SIMH command prompt, and as far as I can tell, you can't escape into the OS via this mechanism. The pidp8i script could easily be rewritten to wrap a "telnet localhost 1968" command, and the instructions talking about "Ctrl-A, d" could be changed to "Ctrl-], q".

The downside pretty much follows from that: you can't say "Ctrl-E, q" to quit the simulator over this interface. But, you do now have reliable shutdown and reboot via the front panel switches, and if you're too lazy to reach over and flip them, you do still have SSH.

Is there anyone here who would be annoyed if my software distribution moved away from screen(1)? I'm not really seeing that it buys anything important in this instance, and moving to a telnet based interface would give a passwordless remote access method without having to compromise the SSH method's security.

[Tony]

Would you not lose the ability to use ctrl-E to mount devices manually while running a simulation?  I don't use USB sticks for this although it's a neat trick.

Tony

[Warren Young]

On Saturday, December 24, 2016 at 2:32:08 AM UTC-7, Tony wrote:

Would you not lose the ability to use ctrl-E to mount devices manually while running a simulation?

Yes, that and any other commands, as already noted.

I suppose I could have some kind of power-user build-time switch to revert it to use screen(1).

Any more objections? 

[Tony]

On Saturday, December 24, 2016 at 10:30:31 AM UTC-6, Warren Young wrote:

On Saturday, December 24, 2016 at 2:32:08 AM UTC-7, Tony wrote:

Would you not lose the ability to use ctrl-E to mount devices manually while running a simulation?

Yes, that and any other commands, as already noted.

I could live with using the toggle switches for reboot / power down as you mentioned.  I would not be wiling to give up attaching storage devices without a suitable work around that did not involve plugging & unplugging USB sticks.

 

I suppose I could have some kind of power-user build-time switch to revert it to use screen(1).

That would be okay.  But if you don't go that route, I'll just have to patch it myself.  No big deal. 

Any more objections?  

Not from me.

 

[Audin Malmin]

You also lose scroll back and the current screen state.

[Warren Young]

On Saturday, December 24, 2016 at 10:48:51 PM UTC-7, Audin Malmin wrote:

You also lose scroll back and the current screen state.

Yeah, I'll probably just forget the idea.

There's simplification, and there's oversimplification. 

[Tony]

I realize now that one reason this had not appealled to me is that I have shared SSL certificates between my main PC and my various Pi's. So I never actually have to login to my Pi's.

Having said that, if simh would support both telnet and ssh then enabling telnet might be handy.

[Remy van Elst]

You can still run simh in screen on the Pi with telnet for the console. To attach devices you would have to login via SSH and open up the screen. Scrollback in telnet however is unknown to me, does your local terminal handle that?

https://raymii.org

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/039ec8af-82b9-41f9-b936-81038a25c9fc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Tony]

On Sunday, December 25, 2016 at 12:52:54 AM UTC-6, Remy van Elst wrote:

You can still run simh in screen on the Pi with telnet for the console. To attach devices you would have to login via SSH and open up the screen. Scrollback in telnet however is unknown to me, does your local terminal handle that?

Now that sounds good if it works that way - two windows!  A "console" dedicated to the simulated PDP8 in its own window and a "console" for the simulator in another window.  

1965 never looked so good ! 

[Remy van Elst]

I'm not sure if you're sarcastic or serious, honestly. One convinience I see is that if you need to do something with the simulator, your OS/8 (or other OS over telnet) session is not interuppted, which looks neater. Plus the reasons Warren stated earlier.

One thing to look out for, I'm not sure if it's applicable, but see here: https://virtuallyfun.superglobalmegacorp.com/2014/12/07/simh-on-demand/

"Some advice on SIMH thought, you can execute a shell with the ! command (hitting Control-E will interrupt SIMH) so to prevent that alter the line in scp.c to make sure it’s a noop_cmd instead of spawn_cmd.  Not that anyone was doing anything sneaky as the nobody user, but to prevent it."

https://raymii.org

--

You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/e7365d10-5753-4e5d-a26c-fd1d4e6a95f4%40googlegroups.com.

[Tony]

On Sunday, December 25, 2016 at 1:16:48 AM UTC-6, Remy van Elst wrote:

I'm not sure if you're sarcastic or serious, honestly.

 

Sorry - I was very serious (and maybe even a little excited). Multiplexing between the PDP-8 output and simh commands via ctrl-E has always felt clumsy to me.  Separate windows seems obvious in hindsight.

Tony 

 

[Andrew Yeomans]

I was wondering if anyone had used the Pi Zero OTG mode to emulate multiple serial consoles (over USB).
That would seem a very neat way of handling multiple screens, one for SIMH, one for a PI console, and a few for PiDP8 serial consoles.

Andrew

[Oscar Vermeulen]

Andrew,

On 25 December 2016 at 11:00, Andrew Yeomans <andrew....@gmail.com> wrote:

I was wondering if anyone had used the Pi Zero OTG mode to emulate multiple serial consoles (over USB).

Never tried multiple - but I always use the Pi Zero with a USB Serial cable for the single terminal. I don't see why two or four USB serial cables would not work. They're just $3 or so at Aliexpress so it is definitely worth a try.

Kind regards,

Oscar.

[Warren Young]

On Saturday, December 24, 2016 at 11:47:39 PM UTC-7, Tony wrote:

if simh would support both telnet and ssh then enabling telnet might be handy.

 

I don't see how to do that. When you give the "SET CONSOLE TELNET=port" command, it stops using stdout for the console, so you can't also use screen(1).

If you come up with a way, I'll certainly be interested to hear it.

[Warren Young]

On Sunday, December 25, 2016 at 8:21:14 AM UTC-7, Warren Young wrote:

On Saturday, December 24, 2016 at 11:47:39 PM UTC-7, Tony wrote:

if simh would support both telnet and ssh then enabling telnet might be handy.

 

I don't see how to do that. When you give the "SET CONSOLE TELNET=port" command, it stops using stdout for the console, so you can't also use screen(1).

There is a way: SIMH also has a SET REMOTE TELNET command which exports its command console on a different TCP port. So, you could export the terminal interface (e.g. OS/8) on TCP port 1968  and the SIMH command console on TCP port 1969.

There are limitations and problems with this, but it's now close enough to sensible that I've filed a ticket for it, with the details and caveats I'm aware of. I don't expect to do this any time soon, so consider it an open challenge to any of you who want this feature. 

[Tony]

On Monday, December 26, 2016 at 3:47:28 PM UTC-6, Warren Young wrote:

There are limitations and problems with this, but it's now close enough to sensible that I've filed a ticket for it, with the details and caveats I'm aware of. I don't expect to do this any time soon, so consider it an open challenge to any of you who want this feature. 

So the unsecure nature of telnet would still be a drawback but do you suppose there are actually still botnets scanning for open telnet ports? Which should not be visible outside our local LAN hopefully anyway.

Of your listed issues,  It seems like I could run screen() from a console window - spit it and open separate telnet sessions?   Then I can come and go from the screen session,  with the telnet sessions underneath still running?

Having a simultaneous simh window and PDP8 window open during "play time" seems like such a great concept.

Tony

 

[Warren Young]

On Monday, December 26, 2016 at 3:06:56 PM UTC-7, Tony wrote:

the unsecure nature of telnet would still be a drawback

I don't see how.

Simply telnetting into your Pi is insecure because it exposes your user name, password, commands, command output, etc. to anyone who can snoop your LAN traffic. (Which, by the way, is not entirely prevented by switched Ethernet.) That in turn lets a bad actor use the Pi for island hopping, free compute power, etc.

But, telnetting to either the SIMH command port or the SIMH terminal console port exposes...what, exactly? No user names, no passwords, no important commands. It does mean that a bad actor on your LAN could roach your OS/8 install, but they can't install a spam worm on it or similar.

 

Also, the SIMH REMOTE TELNET command seems well-thought-out, in that it doesn't allow ! commands.

do you suppose there are actually still botnets scanning for open telnet ports?

Why not? There are still infected Windows boxes sitting in closets and such infected with Code Red and Nimda still hopelessly scanning for other machines to infect, despite the holes being closed for over a decade.

 

It seems like I could run screen() from a console window - spit it and open separate telnet sessions?

I know next to nothing about GNU screen, so you tell me. :)

Having a simultaneous simh window and PDP8 window open during "play time" seems like such a great concept.

Yes, and it's easier for newbies, too.

The trick is, how difficult is it, and what do we give up to get it? 

[Warren Young]

On Monday, December 26, 2016 at 4:21:58 PM UTC-7, Warren Young wrote:

telnetting to either the SIMH command port or the SIMH terminal console port exposes...what, exactly?

I just thought of something minor: you could make SIMH attach random files on the Linux box to the simulated PDP-8 as paper tapes, and read the data out.

Fortunately, the PiDP-8/I software I distribute no longer requires root privileges.

On the other hand, the default Pi user typically has a fair bit of power, above and beyond just running SIMH. One wonders if we should create a separate pidp8i user and group that only has permission to do SIMH type things before we take this step.

[Warren Young]

On Monday, December 26, 2016 at 4:24:54 PM UTC-7, Warren Young wrote:

On Monday, December 26, 2016 at 4:21:58 PM UTC-7, Warren Young wrote:

telnetting to either the SIMH command port or the SIMH terminal console port exposes...what, exactly?

I just thought of something minor

...and another: if you're working with the PiDP-8/I software on your desktop computer or laptop, simply building and running it with the default configuration would expose your development box innards via telnet to anyone clever enough to smuggle things out through SIMH, such as via paper tape attachments.

Now I wonder about it being the default at all, but instead set as an option on the binary OS media.

Security Is Hard.

[Tony]

On Monday, December 26, 2016 at 5:27:20 PM UTC-6, Warren Young wrote:

Security Is Hard.

It might not be that bad.  

In the scenario I outlined earlier, you use ssh (only) to connect remotely to your Pi.  Then you run screen from the command prompt, split the window, and run a separate telnet session in each  - one to 127.0.0.1:1968 and the other to 127.0.0.1:1969.

If you can configure the Pi to only accept local connections on those ports ( iptables or somehow?) then you are as secure as you ssh login.

[Warren Young]

On Monday, December 26, 2016 at 4:32:55 PM UTC-7, Tony wrote:

On Monday, December 26, 2016 at 5:27:20 PM UTC-6, Warren Young wrote:

Security Is Hard.

It might not be that bad.  

It's bad enough that I'm back to not liking this idea. :)

In the scenario I outlined earlier, you use ssh (only) to connect remotely to your Pi.

The original motivation for doing this is to avoid the need for clue-deficient Windows users — I do not mean that to be understood as redundant — to figure out SSH.

 

Then you run screen from the command prompt, split the window, and run a separate telnet session in each  - one to 127.0.0.1:1968 and the other to 127.0.0.1:1969.

As far as I can tell, the current features in SIMH do not allow specifying localhost binds.

Doubtless one could add such a feature, but again we're ratcheting up the complexity.

 

If you can configure the Pi to only accept local connections on those ports ( iptables or somehow?)

You don't want to rely on the firewall for this. As it stands, this software will build and run just fine on non-Linux boxes, and we don't want to work out the local firewall commands for every possible host OS we'd want to support.

Modifying SIMH to bind to localhost only is a much simpler method. 

[Joshua Kaplan]

Warren,

I'd suggest that if this is going to be a security mess if you
are opening up the system to the open world via telnet (and lets
not get into mounting things) - then you might want to leave it
alone.

I do like the idea of simh system consoles that are only locally
accessible (only from the actual pidp system) (specifically the
simh console and the base system console - and make those only
accessiable via a ssh) - BUT - if you do that for all consoles -
it would make some things more difficult. For example - when my
dad and I got the pidp8 system running over ethernet - we could
start up TSS/8 and both telnet directly to the system to login to the
extra serial consoles from remote systems (like how it would be
really done). I think that you might need to work out (and pass
back) - how to make certain network accessible consoles be only
localhost accessible and others be accessible over the net.

BUT - if you do want to do that - can I make a few suggestions:

1) Make it so that the ports are configurable - perhaps at build
time - since you are already doing a number of other replacements

2) I actually like the screen idea with 2 panes - one for simh
console - one for the physical system (pdp8) console - running via ssh

3) I'd also recommend that for your configuration tool - make a
pidp vs. non-pidp option - that way some things that are fairly
pidp specific aren't triggered (for example adding the user to
the appropriate group for the gpio)

4) In relation to number 3 - for the pidp - if you are converting
the init scripts to systemd - in order to do a basic chroot - you
might consider doing a form of chroot - systemd supports the
WorkingDir, RootDirectory to chroot it (of course that means that
all of your stuff has to be in that jail. A few other ideas are
ProtectSystem. As an alternative - perhaps looking at
ReadWritePaths, ReadOnlyPaths, and InaccessiblePaths. (Many of
these are documented in
https://www.freedesktop.org/software/systemd/man/systemd.exec.html
)


I am a linux person - but for work I have to work in a Windows
world - and work with people who only know windows. In my work I
have to show them how to use putty - which has NEVER been
hard (Run this - put this hostname here - and make sure this box
is selected - then hit the Open button). Doing that is 100x
easier than explaining how to do some things on the
command-line (which would be how a basic telnet would work).

Maybe a bit of documentation on using putty - or even better - a
basic cheat-sheet for things.

-Josh