We didn't make this a 100% drop in replacement for the other sshd. I'd love it to be, but they've had many more years to work on it than I have. That said, we didn't implement their entire configuration file yet either. While some variables were added to the configuration structure, wolfSSHd doesn't know how to parse them yet. There's also some parsing set up for some options, where they are just skipped. ListenAddress is one of those.

It is on my wish-list to add a wolfssh-keygen tool, but I haven't had the time to do it yet. The file keygen.c has some wrapper functions for the wolfCrypt RSA and ECDSA key generation functions. wolfSSH is able to load OpenSSH formatted unencrypted private keys. (We don't have Blowfish or bcrypt support in wolfCrypt yet. We've been focused on algorithms that can get FIPS validations.)

The wolfSSHd application is intended to be used as a server. The examples directory applications are the demonstrations for how one could use the library.

We typically add things on paid customer requests.

--John

Which version of wolfSSH are you using? I'm going to assume v1.4.12, since that was released before your original post. I am seeing the WS_OVERFLOW_E error with that version. I'm going to check to see if we explicitly fixed it, or what.

Sounds good!

We did when we added Zephyr support. We set it to the correct value. That particular case you indicated should be ctx->heap. If you aren't using a custom heap with your own memory allocator functions, you could use NULL for the heap.

It's happening in builds that aren't using the default memory allocators. For Linux/macOS/Windows, the WMALLOC() macro is ignoring the heap parameter. That's why I missed it.

No.

This issue is fixed and will be available in the v1.4.15 release in the next few days.

--John

Whoops. I understand now. I haven't looked at the FAT filesystem that comes with FreeRTOS, but I'm looking now. It follows the pattern that Win32 uses for examining directories, not POSIX. You use ff_findfirst() and ff_findnext() to query the file system for entries in the directory table.

The directory functions are used to get directory listings. The functions that open files for reading or writing take the path string they are given and use that. I think SCP should work with NO_WOLFSSH_DIR. It isn't going affect SSH shells.

testwolverinebagel:

We don't have an example that uses epoll. Our example client is using select() in the function NonBlockSSH_connect(). Can you share with me the code you are using for your connect? You can send it to support@wolfssl.com if you don't want to post it here.

--John

I don't recommend following the example server source. The echoserver is the example that works.

The WOLFSSH object isn't reusable right now. I preferred to create a new WOLFSSH for each incoming connection and free it when done. Servers tend to allow multiple clients to connect simultaneously, so the echoserver can create a new object per incoming connection.

The echoserver is calling wolfSSH_shutdown. wolfSSH_stream_exit would be closing one data channel in a session, not the whole connection.

--John

I do not recommend doing that at all. ECC signatures use a random value and they are different every time you sign some data. It verifies after the fact. I'm assuming you are trying to do a known answer test for the ECC sign function. NIST recommends doing a sign-and-verify test.

If you really want to replace the random number generator that always returns 1, you can set the macro CUSTOM_RAND_GENERATE_BLOCK to a function that you provide that memset's the buffer with 0xFF. You can do that, but I don't recommend that at all. You don't want the code to get out and have the random number generator returning the same value constantly.

The API to look out for is wolfSSL_CTX_set_cipher_list(). You call this once on the WOLFSSL_CTX, and all WOLFSSL sessions made with that CTX will have the preset list. If you only want to use ECDSA-AES256-GCM-SHA384, call it

ret = wolfSSL_CTX_set_cipher_list(ctx, "ECDHE-ECDSA-AES256-GCM-SHA384");

Only that suite will be requested by the client to the server.

I think the following defines in user_settings.h will get you TLSv1.3 with support for the above cipher suite.

#define WOLFSSL_TLS13
#define HAVE_TLS_EXTENSIONS
#define HAVE_SUPPORTED_CURVES
#define HAVE_HKDF
/* #define WC_RSA_PSS - not needed if only using ECC */
/* #define HAVE_FFDHE_2048 - not needed if only using ECC */

If TLSv1.3 is enabled, wolfSSLv23_client_method() will try to negotiate for TLSv1.3 and allow downgrades. (It looks like the manual needs an update.)

Which version of wolfSSL are you using and how are you configuring it?

Your PCAP file isn't showing much with the passive connection. The client sends a hello message and the server is reseting both connections two minutes later-ish. Can you attach a successful handshake with your other client?

You don't use wolfSSL_set_using_nonblock() with TLS sessions. It is only used in DTLS sessions. I originally named the function without the "dtls" part, and it confused some people. "Well, I set non-block and it didn't work." wolfSSL is agnostic to the behavior of the underlying TCP/IP stack, or lack of one, and how it behaves. The only exception is DTLS with non-blocking sockets. In POSIX TCP/IP stacks, the stack returns the same error code for "this socket will block" as the condition "the timeout on this socket expired".

Really, the DTLS usage in our example server and client should have a custom application level structure containing the peer's address, the socket fd, and the non-blocking setting, and that should get passed into the I/O callback function.