Re: Config parser doesn't accept multiple IdentityFile lines

[Tilo Eckert]

This workaround does not work either:

IdentityFile /path/to/id
Host somehost
IdentityFile /path/to/other_id

The host-specific IdentityFile is ignored as well if a global one is 
present. The seen flags should probably be reset when encountering a 
"Host" or "Match" keyword (in addition to the suggestion below).


Regards
Tilo

Am 28.01.21 um 14:32 schrieb Tilo Eckert:

Hi,

~/.ssh/config can contain multiple lines with the "IdentityFile" keyword 
to add multiple keys to try in public key authentication.


The libssh config parser ignores all but the first IdentityFile line, 
resulting in failed authentication if the key that is accepted by the 
server is not the first.


The issue seems to be the "seen" array in ssh_config_parse_line() which 
already has Host, Match and Include as exceptions. Probably just need to 
add IdentityFile.


Regards
Tilo

Config parser doesn't accept multiple IdentityFile lines

[Tilo Eckert]

Hi,

~/.ssh/config can contain multiple lines with the "IdentityFile" keyword 
to add multiple keys to try in public key authentication.


The libssh config parser ignores all but the first IdentityFile line, 
resulting in failed authentication if the key that is accepted by the 
server is not the first.


The issue seems to be the "seen" array in ssh_config_parse_line() which 
already has Host, Match and Include as exceptions. Probably just need to 
add IdentityFile.


Regards
Tilo

Re: SFTP Write async

[Tilo Eckert]

Hi Carlos

I already implemented a basic API some time ago, which is used in 
production. Maybe it can serve you as a starting point. The API is very 
raw, but it works. It allows you to trigger an arbitrary number of 
concurrent async SFTP reads and writes and to fetch the results later 
using the request id. Look for the sftp_async_*() functions:


https://github.com/limes-datentechnik-gmbh/libssh/blob/limes/src/sftp.c

The hard parts have to be implemented by user code which is why I did 
not submit it to upstream. The user code has to manage lists of 
in-transit requests, handle write ACKs, implement a suitable read-ahead 
strategy (depends on read pattern, e.g. lengthy sequential reads vs. 
heavy seeking), proper seeks (you need to track file offsets from user 
perspective for working relative seeks and discard already requested 
blocks). Those parts should be handled by libssh in a final 
implementation because it's easy to produce memory leaks, lose track of 
the correct file offset or have an underperforming read-ahead algorithm.


The most difficult aspect is the read-ahead strategy. There is no one 
size fits all. If you optimize for maximum throughput by using a large 
read-ahead window, you will waste a lot of bandwidth/time waiting for 
data you no longer need if you seek a lot because there is no way in 
SFTP to cancel sent read requests. If you optimize for seek, you will 
have slower throughput.


The current SFTP API could be re-implemented using the async methods and 
a configurable per-file read-ahead strategy which would considerably 
speed up performance. Libssh users that don't write async applications 
but want reasonable throughput and a simple API would no longer be bound 
by network latency as is the case with the current implementation.


Regards,
Tilo

Am 02.06.2020 um 20:32 schrieb Carlos Cabanero:

I couldn’t find any async_write method, but some thought was put into it
from this 2014 thread:
https://www.libssh.org/archive/libssh/2014-06/014.html. Is this
somewhere? Are we still interested to have it and are there any suggestions?

Thanks!

Re: Config file parsing order

[Tilo Eckert]

Am 14.02.2020 um 14:19 schrieb Anderson Sasaki:
> The values in the local configuration have priority over the values in the 
> global configuration.
> 
> In the client values set through configuration files will follow OpenSSH's 
> way, where the first value seen is kept, independently on that being in a 
> different configuration file.
> This is implemented by keeping a table where the options seen are marked 
> (search for 'seen' in src/config.c). But this also means that an option set 
> by a configuration file can't be overridden later by another configuration 
> file (only by setting manually through ssh_options_set()).

I originally misread the "seen" implementation in
ssh_config_parse_line(). It indeed causes options from the user config
file to be preferred over system-wide config options.

Nonetheless, manually set options are ignored if present in one of the
two files and no custom config file is loaded (which our code doesn't)
or the autoload suppress option is not set (did not exist at the time
our code was written). It's a regression bug introduced with the
ssh_options_parse_config() call in ssh_connect().

>> Wouldn't it be more reasonable if options from autoloaded config files
>> are only applied if not already set?
> 
> For me the answer is yes: options set manually through ssh_options_set() 
> should take precedence. But we can't simply change the behavior like this (it 
> would be an ABI breakage).

I submitted a merge request which does not introduce an ABI change and
does not modify the semantics of ssh_options_parse_config() if called by
a libssh user:
https://gitlab.com/libssh/libssh-mirror/-/merge_requests/95

Regards,
Tilo

Config file parsing order

[Tilo Eckert]

Hi everyone,

we are currently facing an issue with the order in which options from
the OpenSSH config files are applied.

When setting up a connection, we call ssh_options_set() for all options
we want to set, followed by ssh_connect(). Commit 89a8a6fc introduced
automatic loading of user-specific and system-wide OpenSSH config files
if no config file has been loaded explicitly. This overrides options
previously set with ssh_options_set() if they also appear in one of the
config files as mentioned in the commit message.

There are multiple problems with this behavior:

1) It is counter-intuitive. Options set explicitly should override
options set in automatically loaded config files. The default global
OpenSSH config file is intended to contain reasonable defaults which may
be overridden by the user-specific config file or via command line.
>From OpenSSH docs:
> ssh(1) obtains configuration data from the following sources in the following 
> order:
>   1.   command-line options
>   2.   user's configuration file (~/.ssh/config)
>   3.   system-wide configuration file (/etc/ssh/ssh_config)
> For each parameter, the first obtained value will be used.

Imo, that is how it should work in libssh, too.

2) Libssh implements the exact opposite order. This leads to conflicts
if the user uses the OpenSSH client and a libssh-based client on the
same machine/account. For example, if the user configures his
non-default known_hosts path in ~/.ssh/config to avoid passing it to the
OpenSSH CLI every time, there is no way to override this with
ssh_options_set() if the user wants to use a different known_hosts file
with libssh. The user of the libssh-based client would need to create a
new config file that we have to load with ssh_options_parse_config()
before connecting.

3) We could call ssh_options_parse_config(session, NULL) before setting
our own options to work around it, but the user and system-wide config
files would still be loaded in the wrong order, with system-wide config
taking top priority.

4) There is no documentation about the overriding behavior of the
ssh_connect() function.

TL;DR
Is it intentional that libssh options priority is the exact opposite of
what OpenSSH does? If yes, why?
Wouldn't it be more reasonable if options from autoloaded config files
are only applied if not already set?

Regards,
Tilo Eckert

Re: [patch] Use inttypes macros for size_t format string

[Tilo Eckert]

Am 23.01.2020 um 10:00 schrieb Andreas Schneider:
> On Wednesday, 22 January 2020 17:40:04 CET Tilo Eckert wrote:
>> Am 22.01.2020 um 13:56 schrieb g4-l...@tonarchiv.ch:
>>> For Windows I can find documentation of "z" as supported spezifier:
>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/format-specificatio
>>> n-syntax-printf-and-wprintf-functions?view=vs-2019#size-prefixes-for-print
>>> f-and-wprintf-format-type-specifiers
>>>
>>> But not sure since when this is supported.
>>
>> Apparently, %zu is supported since VS 2015 (or 2013?), %Iu is the older
>> MS-specific alternative. Support for ANSI C99 still seems not to be 100%
>> complete in VS.
>>
>>> But anway: What is the advantage of using typecasts instead of a format
>>> spezifier macro (see my patch)? You still have to use OS specific type
>>> casts. Or I'm understanding this wrong?
>>
>> There is no printf format specifier macro for size_t in standard
>> headers. The PRIdS macro in priv.h defines a format specifier for
>> printing a ssize_t. We would need a PRIuS macro (`Iu` on Windows, `zu`
>> everywhere else) as you suggested in an earlier email because size_t is
>> unsigned. However, I'm not 100% certain whether this works in all build
>> environments. If you get this macro wrong, not all compilers will warn
>> you about a bad format string.
>>
>> A safe, headache-free, C89 compatible, but not as pretty alternative
>> that will not break in compiler environments of the last 20+ years:
>> printf("%llu", (long long unsigned) size)
> 
> I would prefer to go with:
> 
> -Dsnprintf=__mingw_snprintf -Dvsnprintf=__mingw_vsnprintf
> 
> 
> The question is if we should document how to do it with mingw and suggest a 
> toolchain file having this set, or if we add this to our cmake or priv.h in 
> case of MinGW ...

This is not a MinGW problem, but a general Windows one as I already
tried to explain. Format specifier %zu is not supported in VS versions
older than 5 years because MS didn't bother to make their printf
implementation comply to C99 for a long time. Hence, we should use
MS-proprietary %Iu on Windows or avoid using %z at all to make format
strings compatible with MinGW and VS.

Regards,
Tilo

Re: [patch] Use inttypes macros for size_t format string

[Tilo Eckert]

Am 22.01.2020 um 13:56 schrieb g4-l...@tonarchiv.ch:
> For Windows I can find documentation of "z" as supported spezifier:
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=vs-2019#size-prefixes-for-printf-and-wprintf-format-type-specifiers
> 
> But not sure since when this is supported.
Apparently, %zu is supported since VS 2015 (or 2013?), %Iu is the older
MS-specific alternative. Support for ANSI C99 still seems not to be 100%
complete in VS.

> But anway: What is the advantage of using typecasts instead of a format
> spezifier macro (see my patch)? You still have to use OS specific type
> casts. Or I'm understanding this wrong?
There is no printf format specifier macro for size_t in standard
headers. The PRIdS macro in priv.h defines a format specifier for
printing a ssize_t. We would need a PRIuS macro (`Iu` on Windows, `zu`
everywhere else) as you suggested in an earlier email because size_t is
unsigned. However, I'm not 100% certain whether this works in all build
environments. If you get this macro wrong, not all compilers will warn
you about a bad format string.

A safe, headache-free, C89 compatible, but not as pretty alternative
that will not break in compiler environments of the last 20+ years:
printf("%llu", (long long unsigned) size)

Regards,
Tilo

Re: [patch] Use inttypes macros for size_t format string

[Tilo Eckert]

Am 22.01.2020 um 08:49 schrieb Andreas Schneider:
> On Thursday, 16 January 2020 12:55:07 CET g4-l...@tonarchiv.ch wrote:
 According to that you need to compile with:

 cmake -DCMAKE_C_FLAGS="-D__USE_MINGW_ANSI_STDIO=1" ..
>>>
>>> Alternative seems to be:
>>>
>>> -Dsnprintf=__mingw_snprintf -Dvsnprintf=__mingw_vsnprintf ...
>>
>> Yes i was a bit overhasty with this patch...
>>
>> I also found that _POSIX_SOURCE does the trick. This would be a bit more
>> generic.
>>
>> But I realized that the binaries get bigger like that, probably because
>> they link in more of their own implementations. Not sure, if this is a
>> good thing...
>>
>> -Dsnprintf=__mingw_snprintf -Dvsnprintf=__mingw_vsnprintf looks like a
>> good compromise to me. I will also test this.
> 
> Which route should we go? Just set _POSIX_SOURCE?
>  

None of them. If you want libssh to work on Windows when built without
MinGW, %z must not be used at all. The Windows implementation of printf
does not support it. You have to use typecasts to print size_t in a
portable way.

Defining __USE_MINGW_ANSI_STDIO directly has been deprecated and emits a
warning in newer MinGW versions:
https://osdn.net/projects/mingw/scm/git/mingw-org-wsl/commits/36fae3c324a1997356db40caa83d0fac512b9407

Defining one of _XOPEN_SOURCE, _POSIX_C_SOURCE or _POSIX_SOURCE
(deprecated) implicitly enables __USE_MINGW_ANSI_STDIO. MinGW replaces
the printf and scanf function families with C99 compliant versions if
any of the defines is set, leading to slightly larger binaries. However,
that would only fix it if MinGW is used...

Regards,
Tilo

Re: ssh_channel_open_session slow to return

[Tilo Eckert]

Am 23.04.2019 um 20:44 schrieb Paul Beerkens:
> From an example I copy pasted:
> 
> rc = ssh_userauth_publickey_auto(my_ssh_session, NULL,NULL);
> if (rc == SSH_AUTH_ERROR)
> 
> 
> But that does not cover SS_SSH_AUTH_DENIED.
> 
> 
> I simply need to change it to cover SSH_AUTH_DENIED. 
> 
> 
> Maybe rc!=SSH_AUTH_SUCCESS is what I will go with.

Unless you know exactly which servers you are talking to, you also need
to check for SSH_AUTH_PARTIAL because the server might require multiple
authentications in a row. If you are operating in non-blocking mode,
SSH_AUTH_AGAIN must be checked, too.

See API docs:
http://api.libssh.org/master/group__libssh__auth.html#ga53e6771b250c061463ed98b6e5b6e0af

Regards
Tilo

Re: [patch]: Stop connector socket-to-channel EOF flooding

[Tilo Eckert]

Am 09.04.2019 um 12:39 schrieb g4-l...@tonarchiv.ch:
>> check whether you already sent it before: channel->local_eof != 0
> BTW channel properties are not exposed to client code. So maybe this
> check should be added directly to channel_send_eof()?

Yes, I think so, too. It does not really make sense to be able to send
EOF repeatedly on the same channel.

Re: [patch]: Stop connector socket-to-channel EOF flooding

[Tilo Eckert]

Am 08.04.2019 um 20:54 schrieb g4-l...@tonarchiv.ch:
>> I'm using connectors for a direct-tcp client. So this creates two
>> connectors FD in --> channel out and vice versa.
>>
>> Now when the socket forwarding peer (not the ssh server) closes the
>> connection, i.e. reading on the socket returns 0 = EOF, we end up in
>> some loop with sending EOFs on the channel, until finally the client
>> receives a channel close message.
>>
> I attached some test code to reproduce this.
> 
> Edit line 14 to your needs. It should connect to a service which does
> not dicsonnecet the connenction from its side. I.e. SSH is fine. A
> webserver will not do because it disconnects after answering the request.
> 
> Start a local sshd with 
> 
> shell1>  /usr/sbin/sshd -d -d -p 
> 
> shell2> ./fwconnector username localhost 
> 
> shell3> ssh admin@localhost -p 2022
> Welcome to Debian...
> ~: exit
> 
> On shell1 you will see the > 20 lines of "channel 0: rcvd eof"

Your callback sends an EOF for every received EOF from the server. If
your server does the same, you end up with EOF ping pong. You might want
to check whether you already sent it before: channel->local_eof != 0

Btw, if you close the channel on your end, an EOF is sent automatically
if one has not been sent, yet.

Re: Multithreading question

[Tilo Eckert]

Hi Stefano,

you cannot use a single session in multiple threads concurrently. That
also applies to all channels created for that session. See here:
http://api.libssh.org/stable/libssh_tutor_threads.html

If you are talking about command execution via
ssh_channel_request_exec(), you will have to create a channel for each
command because the channel is closed when the command ends. Channel
reuse is not possible when running single commands. SFTP channels can be
reused.

Regards
Tilo Eckert

Am 30.03.2019 um 10:51 schrieb Stefano Mtangoo:
> Until now I have been using libssh on the main thread. But It is
> annoying as it will sometimes freeze the UI. Network woes sometimes
> makes UI freezing and that isn't nice. So I want to move all operations
> to another thread. But I have questions that I cannot find answers to:
> 1. If I store session in Main UI and pass it in every thread (sometimes
> mutiple threads will be running under same session) do I have to do
> locking or libssh provides one? The docs on MT seems to indicate that
> for dynamic linked DLL
> 
> 2. I plan to create new sftp object per thread with sftp_new(). What is
> the performance impact compared to psersisting it?
> 
> 3. I plan to create new channel for each command from same session when
> sending a command. How much is performance impacted compared to
> persisting a channel
> 
> I do simple command for file management via SFTP (CRUD) plus sending
> some commands to remote SSH server.
> 
> Thank you.
> 
> -- 
> for me to live is Christ to die is gain

Re: Best way to deal with long opened sessions

[Tilo Eckert]

Hi Stefano,

ssh_is_connected() returns session->alive which is only set to 0 when
the client or server explicitly disconnects or the handshake fails.

If your connection silently dies, you can only notice this when you send
anything to the server and it does not respond within some time frame.
If you configured a libssh timeout, most blocking functions will return
SSH_ERROR when the server does not respond to your request. You would
still have to call ssh_disconnect() yourself because a timeout does not
necessarily mean that the remote host is gone.

If you leave your connection open for longer periods of time without
interacting with the server, you will not notice a silently broken
connection until you send something to the server and wait for its
reply. If you want to detect broken connections even while idling, you
should probably enable TCP keep-alive packets by enabling SO_KEEPALIVE
on the socket:
> socket_t socket = ssh_get_fd(session);
> int yes = 1;
> if (setsockopt(socket, SOL_SOCKET, SO_KEEPALIVE, &yes, sizeof(int)) < 0) {
>   // setting SO_KEEPALIVE failed
> }

It will cause your OS kernel to automatically send keep-alive TCP
packets every now and then (configurable on Linux via TCP_KEEPIDLE,
TCP_KEEPINTVL, TCP_KEEPCNT socket options). This is transparent to your
application. If the server does not respond for some time (Linux kernel
default: 30 minutes), the TCP socket is closed by the kernel. To notice
the latter, the socket must be polled. So, you need to regularly call
any libssh function that reads from or writes to the socket and check if
that fails.

Best regards
Tilo Eckert

Am 14.03.2019 um 07:57 schrieb Stefano Mtangoo:
> Hi,
> This library have made my life simpler and would like to thank everyone
> involded.
> I have one thing that I would like to get your advice on. I keep my
> session long open when I edit something on the server. During those long
> time network can be lost and be restored.
> 
> Is checking for `ssh_is_connected` alone enough?
> I use SFTP module to connect to the server and edit stuffs and ssh_* for
> everything else.
> Regards,
> Stefano
> -- 
> for me to live is Christ to die is gain

Re: vcpkg libssh 0.8.x version isn't available

[Tilo Eckert]

Hi Franciszek,

as far as I understand vcpkg, its packages are maintained by Microsoft
and they rely on users to provide pull requests or create tickets asking
for integration. The files for libssh are here:
https://github.com/Microsoft/vcpkg/tree/master/ports/libssh

Since you are already building on Linux, you could cross-compile your
desired version of libssh for Windows using MingW GCC. I use these cmake
options to enable cross-compilation:

(32 bit)
> "-DCMAKE_C_FLAGS:STRING=-m32 -march=i686 -mtune=generic" 
> -DCMAKE_SYSTEM_NAME=Windows -DCMAKE_C_COMPILER=i686-w64-mingw32-gcc

(64 bit)
> "-DCMAKE_C_FLAGS:STRING=-m64 -march=x86-64 -mtune=generic" 
> -DCMAKE_SYSTEM_NAME=Windows -DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc

Regards,
Tilo Eckert

Am 27.02.2019 um 21:55 schrieb Franciszek Juras:
> Hi,
> I have code working on linux that uses libssh 0.8.x api. Now that I want
> to port my application to windows, I wanted to build libssh using vcpkg.
> However, there is only 0.7.6 version of libssh available in vcpkg. What
> is the reason of such situation? Can I expect the 0.8.x version to be
> available soon?
> 
> Regards,
> FJ

Re: Issues with channel callbacks

[Tilo Eckert]

Am 25.02.2019 um 11:51 schrieb g4-l...@tonarchiv.ch:
> On 25.02.19 11:18, Tilo Eckert wrote:
> 
>> 3) My data callback is executed exactly once for every received channel
>> data packet. I think this should be changed to be more user-friendly:
>> The data callback should be executed repeatedly until it consumed all
>> available bytes or 0 (i.e. the callback signals that there is not enough
>> data to process). That would make it easier to implement custom protocol
>> handlers via callbacks. For example, a data callback that processes a
>> single line of text per call would no longer require a loop in the
>> callback function, leading to code that is easier to read.
> 
> Yes this would be very convenient on the client's side. But I also
> understand that this is quite complicated to implement on the lib's
> side, because it needed buffering of the data to read for an undefined
> period.

Buffering is already taken care of in channel_rcv_data(). If your custom
callback does not consume all data received on a channel, the remaining
data is passed to you again when more channel data arrives.

Regards,
Tilo Eckert

Issues with channel callbacks

[Tilo Eckert]

Hi,

I am experimenting with the ssh_event/connector APIs to remotely execute
commands and process the returned output via callbacks (to retain the
order of stdin and stderr messages as sent by the server). I used the
shell() and select_loop() functions from the ssh_client.c example as a
starting point. However, I replaced the stdout and stderr connectors
with callbacks like this:

> ssh_connector connector_in;
> ssh_callbacks_init(&callback);
> callback.userdata = NULL;
> callback.channel_data_function = channel_data_callback;
> callback.channel_close_function = channel_close_callback;
> callback.channel_eof_function = channel_eof_callback;
> callback.channel_exit_signal_function = channel_exit_signal_callback;
> callback.channel_exit_status_function = channel_exit_status_callback;
> ssh_add_channel_callbacks(channel, &callback);

I identified multiple issues with these callbacks during my experiments
and would appreciate some feedback on potential solutions:

1) If my data callback consumes less than the provided number of bytes
and the server closes the channel, the channel_rcv_close() callback in
channels.c will not actually set the channel state to closed, but set
channel->delayed_close = 1 instead because channel buffers are not
empty. This leads to an infinite loop in the main event loop:
> while (ssh_channel_is_open(channel)) {
> ssh_event_dopoll(event, 6);
> }
Question: The assignment channel->delayed_close = 1 seems to be there
for a long time. Is there still any justification for it? The only thing
it seems to do is prevent writing to the channel, which also happens
when the channel is in closed state. If it was meant to delay setting
the closed state on the channel until remaining buffer contents have
been read via ssh_channel_read(), I would expect that the channel is set
to closed state in one of the read functions, but I cannot find such
code. That leads me to believe that channel->delayed_close can be safely
removed to fix the infinite loop. I might be wrong, though.

2) If the channel is being closed and my data callback did not consume
all data before, I do not get a chance to process the remaining data
because there simply exists no callback to handle this case. I would
like to introduce a new callback for this purpose which is executed in
channel_rcv_close() right before the close callback if there is data
remaining in the buffers.

3) My data callback is executed exactly once for every received channel
data packet. I think this should be changed to be more user-friendly:
The data callback should be executed repeatedly until it consumed all
available bytes or 0 (i.e. the callback signals that there is not enough
data to process). That would make it easier to implement custom protocol
handlers via callbacks. For example, a data callback that processes a
single line of text per call would no longer require a loop in the
callback function, leading to code that is easier to read.

Regards,
Tilo Eckert

Re: Bugs when using rsa-sha2 (+patches)

[Tilo Eckert]

Hello Jakub,

the solution looks fine to me except for the assignment
sig->type_c = pubkey->type_c

The new test kind of proves my point that we should set it to the actual
sig type string that the server sends to us. The second inner for loop
successfully imported any signature blob with SSH_DIGEST_SHA1, even if
it was a SHA2 signature. The asserts incorrectly accepted that because
the public key type is ssh-rsa in both cases.

The two attached patches contain the necessary refactorings for your
branch and fix a few typos.

Regards,
Tilo

Am 26.11.2018 um 19:39 schrieb Jakub Jelen:
> Hello Tilo,
> Thank you for the valuable comments. See the comments inline.
> 
> On Mon, 2018-11-26 at 10:58 +0100, Tilo Eckert wrote:
>> Hello Jakub,
>>
>> I explored a similar solution to yours as an alternative, but
>> encountered the same ECDSA issue you mentioned which is caused by the
>> weird way that sig->type_c is set. It didn't make much sense to me
>> that
>> ssh_pki_import_signature_blob() reads the signature key type string
>> from
>> the signature blob, converts it to key type and hash type enums, only
>> to
>> convert them back to a key type string in pki_signature_from_blob(),
>> which does not yield the same string the server sent in case of
>> ECDSA.
> 
> I assume this is based on the history, when it was very easy to have
> type_c representation of the key type as a const string (either RSA or
> DSA). This approach gets more complicated when we have to deal with
> ECDSA keys and with the new SHA2 extension. It looks like the ECDSA
> implementation was not very tested so far. So lets fix it.
> 
>> The assignment "sig->type_c = pubkey->type_c" in your solution
>> troubles
>> me because the key type string from the public key and signature
>> portion
>> of the KEX message sent by the server are not the same string.
> 
> They are the same string for everything but RSA keys with SHA2
> extension. There is similar approach used for the ECDSA key import
> (setting default for all key types and overwriting for ECDSA based on
> the NID). But you are right, we should check first that the key matches
> base type of the signature before doing this. Added to my branch.
> 
>> If
>> anything, sig->type_c should be set to the value of variable "alg" in
>> ssh_pki_import_signature_blob(), which contains the actual key type
>> string the server included in its signature.
> 
> This would be also good solution, and it was also one of the
> possibilities that I was exploring initially, but the problem is that
> the string in type_c is constant and we would not be able to free it,
> unless we would do a lot of refactoring around, which I wanted to
> avoid.
> 
>> Instead of replacing the "ssh_match_group(..., server_key->type_c)"
>> check with "ssh_match_group(..., sig->type_c)", my alternative
>> solution
>> involved checking sig->type_c in addition to the verification of
>> server_key->type_c (as in my previous patch set).
> 
> I was also considering this check, but in the end decided it would be
> bogus -- the signature verification should not really pass if there
> would be key/signature mismatch, unless there would go something
> terribly wrong.
> 
> But it is always be safe than sorry. See below.
> 
>> I was thinking about
>> the case when a bad server sends incompatible server_key->type_c and
>> sig->type_c (e.g. server sends a public key with type "ssh-dss", but
>> the
>> key type string in the signature is "ssh-rsa").
> 
> This test should go to ssh_pki_signature_verify() to catch the same
> possible issue also in other places where we are validating signatures.
> And since I am "deriving" the signature type from the key type, the
> same check should also to the pki_signature_from_blob(), verifying that
> the base type of public key matches the received type of signature,
> before we assign the type_c from the public key to the signature.
> 
> This can be hardly tested with the real ssh session, but the unit tests
> should be able to catch it. I wrote a test to go through all the key
> types, try the import of non-matching signatures and verification of
> already created and imported keys and really, this could have crash
> badly.
> 
> I added few more checks and now the flags look sane and the cross-
> verify fails when it should.
> 
> I added these commits to my branch. Does this address your concerns?
> 
> https://gitlab.com/jjelen/libssh-mirror/commits/rsa-sha2-bug
> 
> Thank you,
> Jakub
> 
From f3942632e6f9ec7cea4e7aa25f8f72dc284a19d3 Mon Sep 1

Bugs when using rsa-sha2 (+patches)

[Tilo Eckert]

Hello Jakub,

I explored a similar solution to yours as an alternative, but
encountered the same ECDSA issue you mentioned which is caused by the
weird way that sig->type_c is set. It didn't make much sense to me that
ssh_pki_import_signature_blob() reads the signature key type string from
the signature blob, converts it to key type and hash type enums, only to
convert them back to a key type string in pki_signature_from_blob(),
which does not yield the same string the server sent in case of ECDSA.

The assignment "sig->type_c = pubkey->type_c" in your solution troubles
me because the key type string from the public key and signature portion
of the KEX message sent by the server are not the same string. If
anything, sig->type_c should be set to the value of variable "alg" in
ssh_pki_import_signature_blob(), which contains the actual key type
string the server included in its signature.

Instead of replacing the "ssh_match_group(..., server_key->type_c)"
check with "ssh_match_group(..., sig->type_c)", my alternative solution
involved checking sig->type_c in addition to the verification of
server_key->type_c (as in my previous patch set). I was thinking about
the case when a bad server sends incompatible server_key->type_c and
sig->type_c (e.g. server sends a public key with type "ssh-dss", but the
key type string in the signature is "ssh-rsa"). I'm not sure if
signature import/verification fails correctly in all possible cases. I
didn't thoroughly investigate this, though.

Kind regards
Tilo

Am 22.11.2018 um 11:02 schrieb Jakub Jelen:
> Hello Tilo,
> thank you for having a look into that.
> 
> I thought about a simpler solution, where you would check just the sig-
>> type_c value (this will contain the string rsa-sha2-*) against the
> list of allowed methods. But having a better look, this value was not
> properly set for the ECDSA keys (sigh ...), but fixing this for ECDSA
> makes the code simpler.
> 
> I reworked your patch set a bit to something (I hope) is simpler, but
> should do the same thing:
> 
> https://gitlab.com/jjelen/libssh-mirror/commits/rsa-sha2-bug
> 
> Could you check if this looks good and works for you?
> 
> Thanks,
> Jakub
> 
> 
> On Wed, 2018-11-21 at 12:03 +0100, Tilo Eckert wrote:
>> Hi Jakub,
>>
>> the new patch set contains my previous rsa-sha2 related patches as
>> well
>> as fixes for the rsa-sha2 downgrade / ssh-rsa upgrade issues and the
>> ECDSA signature bypass when ECC is turned off. Please check if my
>> fixes
>> are sufficient.
>>
>> Initially I attempted to verify hostkey and signature algos
>> separately,
>> but that didn't work out very well. It would have meant a lot of
>> redundancy. After realizing that hostkey and signature need to be
>> considered together, performing the necessary checks in the new
>> hostkey
>> type validation function seemed straight-forward.
>>
>> If you or someone else has an idea on how to talk OpenSSH into being
>> a
>> naughty server or if you can come up with some other way to emulate
>> an
>> rsa-sha2 downgrade attack, feel free to add a test.
>>
>> Regards,
>> Tilo
>>
>>>> The function ssh_pki_signature_verify_blob() is used by server
>>>> (messages.c) and client code (packet_cb.c). So, I think one way
>>>> to
>>>> fix
>>>> it is to remove the ssh_pki_import_signature_blob() call from
>>>> ssh_pki_signature_verify_blob(), move it to the two callers and
>>>> pass
>>>> sig
>>>> instead of sig_blob to the verify function. That would allow us
>>>> to
>>>> check
>>>> the signature type in ssh_packet_newkeys() depending on the
>>>> allowed
>>>> hostkey types.
>>>
>>> That sounds like a way to go. The ssh_pki_signature_verify_blob()
>>> unfortunately does not have slightest idea what is the allowed list
>>> to
>>> verify against.
>>>
>>> We will not have the same problem in the server (messages.c),
>>> because
>>> server does not have any configuration which would allow to disable
>>> some authentication algorithms.
>>>
>>>> I think there may be another unrelated security issue in
>>>> ssh_pki_signature_verify_blob(): When compiling without ECC
>>>> support
>>>> and
>>>> the server sends an unexpected ECDSA signature, it would be
>>>> imported
>>>> successfully, "if (key->type == SSH_KEYTYPE_ECDSA)" would be
>>>> true,
>>>> but
>>>> the block does nothing. The function returns rc, which is still 0
>>>> from
>>>> the import. Maybe I missed something, but this looks to me like a
>>>> signature verification bypass. We should return SSH_ERROR if ECC
>>>> is
>>>> unsupported.
>>>
>>> I think you are right here. Setting the rc = SSH_ERROR in the else
>>> branch should fix this problem, but there might be more issues like
>>> this throughout the code.
>>>
>>> Would you like to submit a patch for these two issues?
>>>
>>> Thanks,
>>>

Re: Bugs when using rsa-sha2 (+patches)

[Tilo Eckert]

Hi Jakub,

the new patch set contains my previous rsa-sha2 related patches as well
as fixes for the rsa-sha2 downgrade / ssh-rsa upgrade issues and the
ECDSA signature bypass when ECC is turned off. Please check if my fixes
are sufficient.

Initially I attempted to verify hostkey and signature algos separately,
but that didn't work out very well. It would have meant a lot of
redundancy. After realizing that hostkey and signature need to be
considered together, performing the necessary checks in the new hostkey
type validation function seemed straight-forward.

If you or someone else has an idea on how to talk OpenSSH into being a
naughty server or if you can come up with some other way to emulate an
rsa-sha2 downgrade attack, feel free to add a test.

Regards,
Tilo

>> The function ssh_pki_signature_verify_blob() is used by server
>> (messages.c) and client code (packet_cb.c). So, I think one way to
>> fix
>> it is to remove the ssh_pki_import_signature_blob() call from
>> ssh_pki_signature_verify_blob(), move it to the two callers and pass
>> sig
>> instead of sig_blob to the verify function. That would allow us to
>> check
>> the signature type in ssh_packet_newkeys() depending on the allowed
>> hostkey types.
> 
> That sounds like a way to go. The ssh_pki_signature_verify_blob()
> unfortunately does not have slightest idea what is the allowed list to
> verify against.
> 
> We will not have the same problem in the server (messages.c), because
> server does not have any configuration which would allow to disable
> some authentication algorithms.
> 
>> I think there may be another unrelated security issue in
>> ssh_pki_signature_verify_blob(): When compiling without ECC support
>> and
>> the server sends an unexpected ECDSA signature, it would be imported
>> successfully, "if (key->type == SSH_KEYTYPE_ECDSA)" would be true,
>> but
>> the block does nothing. The function returns rc, which is still 0
>> from
>> the import. Maybe I missed something, but this looks to me like a
>> signature verification bypass. We should return SSH_ERROR if ECC is
>> unsupported.
> 
> I think you are right here. Setting the rc = SSH_ERROR in the else
> branch should fix this problem, but there might be more issues like
> this throughout the code.
> 
> Would you like to submit a patch for these two issues?
> 
> Thanks,
> 

From 463e7cd33561ccbf59570da662ba02fd7279731c Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Tue, 13 Nov 2018 15:45:47 +0100
Subject: [PATCH 1/7] pki: Add hostkey type validation function

Signed-off-by: Tilo Eckert 
---
 include/libssh/pki.h |  1 +
 src/pki.c| 37 +
 2 files changed, 38 insertions(+)

diff --git a/include/libssh/pki.h b/include/libssh/pki.h
index 241cfdd1..af56f11a 100644
--- a/include/libssh/pki.h
+++ b/include/libssh/pki.h
@@ -140,4 +140,5 @@ ssh_public_key ssh_pki_convert_key_to_publickey(const 
ssh_key key);
 ssh_private_key ssh_pki_convert_key_to_privatekey(const ssh_key key);
 
 int ssh_key_algorithm_allowed(ssh_session session, const char *type);
+int ssh_hostkey_algorithm_allowed(ssh_session session, const char *type);
 #endif /* PKI_H_ */
diff --git a/src/pki.c b/src/pki.c
index 623c70f2..232327fa 100644
--- a/src/pki.c
+++ b/src/pki.c
@@ -296,6 +296,43 @@ int ssh_key_algorithm_allowed(ssh_session session, const 
char *type)
 return ssh_match_group(allowed_list, type);
 }
 
+/**
+ * @brief Checks the given host key against the configured allowed
+ * host key algorithm types
+ *
+ * @param[in] session The SSH session
+ * @param[in] typeThe host key algorithm to check
+ * @returns   1 if the host key algorithm is allowed, 0 otherwise
+ */
+int ssh_hostkey_algorithm_allowed(ssh_session session, const char *type)
+{
+const char *allowed_types;
+
+allowed_types = session->opts.wanted_methods[SSH_HOSTKEYS];
+if (allowed_types == NULL) {
+   return 0; /* should never get here */
+}
+
+if (ssh_match_group(allowed_types, type)) {
+return 1;
+}
+if (strcmp(type, "ssh-rsa") == 0) {
+/*
+ * If rsa-sha2 hostkey algo is used, the server returns ssh-rsa as
+ * host key type. Hence, we need to check if one of the rsa-sha2
+ * variants is in the allowed hostkey types list.
+ */
+if (ssh_match_group(allowed_types, "rsa-sha2-256")) {
+return 1;
+}
+if (ssh_match_group(allowed_types, "rsa-sha2-512")) {
+return 1;
+}
+}
+
+return 0;
+}
+
 /**
  * @brief Convert a key type to a hash type. This is usually unambiguous
  * for all the key types, unless the SHA2 extension (RFC 8332) is
-- 
2.18.0

From 29e5a998615b43090b3b72655022bd41a9ae41c2 Mon Sep 17 00:00:00 2001

Re: Bugs when using rsa-sha2 (+patches)

[Tilo Eckert]

Hi Andreas

> Per Jakubs comments, I've pushed 1, 5, 6 and 8. In patch 7 your Sign-Off is 
> missing.
Fixed patch 7 is attached.

> Do you plan to work on the things Jakub pointed out?
Yes, I'm on it.

Regards
Tilo
From 825e96a88c534b4c9e336d16cdc0c766b59cb8db Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Thu, 15 Nov 2018 10:37:30 +0100
Subject: [PATCH 7/8] socket: Add missing braces

Signed-off-by: Tilo Eckert 
---
 src/socket.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/socket.c b/src/socket.c
index 6012c46e..20831185 100644
--- a/src/socket.c
+++ b/src/socket.c
@@ -236,7 +236,7 @@ int ssh_socket_pollcallback(struct ssh_poll_handle_struct 
*p,
 (revents & POLLOUT) ? "POLLOUT ":"",
 (revents & POLLERR) ? "POLLERR":"",
 ssh_buffer_get_len(s->out_buffer));
-if (revents & POLLERR || revents & POLLHUP) {
+if ((revents & POLLERR) || (revents & POLLHUP)) {
 /* Check if we are in a connecting state */
 if (s->state == SSH_SOCKET_CONNECTING) {
 s->state = SSH_SOCKET_ERROR;
-- 
2.18.0

Re: Bugs when using rsa-sha2 (+patches)

[Tilo Eckert]

Hello Jakub

> With your proposed patch, we are basically opening us to the downgrade
> attack (the client request SHA2 signatures, the server sends the SHA1
> signature and it is properly verified and accepted by the client),
> similarly as it worked some time ago in OpenSSH (with client
> authentication):
> 
> https://bugzilla.mindrot.org/show_bug.cgi?id=2799

I see what you mean. However, having to allow sha-rsa alongside rsa-sha2
isn't any better, except that the downgrade attack is more obvious. ;-)

If I understand ssh_pki_signature_verify_blob() correctly, the server
could also perform an upgrade "attack", i.e. send a SHA2 signature when
only ssh-rsa is allowed.

The function ssh_pki_signature_verify_blob() is used by server
(messages.c) and client code (packet_cb.c). So, I think one way to fix
it is to remove the ssh_pki_import_signature_blob() call from
ssh_pki_signature_verify_blob(), move it to the two callers and pass sig
instead of sig_blob to the verify function. That would allow us to check
the signature type in ssh_packet_newkeys() depending on the allowed
hostkey types.

I think there may be another unrelated security issue in
ssh_pki_signature_verify_blob(): When compiling without ECC support and
the server sends an unexpected ECDSA signature, it would be imported
successfully, "if (key->type == SSH_KEYTYPE_ECDSA)" would be true, but
the block does nothing. The function returns rc, which is still 0 from
the import. Maybe I missed something, but this looks to me like a
signature verification bypass. We should return SSH_ERROR if ECC is
unsupported.

Regards
Tilo

Bugs when using rsa-sha2 (+patches)

[Tilo Eckert]

Hi

a series of patches is attached.

There are two bugs when restricting wanted hostkeys to rsa-sha2 through:
> ssh_options_set(session, SSH_OPTIONS_HOSTKEYS, "rsa-sha2-512,rsa-sha2-256");

When connecting to an OpenSSH server that supports rsa-sha2 and the
permitted hostkeys are restricted like above, every connection attempt
resulted in a timeout.

This had two reasons:

1) The hostkey returned by the server does not have the type
"rsa-sha2-512" or "rsa-sha2-256", but "ssh-rsa", which causes the
callback function ssh_packet_newkeys() to incorrectly fail at this line:
> if(!ssh_match_group(session->opts.wanted_methods[SSH_HOSTKEYS], 
> server_key->type_c)) 
A workaround is to use "rsa-sha2-512,rsa-sha2-256,ssh-rsa". However,
this allows falling back to RSA with SHA1 if rsa-sha2 is not supported
by the server, which might not be what the user wants.

2) If ssh_packet_newkeys() fails with SSH_ERROR, this error is not
handled by its caller ssh_packet_process(). The latter only handles
SSH_PACKET_USED and otherwise ignores the packet, causing the poller to
stall until it eventually times out. Additionally, the timeout error
suppressed the real error message.

The attached patches fix both issues, associated tests and some smaller
issues we found during debugging.

There is another occurrence of "return SSH_ERROR;" in the
ssh_packet_newkeys() function. I am not sure, but I think it should be
replaced with "goto error;" as well (+an error message).

I had some trouble testing with "-DCLIENT_TESTING=ON". I'm wondering why
it actually works in the CI builds on Gitlab. All client tests failed
for me because LD_PRELOAD failed. It attempted to load
> /build/tests/libchroot_wrapper.so
instead of
> /build/lib/libchroot_wrapper.so
where the library is actually located.

I ended up changing this line in libssh/tests/CMakeLists.txt:
> set(CHROOT_WRAPPER_LIBRARY 
> ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}chroot_wrapper${CMAKE_SHARED_LIBRARY_SUFFIX})
to
> set(CHROOT_WRAPPER_LIBRARY 
> ${CMAKE_CURRENT_BINARY_DIR}/../lib/${CMAKE_SHARED_LIBRARY_PREFIX}chroot_wrapper${CMAKE_SHARED_LIBRARY_SUFFIX})
to get client tests to work. Any idea why I had to make that change and
why Gitlab CI tests work without it?

Regards,
Tilo
From 21d6f4d22f8bc914a815e9e5315e4da0944f5cda Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Tue, 13 Nov 2018 12:21:53 +0100
Subject: [PATCH 1/8] packet: Fix timeout on hostkey type mismatch instead of
 proper error

If the hostkey type was not in the list of acceptable hostkey
types, the function failed to set the error state. Due to the
fact that the calling function ssh_packet_process() does not
handle the SSH_ERROR return code, the newkeys packet from the
server was silently ignored, stalling the connection until a
timeout occurred.

Signed-off-by: Tilo Eckert 
---
 src/packet_cb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/packet_cb.c b/src/packet_cb.c
index dc883244..af5b966c 100644
--- a/src/packet_cb.c
+++ b/src/packet_cb.c
@@ -198,7 +198,7 @@ SSH_PACKET_CALLBACK(ssh_packet_newkeys){
   "preference (%s)",
   server_key->type_c,
   session->opts.wanted_methods[SSH_HOSTKEYS]);
-return -1;
+        goto error;
 }
 }
 
-- 
2.18.0

From 6ded3a15153b683a8f54df1df4222eb17ae8a20e Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Tue, 13 Nov 2018 15:45:47 +0100
Subject: [PATCH 2/8] pki: Add hostkey type validation function

Signed-off-by: Tilo Eckert 
---
 include/libssh/pki.h |  1 +
 src/pki.c| 37 +
 2 files changed, 38 insertions(+)

diff --git a/include/libssh/pki.h b/include/libssh/pki.h
index 241cfdd1..af56f11a 100644
--- a/include/libssh/pki.h
+++ b/include/libssh/pki.h
@@ -140,4 +140,5 @@ ssh_public_key ssh_pki_convert_key_to_publickey(const 
ssh_key key);
 ssh_private_key ssh_pki_convert_key_to_privatekey(const ssh_key key);
 
 int ssh_key_algorithm_allowed(ssh_session session, const char *type);
+int ssh_hostkey_algorithm_allowed(ssh_session session, const char *type);
 #endif /* PKI_H_ */
diff --git a/src/pki.c b/src/pki.c
index d420e792..8fe39532 100644
--- a/src/pki.c
+++ b/src/pki.c
@@ -295,6 +295,43 @@ int ssh_key_algorithm_allowed(ssh_session session, const 
char *type)
 return ssh_match_group(allowed_list, type);
 }
 
+/**
+ * @brief Checks the given host key against the configured allowed
+ * host key algorithm types
+ *
+ * @param[in] session The SSH session
+ * @param[in] typeThe host key algorithm to check
+ * @returns   1 if the host key algorithm is allowed, 0 otherwise
+ */
+int ssh_hostkey_algorithm_allowed(ssh_session session, const char *type)
+{
+const char *allowed_types;
+
+allowed_types = session->opts.wanted_methods[SSH_HOSTKEY

Patch: Invalid read while parsing known_hosts

[Tilo Eckert]

Hi,

two patches are attached.

The first one fixes an invalid read when parsing lines from the
known_hosts file, which was introduced by commit 21962d. The bug causes
host keys sent by the server to be randomly rejected. For the average
known_hosts line, the tokens array in ssh_get_knownhost_line() contains
four tokens, with tokens[3]=NULL. However, tokens[4] is accessed for
token validation, which is beyond the end of the tokens array, resulting
in valid host lines being dropped randomly.

The patch completely removes the related check because the optional
comment field may contain whitespace which would result in an arbitrary
number of tokens. Hence, token count >= 3 implies a correctly formatted
known_hosts line.

The other patch fixes a type re-declaration issue which causes errors on
some compilers.

Regards
Tilo Eckert
From 51e6d99d53473e5b6c50a04290684d0970c8c1d6 Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Fri, 12 Oct 2018 15:15:00 +0200
Subject: [PATCH 1/2] knownhosts: Fix invalid read of known_hosts token

Fixes invalid read introduced by commit 21962d.
Accessing tokens[4] for a known_hosts line of
three tokens led to randomly rejected host keys.

This commit completely removes the check because
the optional comments field may contain whitespace.

Signed-off-by: Tilo Eckert 
---
 src/known_hosts.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/known_hosts.c b/src/known_hosts.c
index f52f74b3..407e1de5 100644
--- a/src/known_hosts.c
+++ b/src/known_hosts.c
@@ -131,17 +131,13 @@ static char **ssh_get_knownhost_line(FILE **file, const 
char *filename,
   return NULL;
 }
 
-if(!tokens[0] || !tokens[1] || !tokens[2]) {
+if(tokens[0] == NULL || tokens[1] == NULL || tokens[2] == NULL) {
   /* it should have at least 3 tokens */
   tokens_free(tokens);
   continue;
 }
 
 *found_type = tokens[1];
-if (tokens[3] || tokens[4]) {
-  tokens_free(tokens);
-  continue;
-}
 
 return tokens;
   }
-- 
2.18.0

From 0fc8625fe5fbfe3532f3277baadd7a1ae4693ebe Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Fri, 12 Oct 2018 15:22:45 +0200
Subject: [PATCH 2/2] chacha: remove re-declared type

re-declaring typedefs are not supported by some compilers

Signed-off-by: Tilo Eckert 
---
 src/external/chacha.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/external/chacha.c b/src/external/chacha.c
index e47a6328..8d1ccca6 100644
--- a/src/external/chacha.c
+++ b/src/external/chacha.c
@@ -10,8 +10,6 @@ Public domain.
 
 #include "libssh/chacha.h"
 
-typedef unsigned int uint32_t;
-
 typedef struct chacha_ctx chacha_ctx;
 
 #define U8C(v) (v##U)
-- 
2.18.0

libssh no longer compiles on Solaris

[Tilo Eckert]

Hi,

after upgrading libssh to the 0.8 branch, I can no longer compile libssh
on Solaris.

The function local_parse_glob() introduced by commit 99c5160 is not
portable because GLOB_TILDE and the gl_flags field in the glob_t
structure are both non-standard extensions. POSIX does not specify tilde
expansion for glob().

So, unless someone is willing to make that function portable, I propose
to revert commits 99c5160, b8e301a and a82e24f.

Regards
Tilo Eckert

Re: libssh windows problem

[Tilo Eckert]

The INSTALL file has instructions.

Am 04.10.2018 um 13:58 schrieb Łukasz Oleński:
> Hot to compile libssh yourself?
> 
> 
> Pozdrawiam,
> ---
> Łukasz Oleński
> FORCA: System Administrator Manager
>  
> Telefon: +48 799 799 788
> E-mail: lolen...@forca.pl
>  
> 
> Adres: ul. Lutycka 6/116A, 44-100 Gliwice
> Strona: www.forca.pl
> NIP: 6351648511
> REGON: 240621874
> 
> -Original Message-
> From: Tilo Eckert  
> Sent: Thursday, October 4, 2018 11:57 AM
> To: libssh@libssh.org
> Subject: Re: libssh windows problem
> 
> That is most likely a webserver misconfiguration. Opening 
> https://red.libssh.org yields SSL_ERROR_BAD_CERT_DOMAIN. The site returns the 
> certificate and content of milliways.cryptomilk.org instead of red.libssh.org.
> 
> You can only wait for Andreas to fix it or compile libssh yourself.
> 
> Am 03.10.2018 um 21:23 schrieb Łukasz Oleński:
>> Hello,
>>
>>  
>>
>> I can not download libssh for Windows. Page dont work. Error 404. I 
>> want download libssh-0.7.2.msvc.zip
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>> Pozdrawiam,
>>
>> ---
>>
>> *Łukasz Oleński*
>>
>> *FORCA:*System Administrator Manager
>>
>>  
>>
>> *Telefon:* +48 799 799 788
>> *E-mail:* lolen...@forca.pl <mailto:lolen...@forca.pl>
>>
>>  
>>
>> *Adres:* ul. Lutycka 6/116A, 44-100 Gliwice
>>
>> *Strona:* www.forca.pl <http://www.forca.pl/>
>>
>> *NIP:* 6351648511
>>
>> *REGON:* 240621874
>>
>>  
>>
> 
> 
> 

Re: libssh windows problem

[Tilo Eckert]

That is most likely a webserver misconfiguration. Opening
https://red.libssh.org yields SSL_ERROR_BAD_CERT_DOMAIN. The site
returns the certificate and content of milliways.cryptomilk.org instead
of red.libssh.org.

You can only wait for Andreas to fix it or compile libssh yourself.

Am 03.10.2018 um 21:23 schrieb Łukasz Oleński:
> Hello,
> 
>  
> 
> I can not download libssh for Windows. Page dont work. Error 404. I want
> download libssh-0.7.2.msvc.zip
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> Pozdrawiam,
> 
> ---
> 
> *Łukasz Oleński*
> 
> *FORCA:*System Administrator Manager
> 
>  
> 
> *Telefon:* +48 799 799 788
> *E-mail:* lolen...@forca.pl 
> 
>  
> 
> *Adres:* ul. Lutycka 6/116A, 44-100 Gliwice
> 
> *Strona:* www.forca.pl 
> 
> *NIP:* 6351648511
> 
> *REGON:* 240621874
> 
>  
> 

Re: ssh-client example broken

[Tilo Eckert]

Am 16.08.2018 um 18:51 schrieb Andreas Schneider:
> On Thursday, 16 August 2018 18:11:46 CEST Tilo Eckert wrote:
>> Hi,
>>
>> today I compiled the examples shipped with libssh (current master) for
>> the first time and tried to use the "ssh-client" example, but it seems
>> to be broken.
>>
>> When I connect to an OpenSSH server in interactive shell mode (i.e.
>> ssh-client user@host), the client successfully connects and
>> authenticates, but it does not print any output. Keyboard input does not
>> work either. Once connected, the client does not react to Ctrl+C, so
>> that I have to kill -9 it. When I pass a command as last parameter to
>> run in batch mode, it does not print anything either, does not
>> terminate, but reacts to Ctrl+C.
>>
>> The problem lies in the select_loop() function. I suppose its intention
>> is to connect local stdin, stdout and stderr with its remote
>> counterparts? The ssh_event_dopoll() function is repeatedly called every
>> 60 seconds when it times out or when I press a key, but it seems to do
>> nothing.
>>
>> With an older version from last year, at least the motd from the server
>> gets printed after connecting in interactive mode, but then it gets
>> stuck as well. No shell prompt, no input possible, no Ctrl+C. So it
>> seems to be broken for a while.
> 
> 
> WORKSFORME:
> 
> ./examples/ssh-client asn@krikkit
> Activate the web console with: systemctl enable --now cockpit.socket
> 
> Last login: Thu Aug 16 18:50:07 2018 from 2001:a62:160e:
> 4a01:a935:c919:b383:fa79
> 
> Welcome to krikkit. Load: 0.15 0.09 0.08 3/823 24405
> 
> asn@krikkit:~> ls workspace/projects/libssh
> AUTHORSCTestConfig.cmake  README  cmake   
> doc  libssh-config.cmake.in  src
> BSDChangeLog  README.CodingStyle  config.h.cmake  
> examples libssh.pc.cmake tags
> CMakeLists.txt ConfigureChecks.cmake  README.mbedtls  cscope.in.out   
> include  obj tests
> COPYINGDefineOptions.cmakeREADME.md   cscope.out  
> libssh-build-tree-settings.cmake.in  obj-gcrypt
> CPackConfig.cmake  INSTALLSubmittingPatches   cscope.po.out   
> libssh-config-version.cmake.in   obj-mbedcrypto
> asn@krikkit:~> logout
> 
> 
> 
> I dunno what is wrong on your side ...
> 

I do.

I modified timeout handling in ssh_handle_packets_termination() in my
local copy two years ago because I ran into code paths where, even
though a timeout was configured, ssh_handle_packets_termination() would
block with an infinite timeout, resulting in stalled connections. My
code change fixed that issue, but obviously created another one. I guess
I did not submit my solution as a patch because I knew it wasn't proper
code. Time for re-evaluation... :P

Regards
Tilo

ssh-client example broken

[Tilo Eckert]

Hi,

today I compiled the examples shipped with libssh (current master) for
the first time and tried to use the "ssh-client" example, but it seems
to be broken.

When I connect to an OpenSSH server in interactive shell mode (i.e.
ssh-client user@host), the client successfully connects and
authenticates, but it does not print any output. Keyboard input does not
work either. Once connected, the client does not react to Ctrl+C, so
that I have to kill -9 it. When I pass a command as last parameter to
run in batch mode, it does not print anything either, does not
terminate, but reacts to Ctrl+C.

The problem lies in the select_loop() function. I suppose its intention
is to connect local stdin, stdout and stderr with its remote
counterparts? The ssh_event_dopoll() function is repeatedly called every
60 seconds when it times out or when I press a key, but it seems to do
nothing.

With an older version from last year, at least the motd from the server
gets printed after connecting in interactive mode, but then it gets
stuck as well. No shell prompt, no input possible, no Ctrl+C. So it
seems to be broken for a while.

Regards
Tilo

Re: Transfer a file from a remote to another one

[Tilo Eckert]

Neither SCP nor SFTP have inherent support for (FXP-like) direct file
transfers between two remote hosts. You always have to SSH into one of
the boxes and initiate the transfer from the remote box by running the
necessary command.

scp nick0@x.x.x.x:file nick1@y.y.y.y:newfile
is equivalent to
ssh nick0@x.x.x.x "scp file nick1@y.y.y.y:newfile"

Regards
Tilo

Am 02.08.2018 um 16:13 schrieb Ahmad Modaghegh:
> As mentioned in documentation (tuts), by using SCP and SFTP, It is
> possible to transfer a set of *LOCAL* file (or directories) through a
> secure SSH connection. But is it possible to transfer Files located on a
> public remote to another one?
> 
> Let's say there is host (serving sshd): x.x.x.x:22 and there is another
> one: y.y.y.y:22 (both on different machines). Now is it possible to
> transfer a file from the first one to another one using lib APIs
> directly (by sending the command from a third-machine)? I'm sure it is
> possible natively on ssh (CLI) as below:
> 
> scp nick0@x.x.x.x:file nick1@y.y.y.y:newfile
> 
> Thanks in advance.
> 
> 

Re: custom library path for libcrypto(openssl)

[Tilo Eckert]

Hi Arul,

you can simply adjust the PATH environment variable by prepending the
path to your libcrypto.so before calling cmake, e.g.:
PATH=${OPENSSLDIR}/lib/:$PATH

Regards
Tilo

Am 01.08.2018 um 11:14 schrieb Arul Prakash Selvakumar:
> Hi,
> 
>  
> 
> I’m trying to build the libssh library (0.6.5). While building the
> ‘libcrypto.so’ library is always picked up from /usr/lib64. I want to
> override that with a custom path to look for that library. I have never
> used CMake before, so I’m not sure how to do that. I tried few things in
> Cmakelists.txt but it didn’t work. Is there a way to achieve this?
> 
>  
> 
> Thanks,
> 
> -Arul
> 
>  
> 
> 
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and destroy all
> copies of the original message.
> 

Re: How to use Kex diffie-hellman-group-exchange-sha256 ?

[Tilo Eckert]

This kex is not supported, only those listed in your log output.

Am 27.06.2018 um 08:57 schrieb Antenore Gatta:
> Hi all,
> 
> I'm trying to connect to a host using the Kex
> diffie-hellman-group-exchange-sha256 , but even if I force the Kex, I
> got this trace:
> 
>> [SSH] ssh_kex_select_methods: kex error : no match for method kex
>> algos: server [diffie-hellman-group-exchange-sha256], client
>> [curve25519-sha...@libssh.org,ecdh-sha2-nistp256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1]
>> [SSH] ssh_connect: current state : 9
> 
> In fact the diffie-hellman-group-exchange-sha256 kex is nopt
> recognized:
> 
>> [SSH] SSH_OPTIONS_KEY_EXCHANGE does not have a valid value:
>> diffie-hellman-group-exchange-sha256 
> 
> Is there any special flag to enable
> diffie-hellman-group-exchange-sha256 at compile time? 
> 
> At the moment libssh, in our flatpak, is compiled with:
> 
>> -DCMAKE_BUILD_TYPE:STRING=Release
>> -DWITH_NACL:BOOL=ON
>> -DNACL_INCLUDE_DIR:PATH=/app/include/
>> -DNACL_LIBRARY:PATH=/app/lib/nacl/libnacl.a
>> -DWITH_EXAMPLES:BOOL=OFF
> 
> 
> Thanks in advance!!!
> 
> Best regards
> 
> Antenore
> 

Patch: add curve25519-sha256 alias (was: Removing DSS and other unreasonable algorithms)

[Tilo Eckert]

A series of patches is attached that adds the curve25519-sha256 kex algo
as an alias to its private counterpart curve25519-sha...@libssh.org and
adds some tests (there weren't any client tests).

I had some trouble getting the client tests to work. There was no hint
in the docs that WITH_CLIENT_TESTING needs to be enabled and that some
wrapper libraries are required to get them to work. I added a paragraph
to the INSTALL file and also updated all links therein.

Regards
Tilo

Am 22.06.2018 um 13:51 schrieb Andreas Schneider:
> Could you prepare a patch for adding curve25519-sha256 as an alias and add a 
> test in torture_algorithms for that?

From 76256475f27e6435fcd2b3d11ca0d39c60755459 Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Mon, 25 Jun 2018 13:01:57 +0200
Subject: [PATCH 1/6] kex: add curve25519-sha256 as alias for
 curve25519-sha...@libssh.org

see: https://tools.ietf.org/id/draft-ietf-curdle-ssh-curves-07.html

Signed-off-by: Tilo Eckert 
---
 doc/mainpage.dox| 2 +-
 include/libssh/crypto.h | 4 +++-
 src/client.c| 1 +
 src/curve25519.c| 4 ++--
 src/dh.c| 4 +++-
 src/kex.c   | 4 +++-
 src/packet_cb.c | 1 +
 src/server.c| 1 +
 src/session.c   | 2 ++
 9 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/doc/mainpage.dox b/doc/mainpage.dox
index 1b86baa9..a65caf9b 100644
--- a/doc/mainpage.dox
+++ b/doc/mainpage.dox
@@ -19,7 +19,7 @@ the interesting functions as you go.
 
 The libssh library provides:
 
- - Key Exchange Methods: curve25519-sha...@libssh.org, 
ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, 
diffie-hellman-group1-sha1, diffie-hellman-group14-sha1
+ - Key Exchange Methods: curve25519-sha256, 
curve25519-sha...@libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, 
ecdh-sha2-nistp521, diffie-hellman-group1-sha1, diffie-hellman-group14-sha1
  - Hostkey Types: ssh-ed25519, ecdsa-sha2-nistp256, 
ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, ssh-dss, ssh-rsa
  - Ciphers: aes256-ctr, aes192-ctr, aes128-ctr, 
aes256-cbc (rijndael-...@lysator.liu.se), aes192-cbc, aes128-cbc, 3des-cbc, 
blowfish-cbc, none
  - Compression Schemes: zlib, z...@openssh.com, none
diff --git a/include/libssh/crypto.h b/include/libssh/crypto.h
index fab39ed1..2e62d5ce 100644
--- a/include/libssh/crypto.h
+++ b/include/libssh/crypto.h
@@ -60,7 +60,9 @@ enum ssh_key_exchange_e {
   /* ecdh-sha2-nistp521 */
   SSH_KEX_ECDH_SHA2_NISTP521,
   /* curve25519-sha...@libssh.org */
-  SSH_KEX_CURVE25519_SHA256_LIBSSH_ORG
+  SSH_KEX_CURVE25519_SHA256_LIBSSH_ORG,
+  /* curve25519-sha256 */
+  SSH_KEX_CURVE25519_SHA256
 };
 
 enum ssh_cipher_e {
diff --git a/src/client.c b/src/client.c
index 5a554647..e0b8d102 100644
--- a/src/client.c
+++ b/src/client.c
@@ -266,6 +266,7 @@ static int dh_handshake(ssh_session session) {
   break;
 #endif
 #ifdef HAVE_CURVE25519
+case SSH_KEX_CURVE25519_SHA256:
 case SSH_KEX_CURVE25519_SHA256_LIBSSH_ORG:
   rc = ssh_client_curve25519_init(session);
   break;
diff --git a/src/curve25519.c b/src/curve25519.c
index 8e08f512..42b3b64e 100644
--- a/src/curve25519.c
+++ b/src/curve25519.c
@@ -1,6 +1,6 @@
 /*
  * curve25519.c - Curve25519 ECDH functions for key exchange
- * curve25519-sha...@libssh.org
+ * curve25519-sha...@libssh.org and curve25519-sha256
  *
  * This file is part of the SSH Library
  *
@@ -40,7 +40,7 @@
 #include "libssh/bignum.h"
 
 /** @internal
- * @brief Starts curve25519-sha...@libssh.org key exchange
+ * @brief Starts curve25519-sha...@libssh.org / curve25519-sha256 key exchange
  */
 int ssh_client_curve25519_init(ssh_session session){
   int rc;
diff --git a/src/dh.c b/src/dh.c
index d2ddfabd..0d9b1ebe 100644
--- a/src/dh.c
+++ b/src/dh.c
@@ -682,7 +682,8 @@ int ssh_make_sessionid(ssh_session session) {
 }
 #endif
 #ifdef HAVE_CURVE25519
-} else if (session->next_crypto->kex_type == 
SSH_KEX_CURVE25519_SHA256_LIBSSH_ORG) {
+} else if ((session->next_crypto->kex_type == SSH_KEX_CURVE25519_SHA256) ||
+   (session->next_crypto->kex_type == 
SSH_KEX_CURVE25519_SHA256_LIBSSH_ORG)) {
 rc = ssh_buffer_pack(buf,
  "dPdP",
  CURVE25519_PUBKEY_SIZE,
@@ -718,6 +719,7 @@ int ssh_make_sessionid(ssh_session session) {
session->next_crypto->secret_hash);
 break;
 case SSH_KEX_ECDH_SHA2_NISTP256:
+case SSH_KEX_CURVE25519_SHA256:
 case SSH_KEX_CURVE25519_SHA256_LIBSSH_ORG:
 session->next_crypto->digest_len = SHA256_DIGEST_LENGTH;
 session->next_crypto->mac_type = SSH_MAC_SHA256;
diff --git a/src/kex.c b/src/kex.c
index b658ed44..441fe23a 100644
--- a/src/kex.c
+++ b/src/kex.c
@@ -78,7 +78,7 @@
 #endif
 
 #ifdef HAVE_CURVE25519
-#define CURVE25519 "curve25519-sha...@libssh.org,"
+#define CURVE25519 "curv

Re: Removing DSS and other unreasonable algorithms (Was: Missing signed-off for pkg chacha20 patches)

[Tilo Eckert]

Am 20.06.2018 um 15:12 schrieb Andreas Schneider:
> On Tuesday, 19 June 2018 16:35:49 CEST Jakub Jelen wrote:
>> On Thu, 2018-06-14 at 16:03 +0200, Andreas Schneider wrote:
>>> [...]
>>>
>>> Looks like openssh removed support for ssh-dss. At least my openssh
>>> 7.7
>>> doesn't know about it at all.
>>
>> The OpenSSH 7.7p1 still has the support for ssh-dss keys, but they are
>> disabled by default for any use, unless you enable them using
>> PubkeyAcceptedKeyTypes and friend configuration options. The reason why
>> it is still there is probably because the DSA keys are mandatory part
>> (REQUIRED) of RFC4253 (Section 6.6).
>>
>>> I would remove it from libssh after the release of 0.8 together with
>>> SSHv1
>>> support.
>>>
>>> I think we can remove it from pkd already? Comments?
>>
>> Removing the ancient SSHv1, blowfish and other unreasonable algorithms
>> makes sense for me.
> 
> SSHv1 will be removed, the algorithms will not be compiled in by default but 
> still available.
> 
> This should not affect connecting to RHEL5 as it support and uses rsa keys by 
> default.
> 
> 
>   Andreas
> 

If we are already tidying up:

I suggest to also deprecate the insecure diffie-hellman-group1-sha1 kex
algorithm [1] which is currently compiled in by default.

Instead, maybe we should add curve25519-sha256 as an alias to the
curve25519-sha...@libssh.org kex as Aris' proposal is in the IETF
standardization process [2] and OpenSSH has already adopted it in
September 2016.

[1] https://tools.ietf.org/id/draft-ietf-curdle-ssh-kex-sha2-10.html
[2] https://tools.ietf.org/id/draft-ietf-curdle-ssh-curves-07.html

Regards
Tilo

Bug in ed25519 implementation

[Tilo Eckert]

Hi

We discovered a compiler-dependent bug in the ed25519 implementation
that took us two days to find, but is trivial to fix. With one of our
compilers, if the server provided an ed25519 key, signature verification
failed.

The issue is the global variable at include/libssh/ge25519.h:31
> const ge25519 ge25519_base;
and is fixed by adding the extern keyword:
> extern const ge25519 ge25519_base;
(I did not bother creating a patch for this trivial change. ;-))

Explanation:
The global variable "ge25519_base" is referenced in the module
"src/external/ed25519.c" and initialized in "src/external/ge25519.c".
The lack of the extern keyword in the header results in different
instances being compiled into both translation units if compiled with a
standard-compliant compiler (XLC in our case). The instance in
"ge25519.o" is properly initialized, but the one in "ed25519.o" is
zeroed out. As a result, the zeroed version from "ed25519.o" is used to
attempt to verify the server's signature which obviously fails.

GCC and clang support a GNU extension for variables in global scope that
lack the extern keyword and which are not initialized within the
translation unit. If the linker finds an initialized version in another
translation unit, it is used, the zeroed version otherwise. In other
words, the extern keyword is implied by compilers implementing this
extension, which you obviously cannot rely on on non-GNU compilers.

This issue has already been fixed a while ago in OpenSSH and other projects.

Regards
Tilo

Re: Socket error: disconnected, Socket error: No error

[Tilo Eckert]

Hi Yanis

the server obviously disconnects you after two failed login attempts
(ssh_userauth_none and ssh_userauth_password). Since you do not perform
any kind of error checking, you blindly continue with
ssh_userauth_kbdint which also fails because you are already
disconnected at this point ("Socket error: No error").

Calling ssh_userauth_none is normally used to fetch the list of
authentication methods supported by the server if you don't know them
beforehand. This list can be retrieved with ssh_userauth_list
afterwards. You should only attempt authentication methods which are in
this list (i.e. enabled on the server side).

Have a look at the authentication tutorial and the functions' return
codes to see how to properly deal with errors (checking for
!=SSH_AUTH_SUCCESS is not sufficient):
http://api.libssh.org/master/libssh_tutor_authentication.html

Regards,
Tilo

Am 26.09.2017 um 18:12 schrieb Yanis Kurganov:
> Hi!
> 
> I got a strange libssh error.
> 
> if (ssh_userauth_none(m_Session, nullptr) != SSH_AUTH_SUCCESS)
> {
> if (ssh_userauth_password(m_Session, nullptr,
> m_Settings->Password().c_str()) != SSH_AUTH_SUCCESS)
>   {
>   while ((code = ssh_userauth_kbdint(m_Session, nullptr, nullptr))
> == SSH_AUTH_INFO)
>   .
>   }
> }
> 
> ssh_connect: libssh 0.7.5 (c) 2003-2014 Aris Adamantiadis, Andreas
> Schneider, and libssh contributors. Distributed under the LGPL, please
> refer to COPYING file for information about your rights, using threading
> threads_noop
> getai: host 10.67.41.242 matches an IP address
> ssh_socket_connect: Nonblocking connection socket: 1336
> ssh_connect: Socket connecting, now waiting for the callbacks to work
> ssh_connect: Actual timeout : 6
> ssh_socket_pollcallback: Received POLLOUT in connecting state
> socket_callback_connected: Socket connection callback: 1 (0)
> callback_receive_banner: Received banner:
> SSH-2.0-OpenSSH_7.3p1+sftpfilecontrol-v1.3-hpn14v11
> ssh_client_connection_callback: SSH server banner:
> SSH-2.0-OpenSSH_7.3p1+sftpfilecontrol-v1.3-hpn14v11
> ssh_analyze_banner: Analyzing banner:
> SSH-2.0-OpenSSH_7.3p1+sftpfilecontrol-v1.3-hpn14v11
> ssh_analyze_banner: We are talking to an OpenSSH client version: 7.3 (70300)
> ssh_socket_unbuffered_write: Enabling POLLOUT for socket
> ssh_packet_socket_callback: packet: read type 20
> [len=988,padding=4,comp=983,payload=983]
> ssh_packet_process: Dispatching handler for packet type 20
> ssh_list_kex: kex algos: curve25519-sha...@libssh.org
> ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
> ssh_list_kex: server host key algo:
> ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
> ssh_list_kex: encryption client->server:
> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
> ssh_list_kex: encryption server->client:
> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
> ssh_list_kex: mac algo client->server: umac-64-...@openssh.com
> ,umac-128-...@openssh.com
> ,hmac-sha2-256-...@openssh.com
> ,hmac-sha2-512-...@openssh.com
> ,hmac-sha1-...@openssh.com
> ,umac...@openssh.com
> ,umac-...@openssh.com
> ,hmac-sha2-256,hmac-sha2-512,hmac-sha1
> ssh_list_kex: mac algo server->client: umac-64-...@openssh.com
> ,umac-128-...@openssh.com
> ,hmac-sha2-256-...@openssh.com
> ,hmac-sha2-512-...@openssh.com
> ,hmac-sha1-...@openssh.com
> ,umac...@openssh.com
> ,umac-...@openssh.com
> ,hmac-sha2-256,hmac-sha2-512,hmac-sha1
> ssh_list_kex: compression algo client->server: none,z...@openssh.com
> 
> ssh_list_kex: compression algo server->client: none,z...@openssh.com
> 
> ssh_list_kex: languages client->server: 
> ssh_list_kex: languages server->client: 
> ssh_list_kex: kex algos: curve25519-sha...@libssh.org
> ,ecdh-sha2-nistp256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> ssh_list_kex: server host key algo:
> ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
> ssh_list_kex: encryption client->server:
> aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc
> ssh_list_kex: encryption server->client:
> aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,3des-cbc
> ssh_list_kex: mac algo client->server: h

Re: about issue 223

[Tilo Eckert]

This post explains it better than I could:
https://opensource.stackexchange.com/questions/4804/modifying-an-lgpl-library-and-using-it-in-a-commercial-product/4806#4806

Regards
Tilo

Am 11.09.2017 um 11:23 schrieb 312:
> Hi All,
> 
> It seems that  https://red.libssh.org/issues/223  is pending for eight
> month.
> Because libssh is LGPL license, I want to know if it's ok to include
> this patch into some proprietary product.
> 
> Best Regards
> Jackson Zheng
> 
> 
> 
>  
> 
> 
> 
>  
> 

Re: I use VS2010 invoking libssh.lib and a number of errors have occurred

[Tilo Eckert]

Hi,

your error is somewhere in Microsoft's C Runtime. Since you did not
provide a stack trace, it is impossible to tell what goes wrong. Fire up
your debugger to find out where you get stuck.

PS: Most people on the mailing list are not fluent in Chinese. ;)

Regards
Tilo

Am 30.07.2017 um 12:18 schrieb 马行:
>  I use the VS development environment call libssh.lib
> 
> #include "stdafx.h"
> #include 
> #define SSH_NO_CPP_EXCEPTIONS
> #include 
> 
> using namespace System;
> 
> int main(array ^args)
> {
> ssh_init();
> return 0;
> }
> 
> When the program runs to ssh_init(), i get an error in  "\Microsoft
> Visual Studio 10.0\VC\crt\src\mcrtexe.cpp" .
> 
> 
> 
> I'm not proficient with C++,Please help me,Thanks!

Re: Compiling problem on AIX

[Tilo Eckert]

Hi Robin,

we compile libssh for z/OS / USS and AIX. On AIX, we use gcc. So I
cannot help you regarding xlc on AIX specifically. However, we use a
custom makefile and c99 (xlc) to compile libssh on z/OS and USS.

Here is an example call for compiling on USS:
> c99 -q32 -Wc,goff -Wc,dll -qexportall -qarch=8 -qtune=10 -qtarget=zOSV1R13 
> -D_XOPEN_SOURCE=600 -DLIBSSH_EXPORTS -D_LARGEFILE64_SOURCE -DNI_MAXHOST=1025 
> -O3 -DNDEBUG -D__EBCDIC__ -Ilibssh/include -Ibin/ussz31/openssl/include -o 
> build/ussz31/libssh/messages.o -c libssh/src/messages.c

I think, the xlc executable expects C89 source code by default, which
explains your issue with double slash comments. libssh requires C99.

Regards,
Tilo

Am 19.07.2017 um 12:47 schrieb Robin Geffroy:
> Hi,
> 
> I work with libssh, and I have to make it work with a lot of different
> OSes. On Windows / Linux, no problem. But here I am on AIX, and I am
> unable to make it work :(
> 
> I have to use the xlc compiler (XL 12.1.0 here). I got some errors with
> the C++-style comment in some files, easy to solve, but then another
> error appeared when trying to "make" :
> 
> "/path/to/openssl/openssl-1.0.2k/include/openssl/crypto.h", line 502.44:
> 1506-275 (S) Unexpected text free_func encountered.
> "/path/to/openssl/openssl-1.0.2k/include/openssl/crypto.h", line 507.47:
> 1506-275 (S) Unexpected text free_func encountered.
> "/path/to/openssl/openssl-1.0.2k/include/openssl/asn1.h", line 909.46:
> 1506-275 (S) Unexpected text free_func encountered.
> "/path/to/openssl/openssl-1.0.2k/include/openssl/asn1.h", line 1063.49:
> 1506-275 (S) Unexpected text free_func encountered.
> "/path/to/openssl/openssl-1.0.2k/include/openssl/objects.h", line
> 996.31: 1506-275 (S) Unexpected text free_func encountered.
> "/path/to/openssl/openssl-1.0.2k/include/openssl/ec.h", line 842.41:
> 1506-275 (S) Unexpected text free_func encountered.
> "/path/to/openssl/openssl-1.0.2k/include/openssl/ec.h", line 854.44:
> 1506-275 (S) Unexpected text free_func encountered.
> make: The error code from the last command is 1.
> 
> 
> Stop.
> make: The error code from the last command is 2.
> 
> 
> Stop.
> make: The error code from the last command is 2.
> 
> 
> Do you have any idea what can I do ? I don't know what's happening here.
> I tried with or without CFLAGS, and nothing seems to work. I use OpenSSL
> with other projects, and I got no problem with it...
> 
> Regards,
> 
> Robin

Re: Issue accessing https://git.libssh.org

[Tilo Eckert]

Am 29.06.2017 um 12:46 schrieb Andreas Schneider:
> On Thursday, 29 June 2017 10:54:12 CEST Tilo Eckert wrote:
>> Am 28.06.2017 um 18:05 schrieb Andreas Schneider:
>>> On Wednesday, 28 June 2017 15:40:00 CEST Tilo Eckert wrote:
>>>> Am 28.06.2017 um 13:42 schrieb Andreas Schneider:
>>>>> On Wednesday, 28 June 2017 12:43:14 CEST Tilo Eckert wrote:
>>>>>> Hi,
>>>>>
>>>>> Hi Tilo,
>>>>>
>>>>>> I am experiencing a re-occuring issue when accessing
>>>>>> https://git.libssh.org with Firefox. When requesting a page for the
>>>>>> first time after browser startup or after not accessing the site for a
>>>>>> while, I get an SSL error page with the error code
>>>>>> NS_ERROR_NET_INADEQUATE_SECURITY.
>>>>>>
>>>>>> Refreshing the page causes it to load successfully and I can navigate
>>>>>> the site. When idling on one page for a couple of minutes, the issue
>>>>>> reappears on the next page request.
>>>>>>
>>>>>> If the server is configured for HTTPS2, this post might be relevant:
>>>>>> https://support.mozilla.org/en-US/questions/1139019
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Please retry.
>>>>
>>>> The issue still persists. I think the reason is that the cipher suite
>>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA is negotiated which is blacklisted in
>>>> HTTP/2. Firefox probably falls back to HTTP/1.1 when negotiation failed
>>>> for a recent previous request.
>>>
>>> Strange, I used the SSLCipherSuite line from
>>> https://icing.github.io/mod_h2/ howto.html
>>>
>>> I don't see the issue with Firefox 52.0.2
>>
>> This SSLCipherSuite?
>>
>>> SSLCipherSuite
>>> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES25
>>> 6-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-D
>>> SS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES12
>>> 8-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA3
>>> 84:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:D
>>> HE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES2
>>> 56-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES
>>> :!RC4:!3DES:!MD5:!PSK
> 
> Yes, that's the one.
> 
>> It looks like you either did not specify "SSLHonorCipherOrder on" or
>> your SSLCipherSuite declaration is not used for some reason.
> 
> That's set too.
> 
> 
> However I think I found it.

I can confirm it as fixed. :)

Thanks.

Re: Issue accessing https://git.libssh.org

[Tilo Eckert]

Am 28.06.2017 um 18:05 schrieb Andreas Schneider:
> On Wednesday, 28 June 2017 15:40:00 CEST Tilo Eckert wrote:
>> Am 28.06.2017 um 13:42 schrieb Andreas Schneider:
>>> On Wednesday, 28 June 2017 12:43:14 CEST Tilo Eckert wrote:
>>>> Hi,
>>>
>>> Hi Tilo,
>>>
>>>> I am experiencing a re-occuring issue when accessing
>>>> https://git.libssh.org with Firefox. When requesting a page for the
>>>> first time after browser startup or after not accessing the site for a
>>>> while, I get an SSL error page with the error code
>>>> NS_ERROR_NET_INADEQUATE_SECURITY.
>>>>
>>>> Refreshing the page causes it to load successfully and I can navigate
>>>> the site. When idling on one page for a couple of minutes, the issue
>>>> reappears on the next page request.
>>>>
>>>> If the server is configured for HTTPS2, this post might be relevant:
>>>> https://support.mozilla.org/en-US/questions/1139019
>>>
>>> Thanks!
>>>
>>> Please retry.
>>
>> The issue still persists. I think the reason is that the cipher suite
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA is negotiated which is blacklisted in
>> HTTP/2. Firefox probably falls back to HTTP/1.1 when negotiation failed
>> for a recent previous request.
> 
> Strange, I used the SSLCipherSuite line from https://icing.github.io/mod_h2/
> howto.html
> 
> I don't see the issue with Firefox 52.0.2
> 

This SSLCipherSuite?
> SSLCipherSuite 
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

It looks like you either did not specify "SSLHonorCipherOrder on" or
your SSLCipherSuite declaration is not used for some reason.

The cipher order presented by the server looks like the OpenSSL default
configuration:
https://www.ssllabs.com/ssltest/analyze.html?d=git.libssh.org

The first cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 was added with
Firefox 49 (I am on 48). The next ciphers are CBC ciphers which are all
blacklisted for HTTP2, which explains the
NS_ERROR_NET_INADEQUATE_SECURITY error.

What you should see is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the most
preferred cipher as defined in SSLCipherSuite. This is what it looks
like with the above SSLCipherSuite on our server:
https://www.ssllabs.com/ssltest/analyze.html?d=flam.de&s=144.76.236.9
Basically, the GCM ciphers should be at the top.

Hope this helps.

Re: Issue accessing https://git.libssh.org

[Tilo Eckert]

Am 28.06.2017 um 13:42 schrieb Andreas Schneider:
> On Wednesday, 28 June 2017 12:43:14 CEST Tilo Eckert wrote:
>> Hi,
> 
> Hi Tilo,
> 
>> I am experiencing a re-occuring issue when accessing
>> https://git.libssh.org with Firefox. When requesting a page for the
>> first time after browser startup or after not accessing the site for a
>> while, I get an SSL error page with the error code
>> NS_ERROR_NET_INADEQUATE_SECURITY.
>>
>> Refreshing the page causes it to load successfully and I can navigate
>> the site. When idling on one page for a couple of minutes, the issue
>> reappears on the next page request.
>>
>> If the server is configured for HTTPS2, this post might be relevant:
>> https://support.mozilla.org/en-US/questions/1139019
> 
> Thanks!
> 
> Please retry.

The issue still persists. I think the reason is that the cipher suite
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA is negotiated which is blacklisted in
HTTP/2. Firefox probably falls back to HTTP/1.1 when negotiation failed
for a recent previous request.

See RFC 7540 for all blacklisted suites:
https://tools.ietf.org/html/rfc7540#page-83

Regards,
Tilo

Issue accessing https://git.libssh.org

[Tilo Eckert]

Hi,

I am experiencing a re-occuring issue when accessing
https://git.libssh.org with Firefox. When requesting a page for the
first time after browser startup or after not accessing the site for a
while, I get an SSL error page with the error code
NS_ERROR_NET_INADEQUATE_SECURITY.

Refreshing the page causes it to load successfully and I can navigate
the site. When idling on one page for a couple of minutes, the issue
reappears on the next page request.

If the server is configured for HTTPS2, this post might be relevant:
https://support.mozilla.org/en-US/questions/1139019

Regards
Tilo

Re: Socket error: Unknown error

[Tilo Eckert]

Hi Mike,

the message is set in ssh_socket_exception_callback() in session.c. The
"Unknown error" is the output of strerror(). It is probably easiest to
fire up your debugger as there are multiple callback functions involved
in handling socket events. Your exception is probably fired in
ssh_socket_pollcallback() in socket.c.

Regards
Tilo

Am 22.05.2017 um 16:43 schrieb Mike DePaulo:
> Hi. 
> Over on X2Go Client for Windows (which uses libssh 0.7.x as an SSH
> client), a user is getting the message when attempting to connect to a
> server "Socket error: Unknown error".
> http://lists.x2go.org/pipermail/x2go-user/2017-May/004420.html
> (The message formatting got messed up in the link. I have the original
> email though.)
> 
> I believe this message is coming from libssh src/session.c . I do not
> know where the string "Unknown error" comes from though. 
> 
> I found this. I suppose I could modify X2Go Client to print out the
> error code, if that would be helpful.
> http://api.libssh.org/stable/group__libssh__error.html
> 
> Note that I cannot reproduce his issue.
> 
> Please advise.
> 
> Thanks,
> -Mike
> Volunteer X2Go Client for Windows maintainer

Re: SIGSEGV on master on ssh_channel_free

[Tilo Eckert]

Am 20.05.2017 um 17:29 schrieb Jason Curl:
> 
> On 20/05/2017 14:19, Jason Curl wrote:
>> Hello,
>>
>> My .NET wrapper (prototype) of libssh is crashing on
>> ssh_channel_free() with
>> a SIGSEGV. I've compiled abbd6e3 with MSYS2 32-bit with GCC 6.3.0 (see
>> attachment for cmake output). I'm running on Windows 10 64-bit release
>> 1703.
>>
>> $ cmake -G"Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/usr/local
>> -DCMAKE_BUILD_TYPE=Debug -DWITH_SSH1=ON ..
>>
>> Using GDB to debug I get the following information:
>>
>> Thread 1 received signal SIGSEGV, Segmentation fault.
>> 0x61cd847c in ssh_list_get_iterator (list=0xfeeefeee)
>>  at C:/msys64/home/jcurl/libssh/src/misc.c:382
>> 382   return list->root;
>> (gdb) bt
>> #0  0x61cd847c in ssh_list_get_iterator (list=0xfeeefeee)
>>  at C:/msys64/home/jcurl/libssh/src/misc.c:382
>> #1  0x61cd8491 in ssh_list_find (list=0xfeeefeee, value=0x55101f0)
>>  at C:/msys64/home/jcurl/libssh/src/misc.c:387
>> #2  0x61cc771c in ssh_channel_do_free (channel=0x55101f0)
>>  at C:/msys64/home/jcurl/libssh/src/channels.c:1037
>> #3  0x61cc76f1 in ssh_channel_free (channel=0x55101f0)
>>  at C:/msys64/home/jcurl/libssh/src/channels.c:1025
>> #4  0x014921cd in ?? ()
>> #5  0x014952f6 in ?? ()
>>
>> The other frames are from the CLR and are uninteresting.
>>
>> Sometimes I also get:
>>
>> Thread 1 received signal SIGSEGV, Segmentation fault.
>> 0x61cc4507 in ssh_buffer_free (buffer=0xfeeefeee)
>>  at C:/msys64/home/jcurl/libssh/src/buffer.c:108
>> 108   if (buffer->data) {
>> (gdb) bt
>> #0  0x61cc4507 in ssh_buffer_free (buffer=0xfeeefeee)
>>  at C:/msys64/home/jcurl/libssh/src/buffer.c:108
>> #1  0x61cc774b in ssh_channel_do_free (channel=0x157c230)
>>  at C:/msys64/home/jcurl/libssh/src/channels.c:1041
>> #2  0x61cc76f1 in ssh_channel_free (channel=0x157c230)
>>  at C:/msys64/home/jcurl/libssh/src/channels.c:1025
>>
>> My .NET program is simple. It does the following logical steps:
>>
>> ssh_init();
>> m_Session = ssh_new();
>> ssh_options_set(m_Session, SSH_OPTIONS_COMPRESSION_LEVEL, 9);
>> ssh_options_set(m_Session, SSH_OPTIONS_HOST, "mylinuxserver.home.lan");
>> ssh_options_set(m_Session, SSH_OPTIONS_USER, "myuser");
>> ssh_connect(m_Session);  // Returns SSH_OK
>> ssh_pki_import_privkey_file("myprivatekey", null, null, null, &key);
>> ssh_userauth_none(m_Session, null);  // Returns SSH_AUTH_DENIED as
>> expected
>> ssh_userauth_try_publickey(m_Session, null, key);  // Returns
>> SSH_AUTH_SUCCESS as expected
>> ssh_userauth_publickey(m_Session, null, key);
>> m_Channel = ssh_channel_new(m_Session);  // returns a pointer
> Further testing shows that the next two commands are not necessary.
> Commenting out ssh_channel_open_session and ssh_channel_request_exec
> reproduces a crash on master also.
> 
>> ssh_channel_open_session(m_Channel);  // returns SSH_OK
>> ssh_channel_request_exec(m_Channel, "ps aux");
>> ssh_disconnect(m_Session);
>> ssh_channel_free(m_Channel);  // CRASH HERE
>>
>>
> The crash I get in GDB is:
> 
> Thread 1 received signal SIGSEGV, Segmentation fault.
> 0x61cc4507 in ssh_buffer_free (buffer=0xfeeefeee)
> at C:/msys64/home/jcurl/libssh/src/buffer.c:108
> 108   if (buffer->data) {
> (gdb) bt full 4
> #0  0x61cc4507 in ssh_buffer_free (buffer=0xfeeefeee)
> at C:/msys64/home/jcurl/libssh/src/buffer.c:108
> No locals.
> #1  0x61cc774b in ssh_channel_do_free (channel=0xe5c1e8)
> at C:/msys64/home/jcurl/libssh/src/channels.c:1041
> it = 0x0
> session = 0xe5bfc8
> #2  0x61cc76f1 in ssh_channel_free (channel=0xe5c1e8)
> at C:/msys64/home/jcurl/libssh/src/channels.c:1025
> session = 0xe5bfc8
> #3  0x00d621d5 in ?? ()
> No symbol table info available.
> (More stack frames follow...)
> (gdb)
> 
> Googling, it appears that the MS function HeapFree() sets values to
> 0xFEEEFEEE. It's pretty tough to try and breakpoint a .NET program but I
> didn't observe any calls to ssh_free.
> 
> Create Channel from session: 26251480 0x19090D8
> 
> Thread 1 hit Breakpoint 1, ssh_channel_new (session=0x19090d8)
> at C:/msys64/home/jcurl/libssh/src/channels.c:80
> 
> Create Channel: 26264040 0x190C1E8
> 
> Thread 1 received signal SIGSEGV, Segmentation fault.
> 0x61cc4507 in ssh_buffer_free (buffer=0xfeeefeee)
> at C:/msys64/home/jcurl/libssh/src/buffer.c:108
> 108   if (buffer->data) {
> (gdb) bt ful 4
> #0  0x61cc4507 in ssh_buffer_free (buffer=0xfeeefeee)
> at C:/msys64/home/jcurl/libssh/src/buffer.c:108
> No locals.
> #1  0x61cc774b in ssh_channel_do_free (channel=0x190c1e8)
> at C:/msys64/home/jcurl/libssh/src/channels.c:1041
> it = 0x0
> session = 0x190bfc8
> #2  0x61cc76f1 in ssh_channel_free (channel=0x190c1e8)
> at C:/msys64/home/jcurl/libssh/src/channels.c:1025
> session = 0x190bfc8
> #3  0x031a21d5 in ?? ()
> 
> ssh_channel_free is given the value m_Channel, but isn't the value of
> session in frame #1 expected to be 0x19090D8 and not 0x190bfc8?

Re: problems with ssh_userauth_list

[Tilo Eckert]

If you handle SSH_AUTH_AGAIN with a loop, you probably want to use
blocking mode instead. Non-blocking mode is suitable if your application
works asynchronously.

Am 05.05.2017 um 10:47 schrieb Daniel Kroker:
> thanks i try it.
> 
> whats the best way to handle SSH_AUTH_AGAIN ? while loop and try again
> ssh_userauth_none ?
> 
> Am 05.05.2017 um 10:32 schrieb Tilo Eckert:
>> You did not check the return code "rc".
>>
>> You could already be logged in after the ssh_userauth_none() call (e.g.
>> IP based auth). An error could occur (SSH_AUTH_ERROR) or if you are in
>> non-blocking mode SSH_AUTH_AGAIN could be returned.
>>
>> Am 05.05.2017 um 10:24 schrieb Daniel Kroker:
>>> Hi,
>>>
>>> thanks for your reply. i call ssh_userath_none.
>>>
>>> Here is a small snippet from our program:
>>>
>>> if(!session)
>>>
>>> {
>>>
>>> qDebug()<<"Session not established";
>>>
>>> qDebug()<<"SSH Error 12: ",ssh_get_error(session);
>>>
>>> return-1;
>>>
>>> }
>>>
>>> rc=ssh_userauth_none(session,NULL);
>>>
>>> method=ssh_userauth_list(session,NULL);
>>>
>>> qDebug()<<"method: "<>>
>>> if(method&SSH_AUTH_METHOD_PASSWORD)
>>>
>>> { 
>>>
>>>
>>>
>>> Am 05.05.2017 um 10:22 schrieb Tilo Eckert:
>>>> http://api.libssh.org/stable/group__libssh__auth.html#ga35d44897a44b4bb3b7c01108c1812a37
>>>>
>>>> You either did not call ssh_userauth_none() before or the server does
>>>> not allow any of the supported auth methods.
>>>>
>>>> Regards
>>>> Tilo
>>>>
>>>> Am 05.05.2017 um 09:26 schrieb Daniel Kroker:
>>>>> Hi,
>>>>>
>>>>> we have the problem that in some cases ssh_userauth_list(session,NULL);
>>>>> returned 0.
>>>>> What is 0 exacly?
>>> -- 
>>> Mit freundlichen Grüßen
>>> Daniel Kroker
>>>
>>> VENTAS AG20+ Jahre ERP-Erfahrung!
>>> Web: www.ventas.de
>>> Fon: 040 / 32 33 34 0
>>> Fax: 040 / 32 33 34 38
>>> Firmensitz: Neuer Wall 10, 20354 Hamburg, Deutschland
>>> Registergericht: Hamburg, HRB 80 297 Ust.IdNr.: DE118686712
>>> Vorstandsvorsitzender: Dipl. Ing. Alain Siverly
>>> Aufsichtsratsvorsitzender: Dr. Olaf Rehme 
>>>
>>
> 
> -- 
> Mit freundlichen Grüßen
> Daniel Kroker
> 
> VENTAS AG20+ Jahre ERP-Erfahrung!
> Web: www.ventas.de
> Fon: 040 / 32 33 34 0
> Fax: 040 / 32 33 34 38
> Firmensitz: Neuer Wall 10, 20354 Hamburg, Deutschland
> Registergericht: Hamburg, HRB 80 297 Ust.IdNr.: DE118686712
> Vorstandsvorsitzender: Dipl. Ing. Alain Siverly
> Aufsichtsratsvorsitzender: Dr. Olaf Rehme 
> 

Re: problems with ssh_userauth_list

[Tilo Eckert]

You did not check the return code "rc".

You could already be logged in after the ssh_userauth_none() call (e.g.
IP based auth). An error could occur (SSH_AUTH_ERROR) or if you are in
non-blocking mode SSH_AUTH_AGAIN could be returned.

Am 05.05.2017 um 10:24 schrieb Daniel Kroker:
> Hi,
> 
> thanks for your reply. i call ssh_userath_none.
> 
> Here is a small snippet from our program:
> 
> if(!session)
> 
> {
> 
> qDebug()<<"Session not established";
> 
> qDebug()<<"SSH Error 12: ",ssh_get_error(session);
> 
> return-1;
> 
> }
> 
> rc=ssh_userauth_none(session,NULL);
> 
> method=ssh_userauth_list(session,NULL);
> 
> qDebug()<<"method: "< 
> if(method&SSH_AUTH_METHOD_PASSWORD)
> 
> { 
> 
> 
> 
> Am 05.05.2017 um 10:22 schrieb Tilo Eckert:
>> http://api.libssh.org/stable/group__libssh__auth.html#ga35d44897a44b4bb3b7c01108c1812a37
>>
>> You either did not call ssh_userauth_none() before or the server does
>> not allow any of the supported auth methods.
>>
>> Regards
>> Tilo
>>
>> Am 05.05.2017 um 09:26 schrieb Daniel Kroker:
>>> Hi,
>>>
>>> we have the problem that in some cases ssh_userauth_list(session,NULL);
>>> returned 0.
>>> What is 0 exacly?
>>
> 
> -- 
> Mit freundlichen Grüßen
> Daniel Kroker
> 
> VENTAS AG20+ Jahre ERP-Erfahrung!
> Web: www.ventas.de
> Fon: 040 / 32 33 34 0
> Fax: 040 / 32 33 34 38
> Firmensitz: Neuer Wall 10, 20354 Hamburg, Deutschland
> Registergericht: Hamburg, HRB 80 297 Ust.IdNr.: DE118686712
> Vorstandsvorsitzender: Dipl. Ing. Alain Siverly
> Aufsichtsratsvorsitzender: Dr. Olaf Rehme 
> 

Re: problems with ssh_userauth_list

[Tilo Eckert]

http://api.libssh.org/stable/group__libssh__auth.html#ga35d44897a44b4bb3b7c01108c1812a37

You either did not call ssh_userauth_none() before or the server does
not allow any of the supported auth methods.

Regards
Tilo

Am 05.05.2017 um 09:26 schrieb Daniel Kroker:
> Hi,
> 
> we have the problem that in some cases ssh_userauth_list(session,NULL);
> returned 0.
> What is 0 exacly?

Re: Need urgent help

[Tilo Eckert]

Hi Nitesh,

you don't have the OpenSSL development headers installed. They should be
in package openssl-devel, or whatever it is named in RHEL.

Best regards
Tilo

Am 27.03.2017 um 06:25 schrieb Nitesh Srivastava:
>  
> 
> Hi All,
> 
>  
> 
> We are getting below error while compiling the libssh 7.3 version on
> RHEL 7.1 OS.  We are in between compilation , Please suggest how to
> resolved this.
> 
>  
> 
> -- The C compiler identification is GNU 4.8.3
> 
> -- Check for working C compiler: /bin/cc
> 
> -- Check for working C compiler: /bin/cc -- works
> 
> -- Detecting C compiler ABI info
> 
> -- Detecting C compiler ABI info - done
> 
> -- Detecting C compile features
> 
> -- Detecting C compile features - done
> 
> -- Performing Test WITH_FPIC
> 
> -- Performing Test WITH_FPIC - Success
> 
> -- Performing Test WITH_STACK_PROTECTOR
> 
> -- Performing Test WITH_STACK_PROTECTOR - Success
> 
> -- Found ZLIB: /usr/lib/libz.so (found version "1.2.7")
> 
> -- Found OpenSSL: /usr/lib/libssl.so;/usr/lib/libcrypto.so (found
> version "1.0.1e")
> 
> -- Looking for pthread.h
> 
> -- Looking for pthread.h - found
> 
> -- Looking for pthread_create
> 
> -- Looking for pthread_create - not found
> 
> -- Looking for pthread_create in pthreads
> 
> -- Looking for pthread_create in pthreads - not found
> 
> -- Looking for pthread_create in pthread
> 
> -- Looking for pthread_create in pthread - found
> 
> -- Found Threads: TRUE
> 
> -- Found GSSAPI:
> /usr/lib/libgssapi_krb5.so;/usr/lib/libkrb5.so;/usr/lib/libk5crypto.so;/usr/lib/libcom_err.so
> 
> -- Could NOT find NaCl (missing:  NACL_LIBRARIES NACL_INCLUDE_DIRS)
> 
> -- Performing Test WITH_VISIBILITY_HIDDEN
> 
> -- Performing Test WITH_VISIBILITY_HIDDEN - Success
> 
> -- Looking for argp.h
> 
> -- Looking for argp.h - found
> 
> -- Looking for pty.h
> 
> -- Looking for pty.h - found
> 
> -- Looking for utmp.h
> 
> -- Looking for utmp.h - found
> 
> -- Looking for termios.h
> 
> -- Looking for termios.h - found
> 
> -- Looking for unistd.h
> 
> -- Looking for unistd.h - found
> 
> -- Looking for util.h
> 
> -- Looking for util.h - not found
> 
> -- Looking for libutil.h
> 
> -- Looking for libutil.h - not found
> 
> -- Looking for sys/time.h
> 
> -- Looking for sys/time.h - found
> 
> -- Looking for sys/param.h
> 
> -- Looking for sys/param.h - found
> 
> -- Looking for arpa/inet.h
> 
> -- Looking for arpa/inet.h - found
> 
> -- Looking for byteswap.h
> 
> -- Looking for byteswap.h - found
> 
> -- Looking for openssl/des.h
> 
> -- Looking for openssl/des.h - not found
> 
> CMake Error at ConfigureChecks.cmake:74 (message):
> 
>   Could not detect openssl/des.h
> 
> Call Stack (most recent call first):
> 
>   CMakeLists.txt:78 (include)
> 
>  
> 
> Kind Regards,
> 
> Nitesh
> 
>  
> 
>  
> 
>  
> 

Re: Need Help

[Tilo Eckert]

See the README and INSTALL files inside the archive.

Am 16.03.2017 um 11:57 schrieb Nitesh Srivastava:
> Hi
> 
>  
> 
> *How to do the libssh-0.7.3.tar.xz
>  
> compilation
> on RHEL 7.1 (32 bit) Linux *
> 
> *Is Any make file or set of Step to do *
> 
>  
> 
> Regards,
> 
> Nitesh
> 
>  
> 
>  
> 

Re: X11 Forwarding

[Tilo Eckert]

Hi Wesley

I don't think that libssh implements passing the data stream of an
X11-type channel to X11. The ssh_channel_accept_x11() call is simply
forwarded to ssh_channel_accept() with X11 as channel type flag. I guess
you have to read from the channel with ssh_channel_read() and pass the
stream to X11 yourself.

Regards
Tilo

Am 11.02.2017 um 18:27 schrieb Wesley Witt:
> I am trying to get X11 forwarding working and it appears that the right 
> support is in libssh, but the docs are not clear as to how to make it work.
> 
> Below is the code and the resulting libssh log. Xclock does execute but I do 
> not see the UI display on the remote computer. There is a note in the docs 
> about seeting the DISPLAY variable, but I'm not sure where to set it. I tried 
> using ssh_channel_request_env but that does not work. I'm not even sure if 
> this is the issue. Any help would be appreciated.
> 
> If I start an SSH session using "ssh -X", set the DISPLAY variable in the 
> shell and then start xclock it works as expected. This is what I want to 
> accomplish with libssh.
> 
> 
> m_channel = ssh_channel_new(m_session);
> ssh_channel_open_session(m_channel);
> ssh_channel_request_x11(m_channel, 1, NULL, NULL, 0);
> ssh_channel_request_exec(m_channel, "xclock");
> ssh_channel x11_channel = ssh_channel_accept_x11(m_channel, 3000);
> 
> 
> [2017/02/11 09:23:47.520517, 2] ssh_connect:  libssh 0.7.2 (c) 2003-2014 Aris 
> Adamantiadis, Andreas Schneider, and libssh contributors. Distributed under 
> the LGPL, please refer to COPYING file for information about your rights, 
> using threading threads_noop
> [2017/02/11 09:23:47.528022, 2] ssh_socket_connect:  Nonblocking connection 
> socket: 472
> [2017/02/11 09:23:47.528022, 2] ssh_connect:  Socket connecting, now waiting 
> for the callbacks to work
> [2017/02/11 09:23:47.528522, 1] socket_callback_connected:  Socket connection 
> callback: 1 (0)
> [2017/02/11 09:23:47.535528, 1] ssh_client_connection_callback:  SSH server 
> banner: SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
> [2017/02/11 09:23:47.535528, 1] ssh_analyze_banner:  Analyzing banner: 
> SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
> [2017/02/11 09:23:47.535528, 1] ssh_analyze_banner:  We are talking to an 
> OpenSSH client version: 7.2 (70200)
> [2017/02/11 09:23:47.638095, 2] ssh_packet_dh_reply:  Received SSH_KEXDH_REPLY
> [2017/02/11 09:23:47.641598, 2] ssh_client_curve25519_reply:  SSH_MSG_NEWKEYS 
> sent
> [2017/02/11 09:23:47.641598, 2] ssh_packet_newkeys:  Received SSH_MSG_NEWKEYS
> [2017/02/11 09:23:47.643599, 2] ssh_packet_newkeys:  Signature verified and 
> valid
> [2017/02/11 09:23:47.691131, 2] channel_open:  Creating a channel 43 with 
> 64000 window and 32768 max packet
> [2017/02/11 09:23:47.788195, 2] ssh_packet_global_request:  Received 
> SSH_MSG_GLOBAL_REQUEST packet
> [2017/02/11 09:23:47.788696, 2] ssh_packet_global_request:  UNKNOWN 
> SSH_MSG_GLOBAL_REQUEST hostkeys...@openssh.com 0
> [2017/02/11 09:23:47.788696, 1] ssh_packet_process:  Couldn't do anything 
> with packet type 80
> [2017/02/11 09:23:47.788696, 2] ssh_packet_channel_open_conf:  Received a 
> CHANNEL_OPEN_CONFIRMATION for channel 43:0
> [2017/02/11 09:23:47.788696, 2] ssh_packet_channel_open_conf:  Remote window 
> : 0, maxpacket : 32768
> [2017/02/11 09:23:47.789196, 2] channel_request:  Channel request x11-req 
> success
> [2017/02/11 09:23:47.789696, 2] channel_rcv_change_window:  Adding 2097152 
> bytes to channel (43:0) (from 0 bytes)
> [2017/02/11 09:23:47.789696, 2] channel_request:  Channel request exec success
> 
> 

Re: passing passphrase as parameter?

[Tilo Eckert]

Hi Alex

why don't you generate host keys without a password? If you put the
password of the keys into your code instead of entering it manually, it
is as good as having no password at all. Private SSH host keys should
never leave the machine they were generated on anyway and should only be
accessible by root.

Regards
Tilo

Am 27.01.2017 um 06:11 schrieb alex rosky:
> 
> 
> 
> 
Hello there,
> 
> I'm coding a simple SSH server for learning and I have created dsa and
> rsa keys passing a passphrase. now in my ssh server code, when calling
> ssh_bind_listen, it prompts for this passphrase so my question is, is
> there any way to pass this passphrase as parameter or by callback or
> something without needing to write this manually? my pseudocode:
> 
>  port = ;
> hsession= ssh_new();
> hbind= ssh_bind_new();
> ssh_bind_options_set(hbind, SSH_BIND_OPTIONS_BINDPORT, &port);
> ssh_bind_options_set(hbind, SSH_BIND_OPTIONS_DSAKEY, "ssh_host_dsa_key");
> ssh_bind_options_set(hbind, SSH_BIND_OPTIONS_RSAKEY, "ssh_host_rsa_key");
> 
> ssh_bind_listen(hbind)
> 
> Thanks.
> 
> Alex Jackson.

Re: Question about sftp and timestamp

[Tilo Eckert]

Hi Claudio,

you can use sftp_setstat() or sftp_utimes() to set the file timestamps.
I recommend the first one as it allows you to decide which timestamps to
set. The time is passed as seconds and nanoseconds since 1970. The 64
bit fields in the sftp_attributes structure are not really used. Just
set mtime, mtime_nseconds and so on.

See: http://api.libssh.org/master/group__libssh__sftp.html

Regards
Tilo

Am 13.12.2016 um 13:36 schrieb Fischer, Claudio:
> hi all,
> 
> i have a question about copying a file with libssh sftp.
> 
> If i copy a file with sftp_write(), the copied file gets the
> timestamp of the actual copy date and time of the system.
> 
> Is there a option to keep the same timestamp for
> a copied file like in the original file?
> 
> Like the cp command does with the option
> "-p same as --preserve=mode,ownership,timestamps"
> 
> 
> regards,
> Claudio

Re: Building library for Windows

[Tilo Eckert]

> For me, make and make install are not working.
Can you elaborate on that? Does it give you an error message or do you
simply not have GNU make in your MinGW install? On Windows, you might
need MSYS (http://www.mingw.org/wiki/msys) for the GNU tools.

Also make.exe could have a different name in your MinGW install:
https://stackoverflow.com/questions/12881854/how-to-use-gnu-make-on-windows

Regards
Tilo

Re: Building library for Windows

[Tilo Eckert]

The INSTALL file that comes with libssh contains all the basic
information you need to know to build it. We cross compile libssh on
Linux for MinGW and various other platforms.

It basically boils down to:
- Install all pre-requisites
- Change DefineOptions.cmake to your needs
- cmake -DCMAKE_BUILD_TYPE=Release
- make
- make install

These cmake parameters are relevant only if you don't want libssh to be
installed to the default location by 'make install' or if you did not
install OpenSSL to the default location (i.e. if you compiled it yourself):
-DCMAKE_INSTALL_PREFIX=${INSTALLDIR}
-DOPENSSL_ROOT_DIR=${OPENSSLDIR}
-DOPENSSL_INCLUDE_DIR=${OPENSSLDIR}/include

In case you cross compile, you will need a few more cmake options. I can
elaborate on that if necessary.

PS: Please do not send HTML emails to mailing lists.

Regards
Tilo

Am 29.09.2016 um 09:19 schrieb Servesh Singh:
>  
> 
> Hi Team,
> I searched everywhere but could not find complete help for building
> static library for Windows platform using MinGW.
> Please guide me if anyone has done this.
> Thanks in advance,
> 
> Regards,
> Servesh
> 

Re: Libssh bits for Windows

[Tilo Eckert]

We are cross compiling for Windows on Linux using MinGW (i.e. no MSVC)
and configure everything via cmake parameters. Here's the cmake call we
currently use:

> cmake '-DCMAKE_C_FLAGS:STRING=-m64 -march=x86-64 -mtune=generic' 
> -DCMAKE_SYSTEM_NAME=Windows -DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc 
> -DCMAKE_INSTALL_PREFIX=/my/output/path -DCMAKE_BUILD_TYPE=Release 
> -DOPENSSL_ROOT_DIR=/my/openssl/path 
> -DOPENSSL_INCLUDE_DIR=/my/openssl/path/include -DWITH_GSSAPI=OFF 
> -DWITH_ZLIB=OFF -DWITH_SSH1=OFF -DWITH_SFTP=ON -DWITH_SERVER=OFF 
> -DWITH_STATIC_LIB=ON -DWITH_DEBUG_CRYPTO=OFF -DWITH_DEBUG_CALLTRACE=ON 
> -DWITH_GCRYPT=OFF -DWITH_PCAP=ON -DWITH_INTERNAL_DOC=OFF -DWITH_TESTING=OFF 
> -DWITH_CLIENT_TESTING=OFF -DWITH_BENCHMARKS=OFF -DWITH_EXAMPLES=OFF 
> -DWITH_NACL=ON /my/libssh/path

Regards
Tilo

Am 21.07.2016 um 21:14 schrieb Hitesh Sharma:
> The error I'm getting for Windows are same as listed here.
> 
> https://www.libssh.org/archive/libssh/2014-04/082.html
> 
> IIRC there were a few headers that were being complained about in my
> case. Can you share the CMake configuration you used (like which MSVC
> compiler, etc)? I'm very new to CMake so it is quite likely I didn't set
> it up properly.
> 
> Thanks,
> Hitesh
> 
>> Date: Thu, 21 Jul 2016 09:29:14 +0200
>> From: tilo.eck...@flam.de
>> To: libssh@libssh.org
>> Subject: Re: Libssh bits for Windows
>>
>> There are no binaries at this time as long as red.libssh.org does not
> work.
>>
>> What are your Windows build errors? Is it something about session.c? If
>> yes, I submitted a patch for a Windows build issue 3 weeks ago which has
>> not been included into master, yet. You can find it here (the last of
>> the three):
>> http://permalink.gmane.org/gmane.network.ssh.libssh.general/2474
>>
>> Regards
>> Tilo
>>
>> Am 20.07.2016 um 20:15 schrieb Hitesh Sharma:
>> > Thanks for the response.
>> >
>> > I'm looking for Windows binaries so I don't have to build myself. FWIW,
>> > I tried building for Windows and run into some errors.
>> >
>> > Regards,
>> > Hitesh
>> >
>> > 
>> > From: spaniku...@ipswitch.com
>> > To: libssh@libssh.org
>> > Subject: RE: Libssh bits for Windows
>> > Date: Wed, 20 Jul 2016 17:32:41 +
>> >
>> > Latest version of the Master Branch in ZIP and TGZ format is
> available at
>> >
>> >
>> >
>> > https://git.libssh.org/projects/libssh.git/snapshot/master.zip
>> >
>> > https://git.libssh.org/projects/libssh.git/snapshot/master.tar.gz
>> >
>> >
>> >
>> > *From:*Hitesh Sharma [mailto:shankarhit...@hotmail.com]
>> > *Sent:* Wednesday, July 20, 2016 13:15
>> > *To:* libssh@libssh.org
>> > *Subject:* RE: Libssh bits for Windows
>> >
>> >
>> >
>> > Thank you for the response, folks.
>> >
>> >
>> >
>> > Is there an alternate medium to download the Windows bits? If someone
>> > can upload it somewhere then it will help while we wait for the server
>> > to be fixed.
>> >
>> >
>> >
>> > Regards,
>> >
>> > Hitesh
>> >
>> >
>> >
>> >> Subject: Re: Libssh bits for Windows
>> >> To: libssh@libssh.org <mailto:libssh@libssh.org>
>> >> From: a...@0xbadc0de.be <mailto:a...@0xbadc0de.be>
>> >> Date: Wed, 20 Jul 2016 12:58:20 +0200
>> >>
>> >> Hi,
>> >>
>> >> I'm sorry, it's Andreas who's the only one with access to the failed
>> >> server, and he's unfortunately unreachable (I tried a few times already
>> >> on different mediums). When he's back and the server is back online,
>> >> we'll discuss a way to have backup access in case the server needs
> a fix.
>> >>
>> >> Aris
>> >>
>> >>
>> >> On 20/07/16 12:09, Tilo Eckert wrote:
>> >> > http://comments.gmane.org/gmane.network.ssh.libssh.general/2479
>> >> >
>> >> > Libssh maintainers aren't very active, unfortunately...
>> >> >
>> >> > Am 19.07.2016 um 21:51 schrieb Hitesh Sharma:
>> >> >> Hello,
>> >> >>
>> >> >> The download link for libssh seems to be broken. Why is that?
>> >> >>
>> >> >> https://red.libssh.org/projects/libssh/files
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> Hitesh
>> >> >>
>> >> >>
>> >> >> Object not found!
>> >> >>
>> >> >> The requested URL was not found on this server. The link on the
>> >> >> referring page seems to be wrong or outdated. Please inform the
> author
>> >> >> of that page about the error.
>> >> >>
>> >> >> If you think this is a server error, please contact the webmaster.
>> >> >>
>> >> >> Error 404
>> >> >>
>> >> >> red.libssh.org
>> >> >> Apache/2.4.16 (Linux/SUSE)
>> >> >
>> >>
>> >>
>> >
>>
>>

Re: Libssh bits for Windows

[Tilo Eckert]

There are no binaries at this time as long as red.libssh.org does not work.

What are your Windows build errors? Is it something about session.c? If
yes, I submitted a patch for a Windows build issue 3 weeks ago which has
not been included into master, yet. You can find it here (the last of
the three):
http://permalink.gmane.org/gmane.network.ssh.libssh.general/2474

Regards
Tilo

Am 20.07.2016 um 20:15 schrieb Hitesh Sharma:
> Thanks for the response.
> 
> I'm looking for Windows binaries so I don't have to build myself. FWIW,
> I tried building for Windows and run into some errors. 
> 
> Regards,
> Hitesh
> 
> 
> From: spaniku...@ipswitch.com
> To: libssh@libssh.org
> Subject: RE: Libssh bits for Windows
> Date: Wed, 20 Jul 2016 17:32:41 +
> 
> Latest version of the Master Branch in ZIP and TGZ format is available at
> 
>  
> 
> https://git.libssh.org/projects/libssh.git/snapshot/master.zip
> 
> https://git.libssh.org/projects/libssh.git/snapshot/master.tar.gz
> 
>  
> 
> *From:*Hitesh Sharma [mailto:shankarhit...@hotmail.com]
> *Sent:* Wednesday, July 20, 2016 13:15
> *To:* libssh@libssh.org
> *Subject:* RE: Libssh bits for Windows
> 
>  
> 
> Thank you for the response, folks.
> 
>  
> 
> Is there an alternate medium to download the Windows bits? If someone
> can upload it somewhere then it will help while we wait for the server
> to be fixed.
> 
>  
> 
> Regards,
> 
> Hitesh
> 
>  
> 
>> Subject: Re: Libssh bits for Windows
>> To: libssh@libssh.org <mailto:libssh@libssh.org>
>> From: a...@0xbadc0de.be <mailto:a...@0xbadc0de.be>
>> Date: Wed, 20 Jul 2016 12:58:20 +0200
>> 
>> Hi,
>> 
>> I'm sorry, it's Andreas who's the only one with access to the failed
>> server, and he's unfortunately unreachable (I tried a few times already
>> on different mediums). When he's back and the server is back online,
>> we'll discuss a way to have backup access in case the server needs a fix.
>> 
>> Aris
>> 
>> 
>> On 20/07/16 12:09, Tilo Eckert wrote:
>> > http://comments.gmane.org/gmane.network.ssh.libssh.general/2479
>> >
>> > Libssh maintainers aren't very active, unfortunately...
>> >
>> > Am 19.07.2016 um 21:51 schrieb Hitesh Sharma:
>> >> Hello,
>> >>
>> >> The download link for libssh seems to be broken. Why is that?
>> >>
>> >> https://red.libssh.org/projects/libssh/files
>> >>
>> >> Thanks,
>> >>
>> >> Hitesh
>> >>
>> >>
>> >> Object not found!
>> >>
>> >> The requested URL was not found on this server. The link on the
>> >> referring page seems to be wrong or outdated. Please inform the author
>> >> of that page about the error.
>> >>
>> >> If you think this is a server error, please contact the webmaster.
>> >>
>> >> Error 404
>> >>
>> >> red.libssh.org
>> >> Apache/2.4.16 (Linux/SUSE)
>> >
>> 
>> 
> 

Re: Libssh bits for Windows

[Tilo Eckert]

http://comments.gmane.org/gmane.network.ssh.libssh.general/2479

Libssh maintainers aren't very active, unfortunately...

Am 19.07.2016 um 21:51 schrieb Hitesh Sharma:
> Hello,
> 
> The download link for libssh seems to be broken. Why is that?
> 
> https://red.libssh.org/projects/libssh/files
> 
> Thanks,
> 
> Hitesh
> 
> 
> Object not found!
> 
> The requested URL was not found on this server. The link on the
> referring page seems to be wrong or outdated. Please inform the author
> of that page about the error.
> 
> If you think this is a server error, please contact the webmaster.
> 
> Error 404
> 
> red.libssh.org
> Apache/2.4.16 (Linux/SUSE)

Re: https://red.libssh.org/projects/libssh/files not accessible

[Tilo Eckert]

The link is 404 as you already discovered. Therefore get the source from
git by following the respective links on that page.

Am 11.07.2016 um 12:56 schrieb Nagaraj Komarasamy:
> Hi Yang,
> 
>  https://www.libssh.org/get-it/ is working and I am trying to access the
> following link,
> From the page
> A NSIS installer and zip archives of the latest version can be
> found here <https://red.libssh.org/projects/libssh/files>.
> 
> -
> 
> Thanks,
> Naga
> 
> On Mon, Jul 11, 2016 at 2:48 PM, Yang Yubo  <mailto:y...@yangyubo.com>> wrote:
> 
> Hi,
> 
> See here: https://www.libssh.org/get-it/
> 
> And another question that may off topic: why libssh does not hosting
> on Github?
> 
> For my personal opinion, issue tracking and pull requesting on
> Github would make libssh development much more responsive.
> 
> Best wishes,
> 
> Yang
> 
>> On Jul 11, 2016, at 17:08, Tilo Eckert > <mailto:tilo.eck...@flam.de>> wrote:
>>
>> Check the download page on the website. There are multiple links
>> to the
>> git web frontend or just get the source with git.
>>
>> Regards
>> Tilo
>>
>> Am 11.07.2016 um 10:44 schrieb Nagaraj Komarasamy:
>>> Hi,
>>>
>>> Could you please help me to get the download link to download the
>>> src or
>>> libraries. The link is not working.
>>>
>>> or point me to report the problem.
>>>
>>> Thanks,
>>> Naga
>>>
>>> -- Forwarded message --
>>> From: *Nagaraj Komarasamy* <1inmill...@gmail.com
>>> <mailto:1inmill...@gmail.com>
>>> <mailto:1inmill...@gmail.com>>
>>> Date: Sat, Jul 9, 2016 at 1:27 PM
>>> Subject: https://red.libssh.org/projects/libssh/files not accessible
>>> To: libssh@libssh.org <mailto:libssh@libssh.org>
>>> <mailto:libssh@libssh.org>
>>>
>>>
>>> Hi,
>>>
>>> I am not able to access the url. Please let me know if there is other
>>> url to access the download link.
>>>
>>> Thanks,
>>> Naga
>>>
>>
>>
> 
> 

Re: Fwd: https://red.libssh.org/projects/libssh/files not accessible

[Tilo Eckert]

Check the download page on the website. There are multiple links to the
git web frontend or just get the source with git.

Regards
Tilo

Am 11.07.2016 um 10:44 schrieb Nagaraj Komarasamy:
> Hi,
> 
> Could you please help me to get the download link to download the src or
> libraries. The link is not working. 
> 
> or point me to report the problem.
> 
> Thanks,
> Naga
> 
> -- Forwarded message --
> From: *Nagaraj Komarasamy* <1inmill...@gmail.com
> >
> Date: Sat, Jul 9, 2016 at 1:27 PM
> Subject: https://red.libssh.org/projects/libssh/files not accessible
> To: libssh@libssh.org 
> 
> 
> Hi,
> 
> I am not able to access the url. Please let me know if there is other
> url to access the download link.
> 
> Thanks,
> Naga
> 

Re: Fwd: server side ipv6 support

[Tilo Eckert]

Hello Nagaraj

1. libssh should be compilable on any platform where you have a recent
enough cmake version and OpenSSL/gcrypt available. We currently have it
working on Windows, Linux, z/Linux, and even z/OS. For the mainframe
compile we had to create a custom makefile (no cmake available) and make
some modifications, but it works.

2. We don't use the server part, but IPv6 should work because you can
pass a custom socket fd through the server API. See:
http://api.libssh.org/master/group__libssh__server.html

Regards
Tilo

Am 07.07.2016 um 07:46 schrieb Nagaraj Komarasamy:
> Hello all,
> 
> I am working on to check the feasibility of using libssh with our
> product. Our product is distributed and each installation will listen on
> a particular port and we need to secure it with publickey cryptography
> and public key authentication. Each installation will act as a server by
> itself and will be a client to other installations.
> 
> Following are first list of queries comes to mind.
> 
> 1. should I be able to compile libssh on the following platforms? If
> anyone faced any issues on compiling in any of the platforms, please let
> me know.
> 
>   * windows 32 and 64 bit
>   * Linux 32 and 64 bit
>   * HP-UX (PA-RISC) 11.11, 11.23, 11.31
>   * HP-UX (Itanium) 11.23, 11.31
>   * Novell Open Enterprise Server 2.0 for Linux (32-bit and 64-bit)
>   * Novell Open Enterprise Server 11.x for Linux (64-bit) 
>   * Novell Open Enterprise Server 2015 for Linux (64-bit)
>   * Sun Solaris (SPARC) 9, 10, 11
>   * Sun Solaris (x86, x64) 10, 11
>   * SCO OpenServer 6.0.0 
>   * Open VMS 8.3 , 8.4 (Alpha) 
>   * Open VMS 8.3, 8.3-1H1 , 8.4 (Itanium)
>   * Mac OS X Server 10.6.x (64-bit) (x64)
> 
> 
> 2. IPV6 server side support available?
> 
> Let me know if you need more information.
> 
> Thanks,
> Naga
> 
> 
> 

Bugfix patches + SFTP append support

[Tilo Eckert]

Hi,

I attached some patches:

- The SSH_FXF_READ flag was always set when opening a file via SFTP
- I added support for opening files in append mode. Due to bad protocol
design I had to query the file size through the stat() function to get
the EOF offset, which makes opening a file in append mode non-atomic.
- The current master was not compilable on Windows since November.

Regards
Tilo
From d47a6b435a37bc811a77651891b768c41ee1afb4 Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Thu, 30 Jun 2016 12:27:43 +0200
Subject: [PATCH 1/3] bug fix: SFTP flag SSH_FXF_READ was always set (even on
 O_WRONLY) because O_RDONLY == 0

Comparison ((flags & O_RDONLY) == O_RDONLY) is always true.
Also, O_RDWR, O_WRONLY and O_RDONLY are mutually exclusive => no need to check 
all of them

Signed-off-by: Tilo Eckert 
---
 src/sftp.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/sftp.c b/src/sftp.c
index f99683d..db5b088 100644
--- a/src/sftp.c
+++ b/src/sftp.c
@@ -1625,12 +1625,12 @@ sftp_file sftp_open(sftp_session sftp, const char 
*file, int flags,
   attr.permissions = mode;
   attr.flags = SSH_FILEXFER_ATTR_PERMISSIONS;
 
-  if ((flags & O_RDONLY) == O_RDONLY)
-sftp_flags |= SSH_FXF_READ;
-  if ((flags & O_WRONLY) == O_WRONLY)
-sftp_flags |= SSH_FXF_WRITE;
   if ((flags & O_RDWR) == O_RDWR)
 sftp_flags |= (SSH_FXF_WRITE | SSH_FXF_READ);
+  else if ((flags & O_WRONLY) == O_WRONLY)
+sftp_flags |= SSH_FXF_WRITE;
+  else
+sftp_flags |= SSH_FXF_READ;
   if ((flags & O_CREAT) == O_CREAT)
 sftp_flags |= SSH_FXF_CREAT;
   if ((flags & O_TRUNC) == O_TRUNC)
-- 
2.9.0

From a12d8c856a52cedba408e7817881e09411520b6b Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Fri, 1 Jul 2016 10:57:38 +0200
Subject: [PATCH 2/3] add append support to sftp_open()

Signed-off-by: Tilo Eckert 
---
 src/sftp.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/sftp.c b/src/sftp.c
index db5b088..ae8418b 100644
--- a/src/sftp.c
+++ b/src/sftp.c
@@ -1605,6 +1605,7 @@ sftp_file sftp_open(sftp_session sftp, const char *file, 
int flags,
   sftp_file handle;
   ssh_string filename;
   ssh_buffer buffer;
+  sftp_attributes statData;
   uint32_t sftp_flags = 0;
   uint32_t id;
 
@@ -1637,6 +1638,8 @@ sftp_file sftp_open(sftp_session sftp, const char *file, 
int flags,
 sftp_flags |= SSH_FXF_TRUNC;
   if ((flags & O_EXCL) == O_EXCL)
 sftp_flags |= SSH_FXF_EXCL;
+  if ((flags & O_APPEND) == O_APPEND)
+sftp_flags |= SSH_FXF_APPEND;
   SSH_LOG(SSH_LOG_PACKET,"Opening file %s with sftp flags %x",file,sftp_flags);
   id = sftp_get_new_id(sftp);
   if (ssh_buffer_add_u32(buffer, htonl(id)) < 0 ||
@@ -1684,6 +1687,19 @@ sftp_file sftp_open(sftp_session sftp, const char *file, 
int flags,
 case SSH_FXP_HANDLE:
   handle = parse_handle_msg(msg);
   sftp_message_free(msg);
+  if ((flags & O_APPEND) == O_APPEND) {
+statData = sftp_stat(sftp, file);
+if (statData==NULL) {
+  sftp_close(handle);
+  return NULL;
+}
+if ((statData->flags & SSH_FILEXFER_ATTR_SIZE) != 
SSH_FILEXFER_ATTR_SIZE) {
+  ssh_set_error(sftp->session, SSH_FATAL, "Cannot open in append mode. 
Unknown file size.");
+  sftp_close(handle);
+  return NULL;
+}
+handle->offset = statData->size;
+  }
   return handle;
 default:
   ssh_set_error(sftp->session, SSH_FATAL,
-- 
2.9.0

From b2b1c02f828d07082847f851e270cc37ad66ee9f Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Fri, 1 Jul 2016 10:58:39 +0200
Subject: [PATCH 3/3] Add missing ifdef that prevented Windows builds

Signed-off-by: Tilo Eckert 
---
 src/session.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/session.c b/src/session.c
index 6885866..31bb2a7 100644
--- a/src/session.c
+++ b/src/session.c
@@ -270,7 +270,9 @@ void ssh_free(ssh_session session) {
   ssh_list_free(session->opts.identity);
   }
 
+#ifndef _WIN32
   ssh_agent_state_free (session->agent_state);
+#endif
   session->agent_state = NULL;
 
   SAFE_FREE(session->auth_auto_state);
-- 
2.9.0

Re: Fwd: how to delete a directory and its subdirectories with libssh ?

[Tilo Eckert]

Hi Stéphane

If I'm not mistaken, attributes->name contains only the file/directory
name. When you call your function recursively, you need to build the
full path and pass it to the recursive call. Currently, you attempt to
delete the directories from your working directory.

Regards
Tilo

Am 08.04.2016 um 22:58 schrieb Stéphane Lemoine:
> 
> 
> 
> Hi,
> 
> I cannot delete recursively a directory and its subdirectories,my
> function fails.
> I have a first function that delete all the files in the directory and
> its subdirectory.that first function is ok.
> my second function fails (it tries to delete the directories)
> -c++,qt,libssh-
> 
> 
> 
> boolsshobj::supprimerepserveur(QStringdestdir)
> 
> {
> 
> int rc;
> 
> char * p;
> 
>  char dat[1];
> 
>  bool res=true;
> 
>  p=destdir.toUtf8().data();
> 
>  strcpy(dat,p);
> 
> 
> sftp_dir dir;
> 
> sftp_attributes attributes;
> 
> 
> dir = sftp_opendir(m_sftp, dat);
> 
> if (!dir)
> 
> {
> 
> 
>   return false;
> 
> }
> 
> 
> while ((attributes = sftp_readdir(m_sftp, dir)) != NULL)
> 
> {
> 
> switch(attributes->type)
> 
> {
> 
> 
>  case SSH_FILEXFER_TYPE_DIRECTORY:
> 
>  {
> 
> QString 
> rep=QString::fromUtf8(attributes->name);
> 
> bool res2=supprimerepserveur(rep);
> 
> if (res2==false)
> 
> res=false;
> 
> 
> 
> break;
> 
> }
> 
> case SSH_FILEXFER_TYPE_REGULAR:
> 
> {
> 
> 
> 
> break;
> 
> }
> 
>  case SSH_FILEXFER_TYPE_SYMLINK:
> 
> {
> 
> break;
> 
> }
> 
>  case SSH_FILEXFER_TYPE_SPECIAL:
> 
> {
> 
> break;
> 
> }
> 
>  case SSH_FILEXFER_TYPE_UNKNOWN:{
> 
> break;
> 
> }
> 
> }
> 
> 
>sftp_attributes_free(attributes);
> 
> }
> 
> if (!sftp_dir_eof(dir))
> 
> {
> 
>   sftp_closedir(dir);
> 
>   
> 
> }
> 
> rc = sftp_closedir(dir);
> 
> rc = sftp_rmdir(m_sftp,dat);
> 
> 
> if(rc<0)
> 
>res=false;
> 
> return res;
> 
> 
> 
> 
> }
> 
> 
> do you have any idea ?
> 
> stéphane.
> 
> 

Re: ssh_user_auth_none Permission denied

[Tilo Eckert]

For SSH2, you must set the username before connecting via
  ssh_options_set(session, SSH_OPTIONS_USER, username);

The username parameter of ssh_userauth_try_publickey() and all other
functions must be NULL.

ssh_userauth_none() will never return SSH_AUTH_SUCCESS unless the SSH
server does not require any authentication at all. It is only useful to
query the available authentication methods and usually returns
SSH_AUTH_DENIED or SSH_AUTH_ERROR if there was a real error.

Best regards
Tilo

Am 18.03.2016 um 12:27 schrieb Sruthi Mohan (RBEI/EIA1):
> Dear All,
>  
> I am trying to connect to the server using ssh.
> I get  Access denied for ssh_user_auth_none. Authentication that can
> continue Public key
> As per ssh_userauth_list list PUBLIC KEY authentication is valid
>  
> Post that ssh_userauth_try_publickeyand ssh_pki_import_pubkey_filealso
> fails. Kindly let me know the possible reason failure
>  
>  
> Attached code below
>  
> intmain(intargc,char*argv[])
> {
> QCoreApplication a(argc, argv);
> ssh_session my_ssh_session;
> int verbosity = SSH_LOG_PROTOCOL;
> int port = 155;
> my_ssh_session = ssh_new();
> if (my_ssh_session == NULL)
> {
> exit(-1);
> }
> ssh_options_set(my_ssh_session, SSH_OPTIONS_HOST, myip);
> ssh_options_set(my_ssh_session, SSH_OPTIONS_LOG_VERBOSITY, &verbosity);
> ssh_options_set(my_ssh_session, SSH_OPTIONS_PORT, &port);
>  
>int rc = ssh_connect(my_ssh_session);
> if (rc != SSH_OK)
> {
> qDebug()<<"Error connecting tohost:"<   exit(-1);
> }
> rc=verify_knownhost(my_ssh_session);
> rc = ssh_userauth_none(my_ssh_session, NULL);
> if (rc != SSH_AUTH_SUCCESS) {
>qDebug()<<"Error connecting to localhost:
> %s\n" }
> int method = ssh_userauth_list(my_ssh_session, NULL);
>  
> if (method & SSH_AUTH_METHOD_NONE)
> {
> qDebug()<<"Authenticate None";
> }
> if (method & SSH_AUTH_METHOD_PUBLICKEY)
> {
> qDebug()<<"Authenticate pubkey";
> }
> if (method & SSH_AUTH_METHOD_INTERACTIVE)
> {
> qDebug()<<"Authenticate keyboard";
> }
> if (method & SSH_AUTH_METHOD_PASSWORD)
> {
> qDebug()<<"Authenticate password";
> }
>  
> if(ssh_pki_import_pubkey_file(PublickeyFile.toStdString().c_str(),&pubkey)!=SSH_OK)
> {
> qDebug()<<"Failed to import the key";
> }
> if(ssh_userauth_try_publickey(my_ssh_session,"S3DDM",pubkey)==SSH_ERROR)
> {
> qDebug()<<"Failed to import the key";
> }
>  
>  
> ssh_free(my_ssh_session);
> ssh_disconnect(my_ssh_session);
>  
> return a.exec();
> }
>  
>  
> Best regards
>  
> *Sruthi Mohan *
> *RBEI/EIA1*
>  
> Tel. +91(80)6783-7826
>  
>  

sftp_utimes() uses wrong subsecond unit

[Tilo Eckert]

Hi,

I think the subsecond handling in sftp_utimes() is wrong. It takes two
"struct timeval" as parameter which contain the tv_usec field. That
field is in microseconds. However, all the Xtime_nseconds fields of
sftp_attributes_struct are in nanoseconds. Hence, a multiplication by
1000 is missing.

Regards
Tilo

sftp_async_* and file offset

[Tilo Eckert]

Hi,

when reading files through the asynchronous SFTP methods, I see that you
update the file offset in sftp_async_read_begin(). Is there any specific
reason why you do it here and not in sftp_async_read()?

Due to this behavior, I am unable to use sftp_tell() in my read-ahead
implementation. Since I request multiple buffers in advance, the offset
stored in the sftp_file handle is always in the future as the requested
buffers have not been read, yet. Also, the offset may be set to values
beyond the end of the file.

Another thing that bugs me are the following lines in sftp_async_read():
  /* Update the offset with the correct value */
  file->offset = file->offset - (size - len);

This causes the difference of the size of the buffer passed as parameter
and the received data's length to be subtracted from offset. I guess
this is to fix the offset when reaching EOF? The problem is that the
value of file->offset will become invalid if a buffer is passed to the
function that is larger than the number of bytes requested (which is
fine according to the docs). It will cause the offset to illegally
decrease. When the buffer is more than twice the size of the original
request, the offset value would even go backwards. So, I guess this is a
bug.

My suggested fix is to replace this line by moving the offset+=len line
from sftp_async_read_begin().

Regards
Tilo

Re: SFTP read-ahead problem

[Tilo Eckert]

Hi,

eventually I took the time to dig into the packet processing code and
managed to find the bug that caused random "Short sftp packet!" errors.

When there are multiple pending read requests, the OpenSSH server stuffs
multiple SFTP data packets into one CHANNEL_DATA packet until 32KiB are
full. As a result, SFTP packets may be split and sent as payload of
multiple CHANNEL_DATA packets. At some point, the length field of the
SFTP packet will be the splitting point. This is what sftp_packet_read()
is unable to handle. It calls ssh_channel_read() with length 4 and
expects to get 4 bytes, which ssh_channel_read() does not guarantee. In
the split length field situation, less than 4 bytes are read which
results in the aforementioned error.

A patch is attached which reads the length field in a loop until 4 bytes
are read.

Tilo

Am 08.06.2015 um 13:09 schrieb Tilo Eckert:
> I used libssh 0.7.0 for my tests. The 0.6 branch from git has the same
> issue. Of the 0.6.x source tarballs none of them compiles here (ArchLinux).
> 
> Here is a verbose log where the sftp_close() does not get stuck (remote
> host, run with N=1024):
> https://paste.ee/p/A4N4i
> and here it gets stuck (same host/file, N=128):
> https://paste.ee/p/WoIeY
> 
> Regards,
> Tilo
> 
> Am 08.06.2015 um 12:04 schrieb Aris Adamantiadis:
>> Hi,
>>
>> I agree with your analysis. Which libssh version did you use ? Could you
>> try again with 0.6.0 and tell us if the same happens ?
>> Please attach verbose logs.
>>
>> Aris
>>
>> Le 08/06/15 11:46, Tilo Eckert a écrit :
>>> Hi,
>>>
>>> I am trying to implement a simple read-ahead mechanism for reading large
>>> files via SFTP using sftp_async_read_begin() and sftp_async_read(). On
>>> the first attempt to read a 4096 bytes block, I request N times 4K, and
>>> read the first 4K block. On successive reads, for each block read
>>> another one is requested to keep N requests on the wire.
>>>
>>> The problem is: sftp_async_read() suddenly fails with the error message
>>> "Short sftp packet!" after successfully reading a few hundred packets
>>> when N is large enough and the server is running OpenSSH. For a remote
>>> host over a 5 Mbit internet connection with 60ms latency, the issue
>>> starts when requesting more than about 70 blocks. In my tests on GBit
>>> LAN, the issue started for somewhat larger values of N.
>>>
>>> When I attempt to call sftp_async_read() or sftp_close() after the error
>>> occurs, I can see from the libssh log that all requests are actually
>>> fulfilled by the server (i.e. N * 4K are received by the socket). For
>>> certain combinations of N and network connection, calls to these
>>> functions also get stuck and never return. In other cases, closing fails
>>> with "Unknown packet type 0".
>>>
>>> Here is a sample program that demonstrates the issue:
>>> http://pastebin.com/gfiFKfDT
>>>
>>> I tested this with different OpenSSH versions between 6.0 and 6.8 on
>>> Windows and Linux, and with freeSSHd on Windows. With all OpenSSH
>>> versions, I get the described behavior. With freeSSHd, there are no
>>> issues at all. I successfully tested it with up to N=4096 (i.e. 16 MiB
>>> read-ahead).
>>>
>>> It looks to me like libssh starts to misinterpret packets under certain
>>> conditions. Maybe someone with deeper insight can investigate this.
>>>
>>> Regards,
>>> Tilo
>>>
>>
>>
> 
> 

From e0a3b56610ca35e2c24cc52b1efbe75b1b5479e2 Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Fri, 31 Jul 2015 13:22:02 +0200
Subject: sftp: Fix incorrect handling of received length fields

Signed-off-by: Tilo Eckert 
---
 src/sftp.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/src/sftp.c b/src/sftp.c
index 56093fb..39d0819 100644
--- a/src/sftp.c
+++ b/src/sftp.c
@@ -307,7 +307,7 @@ sftp_packet sftp_packet_read(sftp_session sftp) {
   sftp_packet packet = NULL;
   uint32_t tmp;
   size_t size;
-  int r;
+  int r, s;
 
   packet = malloc(sizeof(struct sftp_packet_struct));
   if (packet == NULL) {
@@ -322,12 +322,18 @@ sftp_packet sftp_packet_read(sftp_session sftp) {
 return NULL;
   }
 
-  r=ssh_channel_read(sftp->channel, buffer, 4, 0);
-  if (r < 0) {
-ssh_buffer_free(packet->payload);
-SAFE_FREE(packet);
-return NULL;
-  }
+  r=0;
+  do {
+// read from channel until 4 bytes have been read or an error occurs
+s=ssh_channel_read(sftp->channel, buffer+r, 4-r, 0);
+if (s < 0) {
+  ssh_buffer_free(packet->payload);
+  SAFE_FREE(packet);
+  return NULL;
+} else {
+  r += s;
+}
+  } while (r<4);
   ssh_buffer_add_data(packet->payload, buffer, r);
   if (buffer_get_u32(packet->payload, &tmp) != sizeof(uint32_t)) {
 ssh_set_error(sftp->session, SSH_FATAL, "Short sftp packet!");
-- 
2.5.0

Re: Double authentication using libssh

[Tilo Eckert]

Hi

if the server requires multiple authentication steps, the authentication
functions return SSH_AUTH_PARTIAL for any partial authentication step.
Only after the last step, SSH_AUTH_SUCCESS is returned, indicating
successful login.

Some notes on your implementation:
- You should set the username through ssh_options_set().
- You have no host key validation (aka known_hosts check). Without it,
you have no security at all.
- You release the session handle without disconnecting.
- Your main() never returns anything, but has return type int.

I suggest reading the tutorials about properly setting up an SSH
connection at:
http://api.libssh.org/master/libssh_tutorial.html

Regards,
Tilo

Am 29.07.2015 um 11:59 schrieb balasubramanian Achuthan:
> Hi All,
> 
> My SSH server uses double authtication. I do not know how its
> implemented. But initially its asks for a password, then again asks for
> another password to login to a separate console which is different from
> usual control.
> 
> My code is similar to the example code shown in the documentations,
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> 
> int main(int argc, char * argv[])
> {
> ssh_session my_ssh_session = ssh_new();
> int rc;
> char * password;
> char * username = "admin";
> // Check if ssh session exists.
> if(my_ssh_session == NULL)
> {
> exit(-1);
> }
> 
> ssh_options_set(my_ssh_session, SSH_OPTIONS_HOST, "x.x.x.x");
> 
> rc = ssh_connect(my_ssh_session);
> if (rc != SSH_OK)
> {
> fprintf(stderr, "Error Connecting to Server: %s.\n",
> ssh_get_error(my_ssh_session));
> exit(-1);
> }
> 
> password = getpass("Password: ");
> rc = ssh_userauth_password(my_ssh_session, username, password);
> if (rc != SSH_AUTH_SUCCESS)
> {
> fprintf(stderr, "ERROR Authenticating: %s.\n",
> ssh_get_error(my_ssh_session));
> ssh_disconnect(my_ssh_session);
> ssh_free(my_ssh_session);
> }
> else
> {
> printf("Authentication Successful.\n");
> }
> 
> ssh_free(my_ssh_session);
> }
> 
> How do i implement a double authtication in this ? can you kindly help
> me out ? 
> 
> Thanks,
> Bala.

Flag checking the bad way (+patch)

[Tilo Eckert]

Hi,

I compiled libssh on a non-Linux system where all the O_ and S_ file
flags are defined differently. The way libssh checks these flags results
in some unexpected behavior. File access modes are defined as:
  #define O_WRONLY 0x01
  #define O_RDONLY 0x02
  #define O_RDWR   0x03

The way mode flags are checked in sftp_open resulted in read-only and
write-only being translated to read-write. For flags which may have more
than one bit set, ANDing them with the variable and checking for
non-zero is not sufficient. Instead, the following pattern must be used
(which is always a good idea to use to avoid such platform-dependency
issues):
  if (((flags & FLAG) == FLAG))

Since the S_IF flags values are different too, sftp_parse_attr functions
failed to translate the types of files received by sftp_readdir.
Replacing all S_IF flags with own defines for platform-independence is a
good idea.

Patches for both are attached. Note that I only checked the SFTP module
for flags issues. Someone might want to look for other similar places.

Tilo
From 1a0b6de1b7e544b123132343e59e79028a4b7391 Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Wed, 22 Jul 2015 15:26:56 +0200
Subject: fix file mode checks in sftp_open()

Signed-off-by: Tilo Eckert 
---
 src/sftp.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/src/sftp.c b/src/sftp.c
index e925b52..ae7b7ef 100644
--- a/src/sftp.c
+++ b/src/sftp.c
@@ -1638,18 +1638,17 @@ sftp_file sftp_open(sftp_session sftp, const char 
*file, int flags,
   attr.permissions = mode;
   attr.flags = SSH_FILEXFER_ATTR_PERMISSIONS;
 
-  if (flags == O_RDONLY)
-sftp_flags |= SSH_FXF_READ; /* if any of the other flag is set,
-   READ should not be set initialy */
-  if (flags & O_WRONLY)
+  if ((flags & O_RDONLY) == O_RDONLY)
+sftp_flags |= SSH_FXF_READ;
+  if ((flags & O_WRONLY) == O_WRONLY)
 sftp_flags |= SSH_FXF_WRITE;
-  if (flags & O_RDWR)
+  if ((flags & O_RDWR) == O_RDWR)
 sftp_flags |= (SSH_FXF_WRITE | SSH_FXF_READ);
-  if (flags & O_CREAT)
+  if ((flags & O_CREAT) == O_CREAT)
 sftp_flags |= SSH_FXF_CREAT;
-  if (flags & O_TRUNC)
+  if ((flags & O_TRUNC) == O_TRUNC)
 sftp_flags |= SSH_FXF_TRUNC;
-  if (flags & O_EXCL)
+  if ((flags & O_EXCL) == O_EXCL)
 sftp_flags |= SSH_FXF_EXCL;
   SSH_LOG(SSH_LOG_PACKET,"Opening file %s with sftp flags %x",file,sftp_flags);
   id = sftp_get_new_id(sftp);
-- 
2.4.5

From ce313999b6fd4a85b7ed67ea0b3cf55ad6e676f0 Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Wed, 22 Jul 2015 15:24:14 +0200
Subject: define our own platform-independent S_IF macros

Signed-off-by: Tilo Eckert 
---
 include/libssh/sftp.h | 10 ++
 src/sftp.c| 40 
 2 files changed, 26 insertions(+), 24 deletions(-)

diff --git a/include/libssh/sftp.h b/include/libssh/sftp.h
index 8fb8f11..6620841 100644
--- a/include/libssh/sftp.h
+++ b/include/libssh/sftp.h
@@ -962,6 +962,16 @@ void sftp_handle_remove(sftp_session sftp, void *handle);
 #define SSH_FXF_EXCL 0x20
 #define SSH_FXF_TEXT 0x40
 
+/* file type flags */
+#define SSH_S_IFMT   0017
+#define SSH_S_IFSOCK 014
+#define SSH_S_IFLNK  012
+#define SSH_S_IFREG  010
+#define SSH_S_IFBLK  006
+#define SSH_S_IFDIR  004
+#define SSH_S_IFCHR  002
+#define SSH_S_IFIFO  001
+
 /* rename flags */
 #define SSH_FXF_RENAME_OVERWRITE  0x0001
 #define SSH_FXF_RENAME_ATOMIC 0x0002
diff --git a/src/sftp.c b/src/sftp.c
index ae7b7ef..56093fb 100644
--- a/src/sftp.c
+++ b/src/sftp.c
@@ -38,14 +38,6 @@
 #ifndef _WIN32
 #include 
 #include 
-#else
-#define S_IFSOCK 014
-#define S_IFLNK  012
-
-#ifdef _MSC_VER
-#define S_IFBLK  006
-#define S_IFIFO  001
-#endif
 #endif
 
 #include "libssh/priv.h"
@@ -1008,20 +1000,20 @@ static sftp_attributes sftp_parse_attr_4(sftp_session 
sftp, ssh_buffer buf,
   attr->permissions = ntohl(attr->permissions);
 
   /* FIXME on windows! */
-  switch (attr->permissions & S_IFMT) {
-case S_IFSOCK:
-case S_IFBLK:
-case S_IFCHR:
-case S_IFIFO:
+  switch (attr->permissions & SSH_S_IFMT) {
+case SSH_S_IFSOCK:
+case SSH_S_IFBLK:
+case SSH_S_IFCHR:
+case SSH_S_IFIFO:
   attr->type = SSH_FILEXFER_TYPE_SPECIAL;
   break;
-case S_IFLNK:
+case SSH_S_IFLNK:
   attr->type = SSH_FILEXFER_TYPE_SYMLINK;
   break;
-case S_IFREG:
+case SSH_S_IFREG:
   attr->type = SSH_FILEXFER_TYPE_REGULAR;
   break;
-case S_IFDIR:
+case SSH_S_IFDIR:
   attr->type = SSH_FILEXFER_TYPE_DIRECTORY;
   break;
 default:
@@ -1244,20 +1236,20 @@ static sftp_attributes sftp_parse_attr_3(sftp_session 
sftp, ssh_buffer buf,
 goto error;
 

Re: SFTP read-ahead problem

[Tilo Eckert]

Any idea what might cause this strange behavior when doing read-ahead?

Am 08.06.2015 um 13:09 schrieb Tilo Eckert:
> I used libssh 0.7.0 for my tests. The 0.6 branch from git has the same
> issue. Of the 0.6.x source tarballs none of them compiles here (ArchLinux).
> 
> Here is a verbose log where the sftp_close() does not get stuck (remote
> host, run with N=1024):
> https://paste.ee/p/A4N4i
> and here it gets stuck (same host/file, N=128):
> https://paste.ee/p/WoIeY
> 
> Regards,
> Tilo
> 
> Am 08.06.2015 um 12:04 schrieb Aris Adamantiadis:
>> Hi,
>>
>> I agree with your analysis. Which libssh version did you use ? Could you
>> try again with 0.6.0 and tell us if the same happens ?
>> Please attach verbose logs.
>>
>> Aris
>>
>> Le 08/06/15 11:46, Tilo Eckert a écrit :
>>> Hi,
>>>
>>> I am trying to implement a simple read-ahead mechanism for reading large
>>> files via SFTP using sftp_async_read_begin() and sftp_async_read(). On
>>> the first attempt to read a 4096 bytes block, I request N times 4K, and
>>> read the first 4K block. On successive reads, for each block read
>>> another one is requested to keep N requests on the wire.
>>>
>>> The problem is: sftp_async_read() suddenly fails with the error message
>>> "Short sftp packet!" after successfully reading a few hundred packets
>>> when N is large enough and the server is running OpenSSH. For a remote
>>> host over a 5 Mbit internet connection with 60ms latency, the issue
>>> starts when requesting more than about 70 blocks. In my tests on GBit
>>> LAN, the issue started for somewhat larger values of N.
>>>
>>> When I attempt to call sftp_async_read() or sftp_close() after the error
>>> occurs, I can see from the libssh log that all requests are actually
>>> fulfilled by the server (i.e. N * 4K are received by the socket). For
>>> certain combinations of N and network connection, calls to these
>>> functions also get stuck and never return. In other cases, closing fails
>>> with "Unknown packet type 0".
>>>
>>> Here is a sample program that demonstrates the issue:
>>> http://pastebin.com/gfiFKfDT
>>>
>>> I tested this with different OpenSSH versions between 6.0 and 6.8 on
>>> Windows and Linux, and with freeSSHd on Windows. With all OpenSSH
>>> versions, I get the described behavior. With freeSSHd, there are no
>>> issues at all. I successfully tested it with up to N=4096 (i.e. 16 MiB
>>> read-ahead).
>>>
>>> It looks to me like libssh starts to misinterpret packets under certain
>>> conditions. Maybe someone with deeper insight can investigate this.
>>>
>>> Regards,
>>> Tilo
>>>
>>
>>
> 
> 

Re: Public key authentication bugs

[Tilo Eckert]

Hi,

as requested, here is a resubmit of my properly signed patches (original
mails quoted below).

Certificate of Origin was sent separately to contribut...@libssh.org.

Regards
Tilo

Am 11.06.2015 um 16:50 schrieb Tilo Eckert:
> Hi,
> 
> I found two related bugs when trying to authenticate with
> ssh_userauth_publickey_auto() against an OpenSSH server that is
> configured to require public key authentication followed by password
> authentication, i.e. sshd_config contains the line:
> AuthenticationMethods publickey,password
> 
> Bug #1: ssh_userauth_publickey_auto() does not handle the
> SSH_AUTH_PARTIAL return code after the call to ssh_userauth_publickey()
> and therefore behaves like we had sent a bad signature that does not
> match the offered public key. So instead of SSH_AUTH_PARTIAL,
> SSH_AUTH_DENIED is returned.
> 
> Bug #2: Due to Bug #1, session->auth_auto_state was free'd because
> ssh_userauth_publickey() returned SSH_AUTH_PARTIAL, but none of the
> following ifs handled its return code. The following access to the
> 'state' variable is a use-after-free, resulting in memory corruption (in
> my case ssh_disconnect() segfaulted). So, this one is probably security
> related.
> 
> I attached a patch that fixes both bugs.
> 
> Regards,
> Tilo
> 

Am 15.06.2015 um 13:28 schrieb Tilo Eckert:
> Hi,
> 
> when calling ssh_userauth_list() after a successful partial
> authentication (e.g. public key) and another authentication method (e.g.
> password) is required next by the server, only the
> SSH_AUTH_METHOD_PASSWORD flag should be set. However, the
> SSH_AUTH_METHOD_PUBLICKEY flag is also set, even though it is not
> acceptable in the current state.
> 
> The auth_methods field in the session is reset after a failed
> authentication attempt, but not after a partial one. The attached patch
> changes it to be reset in both cases.
> 
> Regards,
> Tilo

>From d3e7868f34cffaf39fa6607cfe3c1f72242826cd Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Mon, 15 Jun 2015 13:12:23 +0200
Subject: [PATCH] available auth_methods must be reset on partial
 authentication

Signed-off-by: Tilo Eckert 
---
 src/auth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/auth.c b/src/auth.c
index da8c4d9..77b99a7 100755
--- a/src/auth.c
+++ b/src/auth.c
@@ -209,8 +209,8 @@ SSH_PACKET_CALLBACK(ssh_packet_userauth_failure){
 "Access denied. Authentication that can continue: %s",
 auth_methods);
 
-session->auth_methods = 0;
   }
+  session->auth_methods = 0;
   if (strstr(auth_methods, "password") != NULL) {
 session->auth_methods |= SSH_AUTH_METHOD_PASSWORD;
   }
-- 
2.4.3

>From ecc579cf777a05807d61da2f959851159a443d8d Mon Sep 17 00:00:00 2001
From: Tilo Eckert 
Date: Thu, 11 Jun 2015 16:43:27 +0200
Subject: [PATCH] SSH_AUTH_PARTIAL is now correctly passed to the caller of
 ssh_userauth_publickey_auto().

Implicitly fixed unsafe return code handling that could result in 
use-after-free.

Signed-off-by: Tilo Eckert 
---
 src/auth.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)
 mode change 100644 => 100755 src/auth.c

diff --git a/src/auth.c b/src/auth.c
old mode 100644
new mode 100755
index 20cac90..da8c4d9
--- a/src/auth.c
+++ b/src/auth.c
@@ -1045,15 +1045,14 @@ int ssh_userauth_publickey_auto(ssh_session session,
 ssh_key_free(state->privkey);
 ssh_key_free(state->pubkey);
 SAFE_FREE(session->auth_auto_state);
-}
-if (rc == SSH_AUTH_ERROR) {
-return rc;
-} else if (rc == SSH_AUTH_SUCCESS) {
-SSH_LOG(SSH_LOG_INFO,
-"Successfully authenticated using %s",
-privkey_file);
+if (rc == SSH_AUTH_SUCCESS) {
+SSH_LOG(SSH_LOG_INFO,
+"Successfully authenticated using %s",
+privkey_file);
+}
 return rc;
-} else if (rc == SSH_AUTH_AGAIN){
+}
+if (rc == SSH_AUTH_AGAIN){
 return rc;
 }
 
-- 
2.4.3

ssh_userauth_list() returns incorrect list after partial auth

[Tilo Eckert]

Hi,

when calling ssh_userauth_list() after a successful partial
authentication (e.g. public key) and another authentication method (e.g.
password) is required next by the server, only the
SSH_AUTH_METHOD_PASSWORD flag should be set. However, the
SSH_AUTH_METHOD_PUBLICKEY flag is also set, even though it is not
acceptable in the current state.

The auth_methods field in the session is reset after a failed
authentication attempt, but not after a partial one. The attached patch
changes it to be reset in both cases.

Regards,
Tilo
From f27b745b7417c0606807c5014eb4fbe0c0433f2e Mon Sep 17 00:00:00 2001
From: tilo 
Date: Mon, 15 Jun 2015 13:12:23 +0200
Subject: [PATCH 1/1] available auth_methods must be reset on partial
 authentication

---
 src/auth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/auth.c b/src/auth.c
index da8c4d9..77b99a7 100755
--- a/src/auth.c
+++ b/src/auth.c
@@ -209,8 +209,8 @@ SSH_PACKET_CALLBACK(ssh_packet_userauth_failure){
 "Access denied. Authentication that can continue: %s",
 auth_methods);
 
-session->auth_methods = 0;
   }
+  session->auth_methods = 0;
   if (strstr(auth_methods, "password") != NULL) {
 session->auth_methods |= SSH_AUTH_METHOD_PASSWORD;
   }
-- 
2.4.3

Public key authentication bugs

[Tilo Eckert]

Hi,

I found two related bugs when trying to authenticate with
ssh_userauth_publickey_auto() against an OpenSSH server that is
configured to require public key authentication followed by password
authentication, i.e. sshd_config contains the line:
AuthenticationMethods publickey,password

Bug #1: ssh_userauth_publickey_auto() does not handle the
SSH_AUTH_PARTIAL return code after the call to ssh_userauth_publickey()
and therefore behaves like we had sent a bad signature that does not
match the offered public key. So instead of SSH_AUTH_PARTIAL,
SSH_AUTH_DENIED is returned.

Bug #2: Due to Bug #1, session->auth_auto_state was free'd because
ssh_userauth_publickey() returned SSH_AUTH_PARTIAL, but none of the
following ifs handled its return code. The following access to the
'state' variable is a use-after-free, resulting in memory corruption (in
my case ssh_disconnect() segfaulted). So, this one is probably security
related.

I attached a patch that fixes both bugs.

Regards,
Tilo
From 69a1f2a1bb7b53e4faf582056b4576f6c07fe743 Mon Sep 17 00:00:00 2001
From: tilo 
Date: Thu, 11 Jun 2015 16:43:27 +0200
Subject: [PATCH 1/1] SSH_AUTH_PARTIAL is now correctly passed to the caller +
 fix for inherently unsafe return code handling

---
 src/auth.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)
 mode change 100644 => 100755 src/auth.c

diff --git a/src/auth.c b/src/auth.c
old mode 100644
new mode 100755
index 20cac90..da8c4d9
--- a/src/auth.c
+++ b/src/auth.c
@@ -1045,15 +1045,14 @@ int ssh_userauth_publickey_auto(ssh_session session,
 ssh_key_free(state->privkey);
 ssh_key_free(state->pubkey);
 SAFE_FREE(session->auth_auto_state);
-}
-if (rc == SSH_AUTH_ERROR) {
-return rc;
-} else if (rc == SSH_AUTH_SUCCESS) {
-SSH_LOG(SSH_LOG_INFO,
-"Successfully authenticated using %s",
-privkey_file);
+if (rc == SSH_AUTH_SUCCESS) {
+SSH_LOG(SSH_LOG_INFO,
+"Successfully authenticated using %s",
+privkey_file);
+}
 return rc;
-} else if (rc == SSH_AUTH_AGAIN){
+}
+if (rc == SSH_AUTH_AGAIN){
 return rc;
 }
 
-- 
2.4.2

Re: SFTP read-ahead problem

[Tilo Eckert]

I used libssh 0.7.0 for my tests. The 0.6 branch from git has the same
issue. Of the 0.6.x source tarballs none of them compiles here (ArchLinux).

Here is a verbose log where the sftp_close() does not get stuck (remote
host, run with N=1024):
https://paste.ee/p/A4N4i
and here it gets stuck (same host/file, N=128):
https://paste.ee/p/WoIeY

Regards,
Tilo

Am 08.06.2015 um 12:04 schrieb Aris Adamantiadis:
> Hi,
> 
> I agree with your analysis. Which libssh version did you use ? Could you
> try again with 0.6.0 and tell us if the same happens ?
> Please attach verbose logs.
> 
> Aris
> 
> Le 08/06/15 11:46, Tilo Eckert a écrit :
>> Hi,
>>
>> I am trying to implement a simple read-ahead mechanism for reading large
>> files via SFTP using sftp_async_read_begin() and sftp_async_read(). On
>> the first attempt to read a 4096 bytes block, I request N times 4K, and
>> read the first 4K block. On successive reads, for each block read
>> another one is requested to keep N requests on the wire.
>>
>> The problem is: sftp_async_read() suddenly fails with the error message
>> "Short sftp packet!" after successfully reading a few hundred packets
>> when N is large enough and the server is running OpenSSH. For a remote
>> host over a 5 Mbit internet connection with 60ms latency, the issue
>> starts when requesting more than about 70 blocks. In my tests on GBit
>> LAN, the issue started for somewhat larger values of N.
>>
>> When I attempt to call sftp_async_read() or sftp_close() after the error
>> occurs, I can see from the libssh log that all requests are actually
>> fulfilled by the server (i.e. N * 4K are received by the socket). For
>> certain combinations of N and network connection, calls to these
>> functions also get stuck and never return. In other cases, closing fails
>> with "Unknown packet type 0".
>>
>> Here is a sample program that demonstrates the issue:
>> http://pastebin.com/gfiFKfDT
>>
>> I tested this with different OpenSSH versions between 6.0 and 6.8 on
>> Windows and Linux, and with freeSSHd on Windows. With all OpenSSH
>> versions, I get the described behavior. With freeSSHd, there are no
>> issues at all. I successfully tested it with up to N=4096 (i.e. 16 MiB
>> read-ahead).
>>
>> It looks to me like libssh starts to misinterpret packets under certain
>> conditions. Maybe someone with deeper insight can investigate this.
>>
>> Regards,
>> Tilo
>>
> 
> 

SFTP read-ahead problem

[Tilo Eckert]

Hi,

I am trying to implement a simple read-ahead mechanism for reading large
files via SFTP using sftp_async_read_begin() and sftp_async_read(). On
the first attempt to read a 4096 bytes block, I request N times 4K, and
read the first 4K block. On successive reads, for each block read
another one is requested to keep N requests on the wire.

The problem is: sftp_async_read() suddenly fails with the error message
"Short sftp packet!" after successfully reading a few hundred packets
when N is large enough and the server is running OpenSSH. For a remote
host over a 5 Mbit internet connection with 60ms latency, the issue
starts when requesting more than about 70 blocks. In my tests on GBit
LAN, the issue started for somewhat larger values of N.

When I attempt to call sftp_async_read() or sftp_close() after the error
occurs, I can see from the libssh log that all requests are actually
fulfilled by the server (i.e. N * 4K are received by the socket). For
certain combinations of N and network connection, calls to these
functions also get stuck and never return. In other cases, closing fails
with "Unknown packet type 0".

Here is a sample program that demonstrates the issue:
http://pastebin.com/gfiFKfDT

I tested this with different OpenSSH versions between 6.0 and 6.8 on
Windows and Linux, and with freeSSHd on Windows. With all OpenSSH
versions, I get the described behavior. With freeSSHd, there are no
issues at all. I successfully tested it with up to N=4096 (i.e. 16 MiB
read-ahead).

It looks to me like libssh starts to misinterpret packets under certain
conditions. Maybe someone with deeper insight can investigate this.

Regards,
Tilo