wolfssl / wolfssh Goto Github PK

wolfSSH is a small, fast, portable SSH implementation, including support for SCP and SFTP.

Shell 2.33% C 81.57% Makefile 0.26% M4 7.68% Perl 0.18% CMake 6.66% Batchfile 1.12% FreeMarker 0.20%

ssh ssh-server ssh-client sftp scp security cryptography iot-security iot sshv2 ssh-library embedded portable scp-example sftp-example ssh-client-library ssh-server-library c wolfssl scp-support

wolfssh's People

Contributors

Stargazers

Watchers

wolfssh's Issues

WS_SFTP_FILEATRB->sz is undocumented?

Checking the size of a remote file with wolfSSH_SFTP_STAT gets me back the result in a WS_SFTP_FILEATRB struct.

It has a struct field named 'word32 sz[2]` that I presume is the size of the file. Given that the file size is 64 bits in total (I hope), which array index is the high and the low 32 bits here? Can I suggest adding this in a documentation or as a clear comment in the header file next to the struct declaration ?

wolfssh/wolfssh/wolfsftp.h

Line 128 in f8c7076

word32 sz[2];

wolfSSH client on STM32F103C8T6

Run only the SSH client on the STM32F103C8T6 so that it can connect to my linux box.

wolfssh/wolfsftp.h is not C90 compliant

I've started working on using wolfSSH as a backend for curl, and in curl we are strictly on C89/C90 and usually use compiler options that scream loudly when we're not. When doing this, we get this warning below in a wolfssh header.

(wolfssh from git as of just minutes ago)

I realize you might not care about C90 compliance, but then again you may.

.../include/wolfssh/wolfsftp.h:103:31: warning: ISO C restricts enumerator values to range of ‘int’ [-Wpedantic]
     WOLFSSH_FILEATRB_EXT    = 0x80000000
                               ^~~~~~~~~~

CMake Support

Hello! I was wondering why WolfSSH does not have support for CMake (a CMakeLists.txt) when WolfSSL does.
I am trying to build WolfSSH and WolfSSL as libraries for an embedded project and I am using CMake, but can only compile SSL because it is setup for CMake and SSH is not.
I'm just wondering the direction here, was there ever supposed to be CMake support for WolfSSH.
Thank you!

use of undeclared identifier 'udp'

Hey. I tried to build the lib via the steps from the readme. It failed on

/Applications/Xcode.app/Contents/Developer/usr/bin/make -j9  check-am
  CC       examples/echoserver/echoserver.o
  CC       examples/echoserver/tests_api_test-echoserver.o
  CC       examples/echoserver/tests_testsuite_test-echoserver.o
  CCLD     src/libwolfssh.la
In file included from examples/echoserver/echoserver.c:40:
./wolfssh/test.h:444:33: error: use of undeclared identifier 'udp'
            hints.ai_socktype = udp ? SOCK_DGRAM : SOCK_STREAM;
                                ^
In file included from examples/echoserver/echoserver.c:40:
./wolfssh/test.h:444:33: error: use of undeclared identifier 'udp'
            hints.ai_socktype = udp ? SOCK_DGRAM : SOCK_STREAM;
                                ^
./wolfssh/test.h:445:33: error: use of undeclared identifier 'udp'
            hints.ai_protocol = udp ? IPPROTO_UDP : IPPROTO_TCP;
                                ^
./wolfssh/test.h:445:33: error: use of undeclared identifier 'udp'
            hints.ai_protocol = udp ? IPPROTO_UDP : IPPROTO_TCP;
                                ^
In file included from examples/echoserver/echoserver.c:40:
./wolfssh/test.h:444:33: error: use of undeclared identifier 'udp'
            hints.ai_socktype = udp ? SOCK_DGRAM : SOCK_STREAM;
                                ^
./wolfssh/test.h:445:33: error: use of undeclared identifier 'udp'
            hints.ai_protocol = udp ? IPPROTO_UDP : IPPROTO_TCP;
                                ^
2 errors generated.
2 errors generated.
2 errors generated.
make[1]: *** [examples/echoserver/tests_api_test-echoserver.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [examples/echoserver/tests_testsuite_test-echoserver.o] Error 1
make[1]: *** [examples/echoserver/echoserver.o] Error 1
Undefined symbols for architecture x86_64:
  "_mp_clear", referenced from:
      _DoPacket in libwolfssh_la-internal.o
  "_mp_init", referenced from:
      _DoPacket in libwolfssh_la-internal.o
  "_mp_read_unsigned_bin", referenced from:
      _DoPacket in libwolfssh_la-internal.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [src/libwolfssh.la] Error 1
make: *** [check] Error 2

My compiler is

$gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 13.0.0 (clang-1300.0.29.3)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
```

Does it ring a bell? Could someone help me make it compile please? 🙏

wolfSSH reverse port forwarding

Hi WolfSSH Team,
I am a newbie here, I see WolfSSH server, client and Client port forwarding examples provided as separate features/examples. In the port forwarding example there is expectation of openSSH server in port forwarding mode to be started in background.
Comments: Learning and adopting WolfSSH purpose will be diverted, if expecting different sources (OpenSSH) in my view.

Requirement: Is there an example or approach explained which I can refer for "SSH Server/echoServer example build with reverse/remote port forwarding feature" ?

Best regards,
Pavan

Add check for options.h

It appears that Ubuntu 18.04's build of wolfssl is missing options.h and this is only observable at compile time. It could maybe be detected during configure.

`wolfSSH_stream_read` return value ignored in src/wolfsftp.c

Example - This looks like a bug, since less data can be returned (or none at all in non-blocking mode), and then whatever was present in the buffer is interpreted as a number. This happens in multiple places.

Other functions (such as SFTP_GetHeader treat it as an error if less data is returned, which seems wrong since wolfSSH_stream_read doesn't guarantee to read exactly bufSz bytes.

I can open a pull request to fix this if this is indeed a bug :)

The wolfSSH_SFTP_SendReadPacket documentation is out of sync

It is documented here: https://www.wolfssl.com/docs/wolfssh-manual/#h.ew6stinnse5x

But the header file says the forth argument is a const word32* ofst. It would be neat if the documentation would explain this.

Uninitialized Variables in internal.c port.h log.h

I'm in the process of porting wolfssh to the Espressif ESP-IDF for inclusion in ide directory, similar to that for the wolfssl IDE. And yes, note the wolfssl IDE directory is uppercase, whereas the wolfssh ide directory is lower case.

The Espressif idf.py build treats all warnings as errors. That's probably a good idea to help keep code clean and reliable.

As an interim workaround, I added this to my copy of internal.c in the esp-idf:

#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"

This issue is just a reminder that these warnings exist and should eventually be cleaned up.

For reference, here's the result of idf.py build | grep -i error for a sample project showing the uninitialized variables:

/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:1001:19: error: 'hashId' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:1002:45: error: 'sK' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:997:45: error: 'cK' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:8974:13: error: 'channelTypeSz' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/wolfssh/port.h:380:31: error: 'channelType' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:2412:22: error: 'side' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:3129:23: error: 'e' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:8703:13: error: 'serviceNameSz' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/wolfssh/port.h:380:31: error: 'serviceName' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:8708:13: error: 'authNameSz' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/wolfssh/port.h:380:31: error: 'authName' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:3942:31: error: 'pw' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:4467:27: error: 'digestSz' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:4467:27: error: 'pk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:4860:15: error: 'newChannel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:9133:9: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:9182:9: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:9231:9: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:9294:28: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:9341:24: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/wolfssh/log.h:76:27: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
/home/gojimmypi/esp/esp-idf/components/wolfssh/src/internal.c:9873:9: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Question about CPU footprint

Hi, posting this question as an issue here, as it might be a good reference for others.

We're using classic openssh server in our infrastructure. However, we're having issues with high CPU demands when even low number of concurrent users are connected (5-10). That's because sshd is single - threaded and encryption takes a lot of CPU.

The only way for scaling this is (we think) scaling horizontally by adding more CPUs and using CPU pinning. But this is really cumbersome as we're in k8s in some public cloud.

So, we're looking for another sshd implementation that might be better performing or maybe could be configured in a more performant way. And here we are analyzing wolfssh.

We found this article about memory footprint of wolfssl - and that looks very promising! https://www.wolfssl.com/wolfssh-sftp-performance/ However not word about CPU utilization there. According to this, https://www.wolfssl.com/docs/tls13/ TLS 1.3 will be probably more performant and less CPU intensive.

Could you please elaborate a little about how WolfSSH/WolfSSL compares to openssh in terms of cpu utilization? And how does scalability look like? As far as I understand from documentation, WolfSSL is multi-threaded (https://www.wolfssl.com/docs/wolfssl-manual/ch2/), with optional SINGLE_THREADED switch. However, not sure if this multithreading helps a lot from a performance perspective, as there is only one mutex (used for the session cache)?

Thank you

Compiling wolfssh on RaspberryPi 3 Model B

Greetings,
The attached screen shot shows the error I received upon compiling wolfssh on raspberry pi 3. I have installed wolfssl with no problems. Your advices would be highly appreciated.
Kernel version: 4.14.71-v7+ (raspbian)

Buffer mishandling based on receive callback value

static int Receive(WOLFSSH* ssh, byte* buf, word32 sz) in internal.c calls the user receive callback recvd = ssh->ctx->ioRecvCb(ssh, buf, sz, ssh->ioReadCtx);. If this user callback was to return a negative value that's not handled in the switch statement, then it will return that negative value default: return recvd;

static int GetInputData(WOLFSSH* ssh, word32 size) only checks for 2 negative values: -1 and WS_WANT_READ. Any other other negative values will be used in here as in:
ssh->inputBuffer.length += in; inSz -= in;
Which means we'll subtract from inputBuffer.length and increase inSz - which means the length could run negative which can lead to writing to areas outside of the buffer.

I confirmed this error by returning -100 in my receive callback function, which resulted in my program crashing (presumably due to writing to invalid memory location). Using bare metal PIC32 env.

Possible init bug in BuildUserAuthRequestEcc

rPad and sPad are set to 1 or 0 and then immediately set to 0 afterwards. Not sure which is the correct behaviour yet but I suspect this could be a bug.

Build wolfssh on Windows to use sftp client

Enviroment:

[ Window10]
[ VS 2015]
[ wolfssh v1.4.2]

I want to build wolfssh to use sftpclient. But I have problems when I build it
Error C1083 Can not open file: “wolfssl/wolfcrypt/settings.h”: No such file or directory wolfssh F:\library\wolfssh\wolfssh\ssh.h 30
The error occurred.
Do I have to build wolf ssl first?
By the way , my real purpose is to integrate sftp client to my own application, Do you have any suggestions?
Thanks.

32bit Linux built echoserver using ECC key segmentation fault

I have wolfSSH 1.4.3 and wolfSSL 4.3.0 in 32bit Linux machine and faced a seg fault issue with echoserver when using ECC key (-e argument). But this issue does not happen in 64bit Linux machine. I have also found that this issue is generated from wolfSSL's integer.c file. Can anyone help me with the fix?

SSH implementation for STM32F103C8T6 Arm STM32

I need to implement the ssh for the above mention device.
Any documentation or examples for that ?

N/A

Putty client fails to connect to wolfssh example/server

Hello,
I am running example server from v1.4.0-stable-34-gf07b134 and using a putty client to connect. The session was not successful and the client keeps expecting packets from server.

Below is the server log when it happens.

2019-07-31 22:23:41 [DEBUG] Leaving ShrinkBuffer()
2019-07-31 22:23:41 [DEBUG] PR5: txCount = 0, rxCount = 48
2019-07-31 22:23:41 [DEBUG] accept state: CLIENT_USERAUTH_REQUEST_DONE
2019-07-31 22:23:41 [DEBUG] BP: paddingSz = 10
2019-07-31 22:23:41 [DEBUG] CreateMac hmac-sha2-256
2019-07-31 22:23:41 [DEBUG] Encrypt aes128-cbc
2019-07-31 22:23:41 [DEBUG] Entering SendUserAuthBanner()
2019-07-31 22:23:41 [DEBUG] BP: paddingSz = 6
2019-07-31 22:23:41 [DEBUG] CreateMac hmac-sha2-256
2019-07-31 22:23:41 [DEBUG] Encrypt aes128-cbc
2019-07-31 22:23:41 [DEBUG] Entering wolfSSH_SendPacket()
2019-07-31 22:23:41 [DEBUG] Embed Send trying to send 144
2019-07-31 22:23:41 [DEBUG] Embed Send sent 144
2019-07-31 22:23:41 [DEBUG] SB: Shrinking output buffer
2019-07-31 22:23:41 [DEBUG] Entering ShrinkBuffer()
2019-07-31 22:23:41 [DEBUG] SB: usedSz = 0, forcedFree = 0
2019-07-31 22:23:41 [DEBUG] SB: releasing dynamic buffer
2019-07-31 22:23:41 [DEBUG] Leaving ShrinkBuffer()
2019-07-31 22:23:41 [DEBUG] Leaving SendUserAuthBanner()
2019-07-31 22:23:41 [DEBUG] accept state: ACCEPT_SERVER_USERAUTH_ACCEPT_SENT
2019-07-31 22:23:41 [DEBUG] PR1: size = 16

NOTE: It does not seem to happen with openssh ssh client. I am trying to understand why there is an inconsistency.

how do I enable publickey auth in my SFTP client code?

Hi again!

We've now merged initial support for wolfSSH in curl. It however struck me I haven't fixed publickey auth in the curl use of wolfssh (curl/curl#4820), and I find the docs rather lacking in this aspect.

What do I need to do to enable publickey auth? In my test case the server accepts publickey auth but my callback set with wolfSSH_SetUserAuth() gets called numerous times but only with authtype == WOLFSSH_USERAUTH_PASSWORD:

https://github.com/curl/curl/blob/68403cdbc6325bcbe4e4128c263db5d04a3c77c6/lib/vssh/wolfssh.c#L393-L395

(A secondary issue is that wolfssh git master doesn't build for me after I updated this afternoon (thinking maybe I needed an update), which is surprising since your CI builds all look green but I'll save that for now.)

Compilation errors when compiling wolfSSH for 32 bit

I cannot (cross)compile wolfSSH for 32 bit (x86).

I configure using setarch i386 ./configure --enable-static --enable-all and CFLAGS contains -m32.

src/port.c:125:49: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
            long offset = ((long)shortOffset[1] << 32) | shortOffset[0];
                                                ^  ~~
src/port.c:133:49: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
            long offset = ((long)shortOffset[1] << 32) | shortOffset[0];
                                                ^  ~~
2 errors generated.
src/wolfscp.c:1568:25: error: implicit conversion loses integer precision: 'word64' (aka 'unsigned long long') to '__time_t' (aka 'long') [-Werror,-Wshorten-64-to-32]
        tmp[0].tv_sec = aTime;Makefile:1231: recipe for target 'src/src_libwolfssh_la-port.lo' failed
make[1]: *** [src/src_libwolfssh_la-port.lo] Error 1

make[1]: *** Waiting for unfinished jobs....
                      ~ ^~~~~
src/wolfscp.c:1570:25: error: implicit conversion loses integer precision: 'word64' (aka 'unsigned long long') to '__time_t' (aka 'long') [-Werror,-Wshorten-64-to-32]
        tmp[1].tv_sec = mTime;
                      ~ ^~~~~
2 errors generated.
Makefile:1252: recipe for target 'src/src_libwolfssh_la-wolfscp.lo' failed
make[1]: *** [src/src_libwolfssh_la-wolfscp.lo] Error 1
src/wolfsftp.c:3810:42: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
    atr->sz[1] = (word32)((stats.st_size >> 32) & 0xFFFFFFFF);
                                         ^  ~~
src/wolfsftp.c:3852:42: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
    atr->sz[1] = (word32)((stats.st_size >> 32) & 0xFFFFFFFF);
                                         ^  ~~
src/wolfsftp.c:7489:39: error: implicit conversion loses integer precision: 'word64' (aka 'unsigned long long') to 'long' [-Werror,-Wshorten-64-to-32]
                    WFSEEK(state->fl, offset, 0);
                    ~~~~~~~~~~~~~~~~~~^~~~~~~~~~
./wolfssh/port.h:221:42: note: expanded from macro 'WFSEEK'
    #define WFSEEK(s,o,w)     fseek((s),(o),(w))
                              ~~~~~      ^
3 errors generated.

Build error

We have installed wolfSSH along with the README.md.
However, running the make command results in the following error.

make -j13 check-am
make[1]: Entering directory '/home/setup/wolfssh'
make -j13 tests/unit.test tests/api.test tests/testsuite.test scripts/external.test
make[2]: Entering directory '/home/setup/wolfssh'
make[2]: warning: -jN forced in submake: disabling jobserver mode.
make[2]: Nothing to be done for 'scripts/external.test'.
make[2]: 'tests/api.test' is up to date.
make[2]: 'tests/testsuite.test' is up to date.
make[2]: Leaving directory '/home/setup/wolfssh'
make -j13 check-TESTS
make[2]: Entering directory '/home/setup/wolfssh'
make[2]: warning: -jN forced in submake: disabling jobserver mode.
make[3]: Entering directory '/home/setup/wolfssh'
make[3]: warning: -jN forced in submake: disabling jobserver mode.
PASS: scripts/external.test
FAIL: tests/unit.test
FAIL: tests/api.test
FAIL: tests/testsuite.test

Testsuite summary for wolfssh 1.4.5

TOTAL: 4

PASS: 1

SKIP: 0

XFAIL: 0

FAIL: 3

XPASS: 0

ERROR: 0

============================================================================
See ./test-suite.log
Please report to [email protected]

Makefile:1625: recipe for target 'test-suite.log' failed
make[3]: * [test-suite.log] Error 1
make[3]: Leaving directory '/home/setup/wolfssh'
Makefile:1731: recipe for target 'check-TESTS' failed
make[2]: * [check-TESTS] Error 2
make[2]: Leaving directory '/home/setup/wolfssh'
Makefile:1930: recipe for target 'check-am' failed
make[1]: * [check-am] Error 2
make[1]: Leaving directory '/home/setup/wolfssh'
Makefile:1933: recipe for target 'check' failed
make: * [check] Error 2

Do you have any information about this issue?

Espressif ESP32 SSH Server

Heads up I have an ESP32 SSH Server in the works and a version for ESP8266 eventually to be include here.

This issue is just a placeholder in case anyone else is interested and/or also working on something similar.

WolfSSH 1.4.5 echoserver SFTP Error [-1001] "Channel data received"

This might well be a problem between keyboard and chair but here it goes:

Server A:
OpenSSH_8.4p1, OpenSSL 1.1.1i 8 Dec 2020 Linux 5.4.89-gentoo

Server B:
Linux 5.10.7-0-lts wolfSSL/wolfssl#1-Alpine
WolfSSL v4.6.0 ./configure --enable-aesctr --enable-aesni --enable-afalg --enable-ssh --enable-keygen --enable-opensslcoexist
WolfSSH v1.4.5 ./configure --enable-scp --enable-sftp --enable-keygen --enable-shell
grep -F "model name" /proc/cpuinfo model name : AMD GX-212ZC SOC with Radeon(TM) R1E Graphics
gcc version 10.2.1 Target: x86_64-alpine-linux-musl

on Server B:

# ./examples/echoserver/echoserver

on Server A:

# sftp -P 22222 [email protected]
wolfSSH Example Echo Server
[email protected]'s password:
Connected to 192.168.0.2.
sftp> put file.dat file.dat
Uploading file.dat to /tmp/./file.dat
file.dat                                                                               0%    0     0.0KB/s   --:-- ETA
client_loop: send disconnect: Broken pipe
Couldn't send packet: Connection reset by peer
Connection closed.

on Server B:

Error with SSH shutdown.
Error [-1001] "Channel data received" with handling connection.

The error depends on file size. I tested files with sizes of 1KB, 10KB, 100KB, 1MB and 10MB.
1KB and 10KB files succeed.
100KB file uploads 96% and stalls.
1MB file sometimes succeeds, sometimes fails with Error [-1001] "Channel data received" with handling connection.
10MB file fails with Error [-1001] "Channel data received" or "verify mac error" with handling connection

I also tested with a Windows machine running WinSCP 5.17.9 and got Error [-1001] "Channel data received" as well.

Please let me know if you need more details.

How can I build project in Windows?

Environment -

Windows 10

Visual Studio 2017

wolfssl-3.15.3

wolfssh-1.3.0

I have successfully build the wolfssl no issues. But while generating the build for wolfssh it fails

D:\Project\keil_workspace\wolfssl\wolfssh\wolfssh.vcxproj : error  : The project file could not be loaded. Could not find file 'D:\Project\keil_workspace\wolfssl\wolfssh\wolfssh.vcxproj'.  D:\Project\keil_workspace\wolfssl\wolfssh\wolfssh.vcxproj


D:\Project\keil_workspace\wolfssl\api-test\api-test.vcxproj : error  : The project file could not be loaded. Could not find a part of the path 'D:\Project\keil_workspace\wolfssl\api-test\api-test.vcxproj'.  D:\Project\keil_workspace\wolfssl\api-test\api-test.vcxproj


D:\Project\keil_workspace\wolfssl\echoserver\echoserver.vcxproj : error  : The project file could not be loaded. Could not find a part of the path 'D:\Project\keil_workspace\wolfssl\echoserver\echoserver.vcxproj'.  D:\Project\keil_workspace\wolfssl\echoserver\echoserver.vcxproj


D:\Project\keil_workspace\wolfssl\unit-test\unit-test.vcxproj : error  : The project file could not be loaded. Could not find a part of the path 'D:\Project\keil_workspace\wolfssl\unit-test\unit-test.vcxproj'.  D:\Project\keil_workspace\wolfssl\unit-test\unit-test.vcxproj


D:\Project\keil_workspace\wolfssl\client\client.vcxproj : error  : The project file could not be loaded. Could not find a part of the path 'D:\Project\keil_workspace\wolfssl\client\client.vcxproj'.  D:\Project\keil_workspace\wolfssl\client\client.vcxproj


D:\Project\keil_workspace\wolfssl\wolfsftp-client\wolfsftp-client.vcxproj : error  : The project file could not be loaded. Could not find a part of the path 'D:\Project\keil_workspace\wolfssl\wolfsftp-client\wolfsftp-client.vcxproj'.  D:\Project\keil_workspace\wolfssl\wolfsftp-client\wolfsftp-client.vcxproj

Followed the instructions of having projects a same location without version or anything. Opened the wofssh.sln from wolfssh folder and trying to build.

Certificate-based authentication

Hi,

wolfSSH is developed with the devices world (such as IoT or embedded devices) as described in the home page.
But, using a distributed echosystem makes very difficoult to managed standard authentication modes such as passwords or public/private key couples.

For example, in a fleet of thousends devices, every ssh user needs to store its public key in every device and it isn't possible in a industrial environment. Managing permissions and secure access easily become an hell.

In the SSH world there are two different specifications that tries to solve the problem:

RFC 6187 - X.509v3 Certificates for Secure Shell Authentication (March 2011)
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/ssh/PROTOCOL.certkeys?content-type=text/plain

The first one is a standard related to SSHv2 protocol, the second one is an extension proposed and fully supported by OpenSSH.

Is the support of these two specifications (or only one of them) planned for wolfssh?

Thanks,
Lorenzo

wolfSSH error: Couldn't connect SSH stream

I have change the code a bit to connect to ssh with my server settings. But I got stuck at the following error.

2018-08-27 16:46:09 [DEBUG] connect error: CLIENT_KEXDH_INIT_SENT, -17
wolfSSH error: Couldn't connect SSH stream

After searching and debugging I found that inside

src/internal.c

under `

DoKexDhGexGroup

`
method ret is set to

WS_UNIMPLEMENTED_E

i.e. error code -17.

can anybody tell me how to implement this feature ? or how to enable it?

Undefined symbols for architecture x86_64

Version 1.4.10

libtool: link: gcc -dynamiclib -o src/.libs/libwolfssh.8.dylib src/.libs/libwolfssh_la-ssh.o src/.libs/libwolfssh_la-internal.o src/.libs/libwolfssh_la-log.o src/.libs/libwolfssh_la-io.o src/.libs/libwolfssh_la-port.o -L/usr/local/lib -lwolfssl -lutil -lnetwork -O2 -pthread -install_name /usr/local/lib/libwolfssh.8.dylib -compatibility_version 13 -current_version 13.4 -Wl,-single_module
Undefined symbols for architecture x86_64:
"_mp_clear", referenced from:
_DoPacket in libwolfssh_la-internal.o
"_mp_init", referenced from:
_DoPacket in libwolfssh_la-internal.o
"_mp_read_unsigned_bin", referenced from:
_DoPacket in libwolfssh_la-internal.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [src/libwolfssh.la] Error 1
make: *** [all] Error 2

wolfssl-config --version
5.3.0

scp and sftp build errors with gcc 8.3.0

I build wolfssh straight from git, currently on commit 57a869e (dated April 22) on Debian Linux 64 bit (unstable) with gcc 8.3.0 and then I get this set of build errors:

$ CPPFLAGS=-I/home/daniel/build-wolfssl/include LDFLAGS=-L/home/daniel/build-wolfssl/lib ./configure --prefix=/home/daniel/build-wolfssh --enable-scp --enable-sftp --disable-examples
[cut]
$ make
make -j9  all-am
make[1]: Entering directory '/home/daniel/src/bagder-wolfssh'
  CC       src/libwolfssh_la-wolfsftp.lo
  CC       src/libwolfssh_la-wolfscp.lo
In file included from ./wolfssh/ssh.h:37,
                 from ./wolfssh/wolfscp.h:27,
                 from src/wolfscp.c:34:
src/wolfscp.c: In function ‘ParseBasePathHelper’:
./wolfssh/port.h:228:35: error: ‘strncpy’ output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
         #define WSTRNCPY(s1,s2,n) strncpy((s1),(s2),(n))
                                   ^~~~~~~~~~~~~~~~~~~~~~
src/wolfscp.c:1074:9: note: in expansion of macro ‘WSTRNCPY’
         WSTRNCPY(buf, ssh->scpBasePath, sz);
         ^~~~~~~~
./wolfssh/port.h:207:31: note: length computed here
     #define WSTRLEN(s1)       strlen((s1))
                               ^~~~~~~~~~~~
src/wolfscp.c:1067:24: note: in expansion of macro ‘WSTRLEN’
         int  sz = (int)WSTRLEN(ssh->scpBasePath);
                        ^~~~~~~
src/wolfscp.c: In function ‘wolfSSH_SetScpErrorMsg’:
./wolfssh/port.h:228:35: error: ‘strncpy’ output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
         #define WSTRNCPY(s1,s2,n) strncpy((s1),(s2),(n))
                                   ^~~~~~~~~~~~~~~~~~~~~~
src/wolfscp.c:710:9: note: in expansion of macro ‘WSTRNCPY’
         WSTRNCPY(value + 1, message, valueSz);
         ^~~~~~~~
./wolfssh/port.h:207:31: note: length computed here
     #define WSTRLEN(s1)       strlen((s1))
                               ^~~~~~~~~~~~
src/wolfscp.c:700:27: note: in expansion of macro ‘WSTRLEN’
         valueSz = (word32)WSTRLEN(message);
                           ^~~~~~~
In file included from ./wolfssh/ssh.h:34,
                 from ./wolfssh/wolfsftp.h:29,
                 from src/wolfsftp.c:26:
src/wolfsftp.c: In function ‘wolfSSH_SFTP_RecvRealPath’:
/home/daniel/build-wolfssl/include/wolfssl/wolfcrypt/types.h:372:35: error: ‘strncpy’ specified bound 256 equals destination size [-Werror=stringop-truncation]
         #define XSTRNCPY(s1,s2,n) strncpy((s1),(s2),(n))
                                   ^~~~~~~~~~~~~~~~~~~~~~
src/wolfsftp.c:922:13: note: in expansion of macro ‘XSTRNCPY’
             XSTRNCPY(wd, ssh->sftpDefaultPath, sizeof(wd));
             ^~~~~~~~
cc1: all warnings being treated as errors
make[1]: *** [Makefile:1263: src/libwolfssh_la-wolfscp.lo] Error 1
make[1]: *** Waiting for unfinished jobs....
cc1: all warnings being treated as errors
make[1]: *** [Makefile:1270: src/libwolfssh_la-wolfsftp.lo] Error 1
make[1]: Leaving directory '/home/daniel/src/bagder-wolfssh'
make: *** [Makefile:851: all] Error 2

I've looked at the code around these errors and I think the code is fine and already does the necessary boundary checks. I managed to hush up gcc with the following patch, but I'm not at all convinced that it is good enough so I leave it here just to show what I did and not because I think it necessarily is the right fix:

diff --git a/src/wolfscp.c b/src/wolfscp.c
index 186d966..238163f 100644
--- a/src/wolfscp.c
+++ b/src/wolfscp.c
@@ -705,11 +705,11 @@ WOLFSSH_API int wolfSSH_SetScpErrorMsg(WOLFSSH* ssh, const char* message)
             ret = WS_MEMORY_E;
     }
 
     if (ret == WS_SUCCESS) {
         /* leave room for cmd at beginning, add \n\0 at end */
-        WSTRNCPY(value + 1, message, valueSz);
+        WSTRNCPY(value + 1, message, valueSz - 1);
         *(value + valueSz + 1) = '\n';
         *(value + valueSz + 2) = '\0';
 
         if (ssh->scpConfirmMsg != NULL) {
             WFREE(ssh->scpConfirmMsg, ssh->ctx->heap, DYNTYPE_STRING);
@@ -1069,11 +1069,11 @@ static int ParseBasePathHelper(WOLFSSH* ssh, int cmdSz)
 
         if (sz > (int)sizeof(buf)) {
             return WS_BUFFER_E;
         }
 
-        WSTRNCPY(buf, ssh->scpBasePath, sz);
+        WSTRNCPY(buf, ssh->scpBasePath, sizeof(buf)-1);
         buf[sz] = '\0';
         WSTRNCAT(buf, "/..", sizeof("/.."));
         clean_path(buf);
 
         idx = (int)WSTRLEN(buf) + 1; /* +1 for delimiter */
diff --git a/src/wolfsftp.c b/src/wolfsftp.c
index f3ee822..86979fa 100644
--- a/src/wolfsftp.c
+++ b/src/wolfsftp.c
@@ -917,11 +917,11 @@ static int wolfSSH_SFTP_RecvRealPath(WOLFSSH* ssh, int reqId, byte* data,
 
     /* get working directory in the case of receiving non absolute path */
     if (r[0] != '/' && r[1] != ':') {
         char wd[WOLFSSH_MAX_FILENAME];
         if (ssh->sftpDefaultPath) {
-            XSTRNCPY(wd, ssh->sftpDefaultPath, sizeof(wd));
+            XSTRNCPY(wd, ssh->sftpDefaultPath, sizeof(wd)-1);
         }
         else {
         #ifndef USE_WINDOWS_API
             if (WGETCWD(wd, WOLFSSH_MAX_FILENAME) == NULL) {
                 WLOG(WS_LOG_SFTP, "Unable to get current working directory");

How can I build this project for arch arm?

I built wolfssl when I excute "make check" but it gave me this error log:

./testsuite/testsuite.test: line 117: /tes tsuite/.libs/lt-testsuite.test: cannot execute binary file: Exec format erro

My configurition is sudo ./configure CC=arm-linux-gcc --prefix=/home/zjq/Downloads/wolfssl-3.15.3/install --host=arm-linux --enable-ssh
@cconlon

STM32F446RE wolfSSH setup

Environment :
**Windows 10
Atollic TrueStudio
WolfSSH 1.3.0 **

I'm trying to build the application which can connect the linux box through ssh on said STM32 board. I have copied the source folders in my project and also the Free RTOS on the board.

Following are the errors where I stuck,

In file included from ../Inc/../wolfssl/wolfcrypt/types.h:29:0,
                 from ../wolfssh/ssh.h:34,
                 from ..\Src\main.c:55:
../Inc/../wolfssl/wolfcrypt/settings.h:1769:14: warning: #warning "For timing resistance / side-channel attack prevention consider using harden options" [-Wcpp]
             #warning "For timing resistance / side-channel attack prevention consider using harden options"
              ^~~~~~~
In file included from ../Inc/../wolfssl/wolfcrypt/types.h:30:0,
                 from ../wolfssh/ssh.h:34,
                 from ..\Src\main.c:55:
../Inc/../wolfssl/wolfcrypt/wc_port.h:145:17: error: unknown type name 'pthread_mutex_t'
         typedef pthread_mutex_t wolfSSL_Mutex;
                 ^~~~~~~~~~~~~~~
In file included from c:\program files (x86)\atollic\truestudio for stm32 9.0.1\armtools\arm-atollic-eabi\include\dirent.h:7:0,
                 from ../Inc/../wolfssl/wolfcrypt/wc_port.h:339,
                 from ../Inc/../wolfssl/wolfcrypt/types.h:30,
                 from ../wolfssh/ssh.h:34,
                 from ..\Src\main.c:55:
c:\program files (x86)\atollic\truestudio for stm32 9.0.1\armtools\arm-atollic-eabi\include\sys\dirent.h:10:2: error: #error "<dirent.h> not supported"
 #error "<dirent.h> not supported"
  ^~~~~
In file included from ../Inc/../wolfssl/wolfcrypt/types.h:30:0,
                 from ../wolfssh/ssh.h:34,
                 from ..\Src\main.c:55:
../Inc/../wolfssl/wolfcrypt/wc_port.h:360:9: error: unknown type name 'DIR'
         DIR*   dir;
         ^~~

How to build wolfSSH on STM32F767?

New Espressif Component Manager Integration Needed

Similar to wolfSSL/wolfssl#5319 and as noted in espressif/esp-idf#9288 there's a new Espressif Component Manager in the works.

wolfSSH needs to be integrated as an ESP-IDF component,

WS_SELECT_RECV_READY undefined

Inside NonBlockSSH_connect(WOLFSSH* ssh)

Below values are undefined,

WS_SELECT_RECV_READY
WS_SELECT_ERROR_READY
WS_SELECT_TIMEOUT

Which files contains the definition?

wolfSSH_SFTP_LS memory leak

Continued work to use wolfSSH in curl. I'm fixing directory listing over SFTP now and I invoke curl like this:

./src/curl -u user:password sftp://localhost/~/ -v

In libcurl I invoke wolfSSH_SFTP_LS() repeatedly until it returns success, like this:

https://github.com/curl/curl/blob/cc5019e8a2b75d3e345d2e97b1630261e89d3bce/lib/vssh/wolfssh.c#L647

... but even though my code calls wolfSSH_SFTPNAME_list_free() afterwards, valgrind still identifies memory being held by the LS function:

==1194== 
==1194== HEAP SUMMARY:
==1194==     in use at exit: 3,402 bytes in 66 blocks
==1194==   total heap usage: 2,828 allocs, 2,762 frees, 2,136,903 bytes allocated
==1194== 
==1194== 3,402 (88 direct, 3,314 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 4
==1194==    at 0x483577F: malloc (vg_replace_malloc.c:309)
==1194==    by 0x4B0BDCC: wolfSSH_SFTPNAME_new (wolfsftp.c:4377)
==1194==    by 0x4B0C5AB: wolfSSH_SFTP_DoName (wolfsftp.c:4761)
==1194==    by 0x4B0FA59: wolfSSH_SFTP_ReadDir (wolfsftp.c:6249)
==1194==    by 0x4B0D14B: wolfSSH_SFTP_LS (wolfsftp.c:5079)
==1194==    by 0x16C775: wssh_statemach_act (wolfssh.c:647)
==1194==    by 0x16C9FC: wssh_multi_statemach (wolfssh.c:711)
==1194==    by 0x16CEE7: wsftp_doing (wolfssh.c:903)
==1194==    by 0x1800A5: Curl_protocol_doing (url.c:1496)
==1194==    by 0x147537: multi_runsingle (multi.c:1698)
==1194==    by 0x14839E: curl_multi_perform (multi.c:2104)
==1194==    by 0x13FF76: easy_transfer (easy.c:606)
==1194== 
==1194== LEAK SUMMARY:
==1194==    definitely lost: 88 bytes in 1 blocks
==1194==    indirectly lost: 3,314 bytes in 65 blocks
==1194==      possibly lost: 0 bytes in 0 blocks
==1194==    still reachable: 0 bytes in 0 blocks
==1194==         suppressed: 0 bytes in 0 blocks
==1194== 
==1194== For lists of detected and suppressed errors, rerun with: -s
==1194== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

internal.c error: variable may be used uninitialized in this function

I'm compiling the wolfssh using the Espressif ESP-IDF. The default compiler settings are such that possibly uninitialized variable warnings are treated as errors. It is probably a good idea not to just ignore the warnings.

I've been able to appease the compiler by simply assigning an initial value of zero. I could submit a PR that does this. Alternatively perhaps the logic needs to be more closely investigated?

C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssl/wolfssl/wolfcrypt/settings.h:2348:14: warning: #warning "For timing resistance / side-channel attack prevention consider using harden options" [-Wcpp]
             #warning "For timing resistance / side-channel attack prevention consider using harden options"
              ^~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'GenerateKeys':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:997:49: error: 'sK' may be used uninitialized in this function [-Werror=maybe-uninitialized]
                                   sK->macKey, sK->macKeySz,
                                               ~~^~~~~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:992:45: error: 'cK' may be used uninitialized in this function [-Werror=maybe-uninitialized]
                               cK->macKey, cK->macKeySz,
                                           ~~^~~~~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'SendChannelOpen':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:9314:13: error: 'channelTypeSz' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         idx += channelTypeSz;
         ~~~~^~~~~~~~~~~~~~~~
In file included from C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/wolfssh/ssh.h:39,
                 from C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:32:
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/wolfssh/port.h:384:31: error: 'channelType' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     #define WMEMCPY(d,s,l)    memcpy((d),(s),(l))
                               ^~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:9287:17: note: 'channelType' was declared here
     const char* channelType;
                 ^~~~~~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'DoKexDhReply':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:3181:23: error: 'e' may be used uninitialized in this function [-Werror=maybe-uninitialized]
                 ret = wc_RsaPublicKeyDecodeRaw(n, nSz, e, eSz,
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                &sigKeyBlock_ptr->sk.rsa.key);
                                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:49:
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'SendKexDhReply':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/misc.c:87:10: error: 'sigBlockSz' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     c[3] =  u32 & 0xff;
     ~~~~~^~~~~~~~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:6856:12: note: 'sigBlockSz' was declared here
     word32 sigBlockSz;
            ^~~~~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'SendUserAuthRequest':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:8999:13: error: 'serviceNameSz' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         idx += serviceNameSz;
             ^~
In file included from C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/wolfssh/ssh.h:39,
                 from C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:32:
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/wolfssh/port.h:384:31: error: 'serviceName' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     #define WMEMCPY(d,s,l)    memcpy((d),(s),(l))
                               ^~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:8890:17: note: 'serviceName' was declared here
     const char* serviceName;
                 ^~~~~~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:9004:13: error: 'authNameSz' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         idx += authNameSz;
             ^~
In file included from C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/wolfssh/ssh.h:39,
                 from C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:32:
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/wolfssh/port.h:384:31: error: 'authName' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     #define WMEMCPY(d,s,l)    memcpy((d),(s),(l))
                               ^~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:8888:17: note: 'authName' was declared here
     const char* authName;
                 ^~~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'DoUserAuthRequestPassword':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:4011:31: error: 'pw' may be used uninitialized in this function [-Werror=maybe-uninitialized]
             pw->newPasswordSz = 0;
             ~~~~~~~~~~~~~~~~~~^~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'DoUserAuthRequestPublicKey':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:4562:27: error: 'pk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
                     ret = DoUserAuthRequestEcc(ssh, pk,
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                hashId, digest, digestSz);
                                                ~~~~~~~~~~~~~~~~~~~~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'DoChannelOpen':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:5040:15: error: 'newChannel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         ret = SendChannelOpenConf(ssh, newChannel);
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'SendChannelEof':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:9493:25: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         channel->eofTxd = 1;
         ~~~~~~~~~~~~~~~~^~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'SendChannelEow':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:9533:9: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         c32toa(channel->peerChannel, output + idx);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'SendChannelExit':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:9582:9: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         c32toa(channel->peerChannel, output + idx);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'SendChannelClose':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:9645:27: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         channel->closeTxd = 1;
         ~~~~~~~~~~~~~~~~~~^~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'SendChannelData':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:9692:24: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         word32 bound = min(channel->peerWindowSz, channel->peerMaxPacketSz);
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/wolfssh/port.h:34,
                 from C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/wolfssh/ssh.h:39,
                 from C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:32:
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'SendChannelRequest':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/wolfssh/log.h:76:27: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
                           wolfSSH_Log(__VA_ARGS__); \
                           ^~~~~~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:9803:22: note: 'channel' was declared here
     WOLFSSH_CHANNEL* channel;
                      ^~~~~~~
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c: In function 'SendChannelSuccess':
C:/Users/gojimmypi/Desktop/esp-idf/components/wolfssh/src/internal.c:10224:9: error: 'channel' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         c32toa(channel->peerChannel, output + idx);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1.exe: some warnings being treated as errors
[1096/1162] Building C object esp-idf/wolfssl/CMakeFiles/__idf_wolfssl.dir/wolfcrypt/src/falcon.c.obj
ninja: build stopped: subcommand failed.
ninja failed with exit code 1

cc: @dgarske

wolfSSH_set_fd: portability issue with sockets on win64

The wolfSSH_set_fd() function takes an 'int' for socket, which won't work with win64 that uses a SOCKET type which is 64 bit while int is 32 bit:

wolfssh/wolfssh/ssh.h

Line 67 in 57a869e

WOLFSSH_API int wolfSSH_set_fd(WOLFSSH*, int);

Update: the same problem exists for wolfSSH_get_fd()

create wolfssh-examples repo?

Although there are considerably fewer wolfssh examples as compared to wolfssl-examples and wolfssl/examples
what do you think if creating a wolfssh-examples repo?

cc: @dgarske @ejohnstown

wolfSSH_SFTP_SendReadPacket returns more bytes than asked for!?

Continuing my efforts of using this from curl, I call wolfSSH_SFTP_SendReadPacket to read data from the remote file.

I have an 18 byte file on my OpenSSH sftp test server and I run this curl command line:

./src/curl -u [credentials] sftp://localhost/~/hello -v

It makes curl open and stat the file just fine, determining that it is indeed 18 bytes. It then moves on to read the file (see link to the read function below) which right now asserts because on the first call when asked to read 18 bytes - it even says to wolfssh that the output buffer is 18 bytes - it very often returns 29. I have not checked to see if this truly writes more data into the buffer or if it just returns the wrong value - or perhaps I just have misunderstood how to use it?

Appreciate your feedback!

https://github.com/curl/curl/blob/96d36c8707e3417fa881ff4f2cdb0277c65c7668/lib/wolfssh.c#L245-L281

!!!!!!!!! wsftp_recv, max 18 bytes from offset 0
!!!!!!!!! wsftp_recv returns 29
curl: wolfssh.c:273: wsftp_recv: Assertion `rc <= (int)len' failed.
Aborted

wolfSSH on STM32L4

Hi everyone,
I'm trying to use wolfSSH on STM32L4 + FreeRTOS. Is it possible to do it and, if so, what are the steps to achieve that?
I see there is a dependency on wolfCrypt, which I guess I can solve as explained in #219 . What are the dependencies as regards the networking part? So far I've had some problems finding necessary include files such as netdb.h (which I've solved using lwip, although I'm not sure it really works) and sys/ioctl.h (which I couldn't find anywhere).

Thanks in advance for your help

libwolfssl not detected during configure for cross-compiling

I am trying to cross-compile wolfssh for arm, but it is not detecting libwolfssl that I have compiled. below is what I am doing:

❯ ./configure --host=arm-linux-gnueabi --prefix=/usr/arm-linux-gnueabi --enable-static LDFLAGS=-static --disable-stripping --without-manpages --without-tack --without-tests
......
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking for socket in -lnetwork... no
checking for forkpty in -lutil... yes
checking for wolfCrypt_Init in -lwolfssl... no
configure: error: libwolfssl is required for wolfssh. It can be obtained from https://www.wolfssl.com/download.html/ .
❯ ls /usr/arm-linux-gnueabi/lib/libwolf*
/usr/arm-linux-gnueabi/lib/libwolfssl.a   /usr/arm-linux-gnueabi/lib/libwolfssl.so     /usr/arm-linux-gnueabi/lib/libwolfssl.so.24.4.0
/usr/arm-linux-gnueabi/lib/libwolfssl.la  /usr/arm-linux-gnueabi/lib/libwolfssl.so.24

The lib files are in the correct folder, but it is not getting detected. Where is the configure script looking for this file?

ssh_client : command not found

Release : WolfSSH 1.3.0 - stable

Sorry if I missing something obvious here. But spare me I'm new to this!

I have compiled and build the code successfully also started the echo server. But when I run the
ssh_client localhost -p 22222
command in another terminal. I'm getting command not found.

wolfssh-1.4.8-stable dont build: syntax error near unexpected token `2.2'

i have CentOS Linux release 7.9.2009 (Core) [supported up to June 30th 2024]
i get ever when i './configure'

./configure: line 3275: syntax error near unexpected token `2.2'
./configure: line 3275: `LT_PREREQ(2.2)'

and 'autoreconf -i' says

Makefile.am:8: error: Libtool library used but 'LIBTOOL' is undefined
Makefile.am:8:   The usual way to define 'LIBTOOL' is to add 'LT_INIT'
Makefile.am:8:   to 'configure.ac' and run 'aclocal' and 'autoconf' again.
Makefile.am:8:   If 'LT_INIT' is in 'configure.ac', make sure
Makefile.am:8:   its definition is in aclocal's search path.
autoreconf: automake failed with exit status: 1

wolfssl is already installed in /usr/local
i have aclocal 1.14.1 and autoreconf 2.69 and libtool 2.4.2 and automake 1.14.1 are installed

that is a known problem, i found this https://www.mail-archive.com/[email protected]/msg43043.html (from the end of August 2021) but no solution

[SFTP] Handle size found was too big

I have the beginnings of support for wolfSSH in curl in a separate branch.

I build and run my code on a Linux Debian unstable x64-64. I run an SFTP server with OpenSSH_7.9p1. Plain password authentication.

When I build with current wolfssh (commit a3881e1, dated May 10) and run my code like this:

curl -u scptest:scptest sftp://localhost/~/hello -v

It fails, and wolfssh logs the following lines from the SFTP open call and onwards, ending with it returning a failure that I just can't understand. Does this happen because of some mistake on my part or is this a problem in wolfssh?

Any suggestions on what I can do to analyze this further?

2019-05-13 15:42:48 [SFTP] Entering wolfSSH_SFTP_Open()
2019-05-13 15:42:48 [SFTP] SFTP OPEN STATE: INIT
2019-05-13 15:42:48 [SFTP] SFTP OPEN STATE: SEND
2019-05-13 15:42:48 [DEBUG] Entering wolfSSH_stream_send()
2019-05-13 15:42:48 [DEBUG] Entering SendChannelData()
2019-05-13 15:42:48 [DEBUG] Entering ChannelFind(): peer 0
2019-05-13 15:42:48 [DEBUG] Leaving ChannelFind(): 0x564930cd7500
2019-05-13 15:42:48 [DEBUG] BP: paddingSz = 14
2019-05-13 15:42:48 [DEBUG] EncryptAead [email protected]
2019-05-13 15:42:48 [INFO]   dataSz = 40
2019-05-13 15:42:48 [INFO]   peerWindowSz = 2097129
2019-05-13 15:42:48 [INFO]   update peerWindowSz = 2097089
2019-05-13 15:42:48 [DEBUG] Entering wolfSSH_SendPacket()
2019-05-13 15:42:48 [DEBUG] Embed Send trying to send 84
2019-05-13 15:42:48 [DEBUG] Embed Send sent 84
2019-05-13 15:42:48 [DEBUG] SB: Shrinking output buffer
2019-05-13 15:42:48 [DEBUG] Entering ShrinkBuffer()
2019-05-13 15:42:48 [DEBUG] SB: usedSz = 0, forcedFree = 0
2019-05-13 15:42:48 [DEBUG] SB: releasing dynamic buffer
2019-05-13 15:42:48 [DEBUG] Leaving ShrinkBuffer()
2019-05-13 15:42:48 [DEBUG] Leaving SendChannelData(), ret = 40
2019-05-13 15:42:48 [DEBUG] Leaving wolfSSH_stream_send(), txd = 40
2019-05-13 15:42:48 [SFTP] SFTP OPEN STATE: GETHANDLE
2019-05-13 15:42:48 [SFTP] Entering wolfSSH_SFTP_GetHandle
2019-05-13 15:42:48 [SFTP] SFTP GET HANDLE STATE: INIT
2019-05-13 15:42:48 [SFTP] SFTP GET HANDLE STATE: GET_HEADER
2019-05-13 15:42:48 [DEBUG] Entering wolfSSH_stream_read()
2019-05-13 15:42:48 [DEBUG] PR1: size = 16
2019-05-13 15:42:48 [DEBUG] Receive: recvd = 16
2019-05-13 15:42:48 [DEBUG] PR2: size = 52
2019-05-13 15:42:48 [DEBUG] Receive: recvd = 36
2019-05-13 15:42:48 [DEBUG] DecryptAead [email protected]
2019-05-13 15:42:48 [DEBUG] DoPacket sequence number: 12
2019-05-13 15:42:48 [DEBUG] Decoding MSGID_CHANNEL_DATA
2019-05-13 15:42:48 [DEBUG] Entering DoChannelData()
2019-05-13 15:42:48 [DEBUG] Entering ChannelFind(): self 0
2019-05-13 15:42:48 [DEBUG] Leaving ChannelFind(): 0x564930cd7500
2019-05-13 15:42:48 [DEBUG] Entering ChannelPutData()
2019-05-13 15:42:48 [INFO]   dataSz = 17
2019-05-13 15:42:48 [INFO]   windowSz = 16179
2019-05-13 15:42:48 [INFO]   windowSz = 16162
2019-05-13 15:42:48 [DEBUG] Leaving DoChannelData(), ret = -1057
2019-05-13 15:42:48 [DEBUG] PR3: peerMacSz = 16
2019-05-13 15:42:48 [DEBUG] PR4: Shrinking input buffer
2019-05-13 15:42:48 [DEBUG] Entering ShrinkBuffer()
2019-05-13 15:42:48 [DEBUG] SB: usedSz = 0, forcedFree = 1
2019-05-13 15:42:48 [DEBUG] SB: releasing dynamic buffer
2019-05-13 15:42:48 [DEBUG] Leaving ShrinkBuffer()
2019-05-13 15:42:48 [DEBUG] PR5: txCount = 336, rxCount = 1200
2019-05-13 15:42:48 [DEBUG] Leaving wolfSSH_stream_read(), rxd = 9
2019-05-13 15:42:48 [SFTP] SFTP GET HANDLE STATE: CHECK_REQ_ID
2019-05-13 15:42:48 [SFTP] SFTP GET HANDLE STATE: READ
2019-05-13 15:42:48 [DEBUG] Entering wolfSSH_stream_read()
2019-05-13 15:42:48 [DEBUG] Leaving wolfSSH_stream_read(), rxd = 8
2019-05-13 15:42:48 [SFTP] Handle size found was too big
2019-05-13 15:42:48 [SFTP] SFTP GET HANDLE STATE: CLEANUP
2019-05-13 15:42:48 [SFTP] Error getting handle
2019-05-13 15:42:48 [SFTP] SFTP OPEN STATE: CLEANUP
2019-05-13 15:42:48 [DEBUG] Entering wolfSSH_get_error()
* wolfssh SFTP open failed: -1004
* multi_done
* Connection #0 to host localhost left intact
curl: (79) wolfssh SFTP open failed: -1004
2019-05-13 15:42:48 [DEBUG] Entering wolfSSH_Cleanup()
2019-05-13 15:42:48 [DEBUG] Leaving wolfSSH_Cleanup(), returning 0

Not able to find 'Dhkey'

Getting following issue,
wolfssh/wolfssh/internal.h:245:9: error: unknown type name 'DhKey'

whereas #include <wolfssl/wolfcrypt/dh.h> added.

user_settings.h

is as follows,

#define NO_WOLFSSL_DIR
#define WOLFCRYPT_ONLY
#define WOLFSSL_KEY_GEN
#define HAVE_ECC
#define HAVE_AESGCM
#define HAVE_HASHDRBG
#define WOLFSSL_SHA384
#define WOLFSSL_SHA512
#define NO_PSK
#define NO_HC128
#define NO_RC4
#define NO_RABBIT
#define NO_DSA
#define NO_MD4
#define WC_RSA_BLINDING
#define USE_FAST_MATH
#define TFM_TIMING_RESISTANT
#define ECC_TIMING_RESISTANT
#define WOLFSSL_PUBLIC_MP

echoserver: Error with SSH shutdown.

examples\echoserver and tests\testsuite give "Error with SSH shutdown." when testing against examples\client.
Is it normal?

Possible copy/paste error in wolfsftp.c

In wolfsftp.c function wolfSSH_SFTP_Remove() this repeated condition is used four times:

if (ssh->error != WS_WANT_READ && ssh->error != WS_WANT_READ)

I presume the condition should be WS_WANT_WRITE but didn't want to submit a patch until I was sure that was the intention.

(also found using cppcheck)

Espressif IDE install is missing

Similar to the wolfSSL Espress IDE Setup, one is also needed here for the wolfssh in the ESP-IDF component directory.

I have something in the works, but had a minor stumble with GitHooks. PR coming soon.

feature request: seek for SFTP?

I'm working on making wolfSSH an alternative SSH backend for curl. One of the features it has is to do resumed downloads and "ranged requests" (only get the data from offset X to Y within a file).

I can't seem to find any API for wolfSSH to ask to seek within an SFTP file? Both libssh2 and libssh provide this. If wolfSSH would have it, it would get feature parity and it would possibly benefit user who'd not get this surprise.

I fully understand if this is not in the roadmap or not something you want to work on. It's just a friendly suggestion and wish.

Windows 10/11 (x64) binaries?

Hello,

I am interested in possibly using your WolfSSH components and in particular your SSH server in a project.

At this current stage in the development, I would just like to run a pre-compiled ssh server so that I can test out first before digging into compiling everything on Visual Studio 2019, or 2022.

The release do not show any binaries and I also cannot locate them on the website.

Where can I find them?
Thanks