FAQs

Yes. The list of supported RFCs and interoperability with SSL clients (e.g. OpenSSH) are described in the User’s Guide.

Based on the version of ThreadX RTOS, the users may need to update the OS abstraction layer. A porting guide is provided to assist with the port to any OS.

Yes. The code is processor agnostic.

Yes.

Yes.

Yes. All required cryptographic operations are provided through the Mocana NanoCrypto module.

Yes, via application registered callbacks.

Yes, via application registered callbacks.

Yes.

Yes (RFC 4335).

The memory footprint depends on the selected set of cipher algorithms. The range is typically between 200KB (optimized cipher suite) – 500KB (full cipher suite).

Yes.

Patches are provided based on issues reported by internal QA regression/continuous integration activities and end users through the ZenDesk ticketing system. New features based are included on the roadmap based on customer specific use case.

When negotiating connections, NanoSSH server can use the strongest cipher suite available, or the desired cipher settings can be specified. To enable the following cipher suites, you will be required to build with the corresponding compilation flag:

Please note that for the SSH client and server to connect securely and successfully, both the client and the server will need to agree on the same cipher suites to use before authenticating to each other and encrypting data to one another.

There are several ways to make communication calls from the CLI application code using NanoSSH server:

The most efficient solution would be to use the NanoSSH API functions. Depending on the operating system, the NanoSSH functions may use only half as many threads as a pipe or socket solution. However, in the case that the CLI application is legacy code that uses numerous send and receive calls or is generally difficult to modify, NanoSSH integration can be done in the following ways:

For the first option, you can replace the legacy code’s function calls with Mocana macros:

If you choose to use the second option, you can refer to example code in examples/ssh_pipe.c to see how pipes are created and managed. To integrate the Mocana pipe code, you’ll be required to modify the NanoSSH server code to disable authentication and to listen only on the loopback interface (127.0.0.1).

There are existing API’s to read/write from and to a file via MOCANA_readFile() and MOCANA_writeFile(), which are used to access the host key files. In terms of our SFTP example code, we have API’s that invoke calls to SSH_sftpReadBuffer() and SSH_sftpWriteBuffer in order to read and write from and to a specified buffer.

The synchronous and asynchronous modes perform message handling differently. In synchronous mode, the initial negotiation locks the thread until negotiation is complete. In asynchronous mode, the user is free to carry out other actions on the thread while negotiation is still processing. If any of the following conditions apply, asynchronous mode must be used instead:

Generally, asynchronous mode is more efficient than synchronous mode. Synchronous mode is recommended if a system is socket-based (using TCP/IP) and is also easier to integrate than asynchronous mode. However, asynchronous mode should be used for any other scenario (e.g. TCB, event-driven, callback-based, asynchronous stacks).

Using RSA and DSA keys are sufficient for a basic SSH connection, but if you are constrained with memory or time, ECC keys are generally smaller and faster. If you are not planning to use ECC in authentication, encryption, or signing, it is unnecessary to generate ECC keys. However, if you are planning to use ECC, you will need to enable the __ENABLE_MOCANA_ECC__ compilation flag.

The SSH (and SFTP) server example by default uses the ssh_example.c file. If you want to enable port forwarding support, then you will need to use ssh_example_pf.c. SSH synchronous mode also uses ssh_example.c as it is the default mode, however, if you would like to use asynchronous mode you should use the ssh_example_async.c file.