Skip to content

ssh serial console #21

Description

@wolfgangr

If we are short on RAM, and want to secure our istallation, we have to drop the webserver.
This is what tasmota says:
https://github.com/arendst/Sonoff-Tasmota/blob/development/sonoff/my_user_config.h

#if defined(USE_MQTT_TLS) && defined(USE_WEBSERVER)
  #error "Select either USE_MQTT_TLS or USE_WEBSERVER as there is just not enough memory to play with"
#endif

This ruins our web console.
So if we want to talk to some stringified interface, as some serial external unit or the forth I'am going to implement, we need some other pathway for console access.

  • Telnet:
    there are telnet servers for forth lingering around. Just open another port, and need no support from the host (beyond network sockets)
    But spoils security again.
  • mqtt
    We might use serial send or implement an own command slot.
    This will work, I think, but is not easy to handle at the client side.

There is a ssh operatability available for the mecrisp forth companion folie:
https://github.com/jeelabs/embello/blob/master/tools/folie/README.md#connecting-via-ssh
folie -x ssh <hostname> <path/to/mecrisp>
Maybe if we replace -x ssh by -x path\to\some\mosquito_wrapper.pl, we can arrive at a quite workable version.
However, we still need a working mqtt installation an a specialised client setup.

Just having a standard ssh demon would enable us to connect from any client machine (I consider ssh client as a standard), independent of mqtt setup.

Does the ssh protocol build on the tls which is used for mqtt encryption, or can it at least share its libraries?
Preferrably I would try to find a forth telnet implementation and hook some encryption libraries into it.
hm....

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions