Interest/Intent to port OpenSSH?
chrisj at rtems.org
Sun Mar 3 22:21:52 UTC 2019
On 4/3/19 8:28 am, Joel Sherrill wrote:
> On Sun, Mar 3, 2019, 3:18 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
> On 2/3/19 3:37 am, Christian Mauderer wrote:
> > Am 01.03.19 um 17:01 schrieb Gedare Bloom:
> >> On Fri, Mar 1, 2019 at 10:52 AM Joel Sherrill <joel at rtems.org
> <mailto:joel at rtems.org>
> >> <mailto:joel at rtems.org <mailto:joel at rtems.org>>> wrote:
> >> On Fri, Mar 1, 2019 at 2:57 AM Sebastian Huber
> >> <sebastian.huber at embedded-brains.de
> <mailto:sebastian.huber at embedded-brains.de>
> >> <mailto:sebastian.huber at embedded-brains.de
> <mailto:sebastian.huber at embedded-brains.de>>> wrote:
> >> Hello Gedare,
> >> we evaluated porting of OpenSSH some time ago. Something to
> >> consider is
> >> also Dropbear SSH:
> >> https://matt.ucc.asn.au/dropbear/dropbear.html
> >> We didn't spend much time with both programs, but it seems to be
> >> complex. We ended up with web sockets via HTTPS.
> >> This would be good to support via a port and the RSB.
> >> Thanks. I have some plan to add an SSH server, but I haven't yet
> >> untangled the complexity of it. Dropbear looks promising--it works under
> >> Cygwin so hopefully the newlib support is sufficient. I think this could
> >> be a GSoC Project, with some proper scoping and some "Extras" in case
> >> the porting turns out to be a bit trivial.
> >> I thought we had a port of an SSL library but I don't see it in the RSB.
> >> We have OpenSSL in the libbsd. Is that what you mean?
> > One possible SSL library is OpenSSL from libbsd. Most likely that's the
> > simplest choice. For some other project we have also build libressl
> > without bigger problems before OpenSSL was included in libbsd. But that
> > was without RSB.
> > Another interesting SSL library would be mbed TLS. It promises to be a
> > lot smaller than OpenSSL. But I didn't try that one yet.
> There is also https://tinyssh.org/. I had the crypto tests working and I was
> able to make secure connections. The missing piece was to look at the telnet
> code we have and to see what could be made common and shared and then to wire
> that to the ssh connection. The nice thing about tinyssh is it's size. it is
> self contained, and it works with the legacy networking and libbsd stacks.
> Would it make sense to have a broad SSH gsoc project that ported multiple and
> compared them? On code size, performance, features, etc. If you can run libbsd,
> you have lots of RAM and code space. But in lighter targets, less might be
If it was this easy to build and add ssh servers I suggest we would have SSH
supported now. :)
I need to be able to run on the legacy and libsd and I have existing telnet apps
and wanted the same level of integration, ie nothing more complicated.
I only had a couple of tests running in libbsd and this was before the header
movement to allow code to be built in rtems and run in libbsd so I suspect it
would be even easier to build either as a 3rd party package or as libssh in the
rtems.git. There is a reasonable amount of work to make tinyssh run and work and
it requires a range of skills such as embedded software, key management on
embedded software, C code, debugging an existing package, networking, crypto,
SSH and SSL standards, shell commands, and re-factoring the telnet pty support
to make it reusable. I suggest there is plenty to do just selecting something
and getting anything to run even with the start I have made with tinyssh (if
that is used). And if the project works out better than we thought we could see
what it would take to add sftp, tinyssh uses openssh's sftp so we would need
code written or added to do this.
More information about the devel