Re: Authentication via none is blocking thread.

[Jakub Jelen]

Hi,
The `ssh_userauth_none()` should work when the session is set to
non-blocking. On the first sight I do not see any significant
difference from other authentication functions. Do you have a
backtrace, where the code is blocking? Do you have a minimal
reproducer? What is the server?

Jakub

On Mon, Jun 10, 2024 at 8:42 AM Bhautik Radadiya
 wrote:
>
> Hi All,
> Hope you all are well and doing well.
> I am facing authentication issue sometimes when we are trying to authenticate 
> via ssh_userauth_none
> and it blocks the thread and we never gets the handle back to thread.
>
> 1. What could be the problem?
> 2. Is ssh_userauth_none is blocking API??
> 3. Is there any alternate API to authenticate via none??
>
> Please let me know if i am missing something or any information you need from 
> me.
> Thanks in advance for your help.
>
> Regards
> Bhautik
>

Re: Trying to build libssh

[Jakub Jelen]

Hi,
you seems to have some non-standard OpenSSL version installed. There
is a patch (already part of master) that detects the FIPS_mode() macro
and gracefully falls back if not found:

https://gitlab.com/libssh/libssh-mirror/-/commit/0d4658740b4a7f94cdbbfaa6d4d7dbc047660d4c

If it will work for you, I will backport it to th 0.10.x branch for a
next release.

Jakub

On Sun, Jun 2, 2024 at 9:11 AM Mikael Petterson
 wrote:
>
> Hi,
>
> I am trying to build libssh 0.10.6 from source.
>
> I am using:
>
> git clone https://git.libssh.org/projects/libssh.git && cd libssh && git 
> checkout tags/libssh-0.10.6 && \
>
>   mkdir build && cd build && \
>
>   cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE="Release" 
> -DWITH_ZLIB=ON -DWITH_GSSAPI=OFF -DWITH_NACL=OFF -DWITH_PCAP=OFF 
> -DWITH_SERVER=OFF -DOPENSSL_ROOT_DIR=/usr/local/openssl .. && \
>
>   make -j2 && \
>
>   make install
>
>
>
>
>
> I get this error:
>
>
> 12.90 -- Build files have been written to: /opt/dev/libssh/build
>
> 13.02 Scanning dependencies of target ssh
>
> 13.06 [  1%] Building C object src/CMakeFiles/ssh.dir/agent.c.o
>
> 13.06 [  2%] Building C object src/CMakeFiles/ssh.dir/auth.c.o
>
> 13.44 [  3%] Building C object src/CMakeFiles/ssh.dir/base64.c.o
>
> 13.59 [  4%] Building C object src/CMakeFiles/ssh.dir/bignum.c.o
>
> 13.64 [  5%] Building C object src/CMakeFiles/ssh.dir/buffer.c.o
>
> 13.77 [  6%] Building C object src/CMakeFiles/ssh.dir/callbacks.c.o
>
> 13.97 [  7%] Building C object src/CMakeFiles/ssh.dir/channels.c.o
>
> 14.17 [  8%] Building C object src/CMakeFiles/ssh.dir/client.c.o
>
> 14.49 [  9%] Building C object src/CMakeFiles/ssh.dir/config.c.o
>
> 15.22 [ 10%] Building C object src/CMakeFiles/ssh.dir/connect.c.o
>
> 15.68 [ 11%] Building C object src/CMakeFiles/ssh.dir/connector.c.o
>
> 15.79 [ 12%] Building C object src/CMakeFiles/ssh.dir/crypto_common.c.o
>
> 15.98 [ 13%] Building C object src/CMakeFiles/ssh.dir/curve25519.c.o
>
> 16.01 [ 13%] Building C object src/CMakeFiles/ssh.dir/dh.c.o
>
> 16.32 [ 14%] Building C object src/CMakeFiles/ssh.dir/ecdh.c.o
>
> 16.41 [ 15%] Building C object src/CMakeFiles/ssh.dir/error.c.o
>
> 16.56 [ 16%] Building C object src/CMakeFiles/ssh.dir/getpass.c.o
>
> 16.65 [ 17%] Building C object src/CMakeFiles/ssh.dir/init.c.o
>
> 16.73 [ 18%] Building C object src/CMakeFiles/ssh.dir/kdf.c.o
>
> 16.83 [ 19%] Building C object src/CMakeFiles/ssh.dir/kex.c.o
>
> 16.96 In file included from /opt/dev/libssh/include/libssh/wrapper.h:28:0,
>
> 16.96  from /opt/dev/libssh/include/libssh/crypto.h:36,
>
> 16.96  from /opt/dev/libssh/include/libssh/dh.h:26,
>
> 16.96  from /opt/dev/libssh/src/kex.c:34:
>
> 16.96 /opt/dev/libssh/src/kex.c: In function 'ssh_client_select_hostkeys':
>
> 16.96 /opt/dev/libssh/include/libssh/libcrypto.h:107:26: error: implicit 
> declaration of function 'FIPS_mode' [-Werror=implicit-function-declaration]
>
> 16.96  #define ssh_fips_mode() (FIPS_mode() != 0)
>
> 16.96   ^
>
> 16.96 /opt/dev/libssh/src/kex.c:680:13: note: in expansion of macro 
> 'ssh_fips_mode'
>
> 16.96  if (ssh_fips_mode()) {
>
> 16.96  ^
>
> 16.98 [ 20%] Building C object src/CMakeFiles/ssh.dir/known_hosts.c.o
>
> 17.34 [ 21%] Building C object src/CMakeFiles/ssh.dir/knownhosts.c.o
>
> 17.35 cc1: some warnings being treated as errors
>
> 17.37 src/CMakeFiles/ssh.dir/build.make:518: recipe for target 
> 'src/CMakeFiles/ssh.dir/kex.c.o' failed
>
> 17.37 make[2]: *** [src/CMakeFiles/ssh.dir/kex.c.o] Error 1
>
> 17.37 make[2]: *** Waiting for unfinished jobs
>
> 17.59 CMakeFiles/Makefile2:203: recipe for target 
> 'src/CMakeFiles/ssh.dir/all' failed
>
> 17.60 Makefile:151: recipe for target 'all' failed
>
> 17.60 make[1]: *** [src/CMakeFiles/ssh.dir/all] Error 2
>
> 17.60 make: *** [all] Error 2
>
>
>
>
>
> Any ideas?
>
>
>
> //mike

Re: tutorial/example sftp in non blocking mode

[Jakub Jelen]

Hi.
The naming is hard. The sftp_async_read was mostly PoC API, but not to
support non-blocking operation, but asynchronous file transfer (that
means having several in-flight requests instead of busily waiting for
the first one to arrive). This was deprecated in favor of the
sftp_aio_* API as described in the tutorial, which should be available
in the next release due in coming months so if you have some feedback,
it would be hugely appreciated:

https://api.libssh.org/master/libssh_tutor_sftp_aio.html

As already mentioned, the nonblocking operation of SFTP is still not
supported. As far as I can see, it would need to rewrite all of the
sftp functions to support returning SSH_AGAIN instead of waiting,
possibly with some API changes as some of the functions do not return
status, but just the allocated objects.

Jakub

On Tue, May 14, 2024 at 12:50 AM  wrote:
>
> On Mon, 2024-05-13 at 18:15 -0400, reid.thomp...@crunchydata.com wrote:
> > On Mon, 2024-05-13 at 11:50 -0700, Norm Green wrote:
> > > sftp is broken in nonblocking mode. Only ssh works.
> > >
> > > See: https://gitlab.com/libssh/libssh-mirror/-/issues/58
> > >
> > > Norm Green
> > >
> > >
> > Thanks,
> >
> > so at this time, sftp is blocking only?
> >
> > And it looks like sftp_async_read* have been deprecated.
>
> So, I want to follow up on this, it appears that sftp_async_read* have been
> marked as deprecated, but the sftp tutorial still has a section describing
> non-blocking asynchronous reading via this mechanism.
> Is this method broken, or just deprecated in anticipation of a better
> implementation in the future?
>
> >
> > Looks like there may be work going on in master to support non-
> > blocking?
> >
> > Reid
>
>
>

Re: GSoC Project: Integrating FIDO/U2F key support in libssh

[Jakub Jelen]

Hello and welcome!

On Wed, Mar 27, 2024 at 4:44 PM Diego Roux  wrote:
>
> Hello everyone,
>
> I am reaching out to express my interest in participating in the GSoC program 
> with libssh. Having worked with webauthn previously and the U2F/CTAP 
> specification, implementing a virtual FIDO device, bringing support for these 
> devices to libssh, quickly caught my eye.

I think this is certainly a useful experience for this project!

> I am proficient in C, and posses knowledge of ECC.
>
> I'll be sharing my full proposal, quite soon; I'll appreciate any and all 
> feedback; in short: I plan to bring support for U2F (CTAP1) and CTAP2 keys 
> for libssh, in an efficient and seamless way.

So far we were planning to approach the testing the same way the
OpenSSH developers did, but we are open to your suggestion if there is
a reasonable implementation of virtual FIDO devices.

> I’ve also done my code contribution (small one),
> (https://gitlab.com/libssh/libssh-mirror/-/merge_requests/476) if it’s below 
> of what’s deemed necessary/appropriate, I’ll be more than happy to contribute 
> more, at whatever I’m directed at.

I think this will need some more work, but lets discuss in the MR itself.

Jakub

Re: Specifying GSSAPI settings

[Jakub Jelen]

Hi,
thank you for the question! Unfortunately the GSSAPI code in libssh is
not very well tested so if you are interested in changing that, we
could use some help:
https://gitlab.com/libssh/libssh-mirror/-/issues/191

We are working on the implementation of proxyjump using libssh in
https://gitlab.com/libssh/libssh-mirror/-/merge_requests/459 (it will
likely need some more work though) so I assume you took some similar
approach for doing this just with the public API for the port
forwarding, which has a disadvantage you need to allocate the port
numbers locally instead of keeping the socket inside of your
application. In any case, feedback here would be hugely appreciated as
this sounds like something very similar you are working on for
real-world use case.

I think this is the limitation of the forwarding as there is no simple
way to derive the hostname from the locally forwarded port so it needs
to be managed manually for now. I think cleaner way might be using
`SSH_OPTIONS_GSSAPI_SERVER_IDENTITY` similar to the openssh
configuration option.

Jakub


On Sat, Mar 9, 2024 at 11:08 PM James Wrigley  wrote:
>
> After a bit more digging I realized that the only necessary thing is to set 
> the server identify because the realm can be obtained from that. From looking 
> at the code I think that should be done in ssh_gssapi_auth_mic(), but I 
> figured out a hack to get around it  If you set the host option to the real 
> hostname after connecting, ssh_gssapi_auth_mic() will just use that in its 
> call to gss_import_name() and GSSAPI auth works as usual. Not sure how kosher 
> that is...
>
> On Sat, Mar 9, 2024, 1:54 AM James Wrigley  wrote:
>>
>> Hi there,
>> I'm writing a program that needs to access a remote host through two jump 
>> hosts. The way I'm doing that is by connecting to each hop in the chain, 
>> creating a direct forwarding channel to port 22 of the next hop, and then 
>> connecting to the forwarded port for the next hop.
>>
>> My problem is that I want to use GSSAPI authentication for each hop, but 
>> that breaks on the forwarded ports. At first when I called userauth_gssapi() 
>> I got this in the logs:
>>
>> [2024/03/09 01:03:27.614606, 1] ssh_gssapi_log_error:  
>> GSSAPI(Initializing gssapi context): Unspecified GSS failure.  Minor code 
>> may provide more information - Configuration file does not specify default 
>> realm
>>
>> After setting a default realm in my krb5.conf I get:
>>
>> [2024/03/09 01:46:56.109448, 1] ssh_gssapi_log_error:  
>> GSSAPI(Initializing gssapi context): Unspecified GSS failure.  Minor code 
>> may provide more information - Server not found in Kerberos database
>>
>> Then I tried ssh'ing on the forwarded port using OpenSSH and got GSSAPI auth 
>> working by passing `-o GSSAPIServerIdentity=...`.
>>
>> So my question is, how can I specify the realm and server identity with 
>> libssh? Ideally the program wouldn't require the user to modify their 
>> krb5.conf or have to fall back to another auth method like password auth. 
>> This works OOTB with OpenSSH and ProxyJump's, so I assume OpenSSH uses the 
>> realm and server identity of the jump hosts when connecting to their 
>> forwarded port.
>>
>> Thanks,
>> James

Re: CVE-2023-6918: removal of unused evp functions & types

[Jakub Jelen]

Hi,
This CVE is about checking return code from the crypto library API
calls, which could fail and cause some unexpected behavior such as
usage of uninitialized memory, DoS, ... Our analysis did not show any
important exploitable code path (but it was in supported libssh
versions -- this might not be the case in older ones!).

The removed functions evp, evp_update, evp_final all return void so
they are not fixable with current singature. As always, we recommend
to update to the supported libssh version which has this fix already
backported. If you really need to use older libssh version, you will
likely have to fix these functions by
 * checking crypto library API calls results in these functions
 * returning the meaningful result from these functions
 * checking the return values from these evp() functions

In any case, if you do the backports anyway and you want somebody to
have a look into them, opening a merge request on gitlab would be
best. More eyes will see more issues and if there are more people
interested in these patches, it might save somebody some more time. We
can accept the changes, but we will likely not do release though.

Best regards,
Jakub Jelen

On Sun, Feb 25, 2024 at 6:17 AM Sean Whitton  wrote:
>
> Hello,
>
> Thank you again for the information in January regarding backporting the
> fix for CVE-2023-48795 to older libssh.  I am now working to backport
> the fix for CVE-2023-6918, and have a quick question.
> There is a commit labelled
>
> CVE-2023-6918: Remove unused evp functions and types
>
> but this is non-trivial to backport because the functions are not unused
> in the older libssh.  My question is, is there a security concern with
> these functions, or was this commit just tidying up?
>
> I'm asking because the commit message is prefixed with the CVE number,
> which makes me think it might be significant for the vulnerability.
>
> Thanks!
>
> --
> Sean Whitton

Re: CVE-2023-6918: removal of unused evp functions & types

[Jakub Jelen]

Hi,
This CVE is about checking return code from the crypto library API
calls, which could fail and cause some unexpected behavior such as
usage of uninitialized memory, DoS, ... Our analysis did not show any
important exploitable code path (but it was in supported libssh
versions -- this might not be the case in older ones!).

The removed functions evp, evp_update, evp_final all return void so
they are not fixable with current singature. As always, we recommend
to update to the supported libssh version which has this fix already
backported. If you really need to use older libssh version, you will
likely have to fix these functions by
 * checking crypto library API calls results in these functions
 * returning the meaningful result from these functions
 * checking the return values from these evp() functions

In any case, if you do the backports anyway and you want somebody to
have a look into them, opening a merge request on gitlab would be
best. More eyes will see more issues and if there are more people
interested in these patches, it might save somebody some more time. We
can accept the changes, but we will likely not do release though.

Best regards,
Jakub Jelen

On Sun, Feb 25, 2024 at 6:17 AM Sean Whitton  wrote:
>
> Hello,
>
> Thank you again for the information in January regarding backporting the
> fix for CVE-2023-48795 to older libssh.  I am now working to backport
> the fix for CVE-2023-6918, and have a quick question.
> There is a commit labelled
>
> CVE-2023-6918: Remove unused evp functions and types
>
> but this is non-trivial to backport because the functions are not unused
> in the older libssh.  My question is, is there a security concern with
> these functions, or was this commit just tidying up?
>
> I'm asking because the commit message is prefixed with the CVE number,
> which makes me think it might be significant for the vulnerability.
>
> Thanks!
>
> --
> Sean Whitton

Re: SSH Key exchange (Kex error)

[Jakub Jelen]

Hi,
if this is with the following option applied, it does not sounds like working:

ssh_option_set (my_session, SSH_OPTIONS_KEY_EXCHANGE,
"diffie-hellman-group14-sha1");

check if there is no other line in the code that would set the
highlighted kex options or if there is no configuration file that
would override this.

Jakub

On Thu, Feb 1, 2024 at 11:11 AM Bhautik Radadiya
 wrote:
>
> Hi,
> We added that log verbose option but not able to see session logs, but
>
> This exception in image might help you to understand issue.
>  We are getting it even after adding that set option line which i mentioned 
> earlier.
>
> Thanks
> Bhautik
>
> On Thu, Feb 1, 2024, 2:47 PM Jakub Jelen  wrote:
>>
>> Please, provide debug log from the libssh session:
>>
>> int verbosity = 4;
>> ssh_options_set(session, SSH_OPTIONS_LOG_VERBOSITY, );
>>
>> The OpenSSH command you used adds this option to some list, while the
>> libssh operation limits the kex algorithms to this single algorithm.
>> The verbose log as mentioned above will show you what the server
>> supports.
>>
>> Jakub
>>
>> On Wed, Jan 31, 2024 at 1:26 PM Bhautik Radadiya
>>  wrote:
>> >
>> > Yes, we tried through manual ssh command like below, and we are into the 
>> > devide.
>> >
>> > ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 Device_ip -p Port
>> >
>> > Not sure what's stopping us through libssh.
>> >
>> > Thanks
>> > Bhautik
>> >
>> > On Wed, Jan 31, 2024, 5:38 PM Andreas Schneider  
>> > wrote:
>> >>
>> >> On Wednesday, 31 January 2024 11:31:53 CET Bhautik Radadiya wrote:
>> >> > Hi,
>> >>
>> >> Hi,
>> >>
>> >> > Hope you all are well!
>> >> > I am facing this (kex error : no match for method kex algos) issue in my
>> >> > application while trying to connect to device.
>> >> > I am using libssh 0.9.5.
>> >> > I added this below line in my sshlib file but not working it.
>> >> >
>> >> > ssh_option_set (my_session, SSH_OPTIO NS_KEY_EXCHANGE,
>> >> > "diffie-hellman-group14-sha1");
>> >> >
>> >> > Can you please help me with this? Or Can you please provide some 
>> >> > guidance.
>> >> > It will be great help.
>> >>
>> >>
>> >> are you sure that the device supports this kex?
>> >>
>> >> Did you enable verbose logging and check what the server returns?
>> >>
>> >>
>> >> Best regards
>> >>
>> >>
>> >> Andreas
>> >>
>> >> --
>> >> Andreas Schneider a...@cryptomilk.org
>> >> GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
>> >>
>> >>
>>
>>

Re: SSH Key exchange (Kex error)

[Jakub Jelen]

Please, provide debug log from the libssh session:

int verbosity = 4;
ssh_options_set(session, SSH_OPTIONS_LOG_VERBOSITY, );

The OpenSSH command you used adds this option to some list, while the
libssh operation limits the kex algorithms to this single algorithm.
The verbose log as mentioned above will show you what the server
supports.

Jakub

On Wed, Jan 31, 2024 at 1:26 PM Bhautik Radadiya
 wrote:
>
> Yes, we tried through manual ssh command like below, and we are into the 
> devide.
>
> ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 Device_ip -p Port
>
> Not sure what's stopping us through libssh.
>
> Thanks
> Bhautik
>
> On Wed, Jan 31, 2024, 5:38 PM Andreas Schneider  wrote:
>>
>> On Wednesday, 31 January 2024 11:31:53 CET Bhautik Radadiya wrote:
>> > Hi,
>>
>> Hi,
>>
>> > Hope you all are well!
>> > I am facing this (kex error : no match for method kex algos) issue in my
>> > application while trying to connect to device.
>> > I am using libssh 0.9.5.
>> > I added this below line in my sshlib file but not working it.
>> >
>> > ssh_option_set (my_session, SSH_OPTIO NS_KEY_EXCHANGE,
>> > "diffie-hellman-group14-sha1");
>> >
>> > Can you please help me with this? Or Can you please provide some guidance.
>> > It will be great help.
>>
>>
>> are you sure that the device supports this kex?
>>
>> Did you enable verbose logging and check what the server returns?
>>
>>
>> Best regards
>>
>>
>> Andreas
>>
>> --
>> Andreas Schneider a...@cryptomilk.org
>> GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
>>
>>

Re: Question about libssh 0.9.x & 0.10.x

[Jakub Jelen]

Hi,
both of these are mostly stable releases, but 0.9 is based on initial
release in 2019 [0] and 0.10 on initial release in 2022 [1] (see the
dates on the download tarballs). Since their initial release, they
received mostly bugfixes and security fixes. This means the 0.10 has
some ~3 years of development and new features (and bugs ;) ) when
compared to 0.9.

With the release of 0.11 later this year, you can expect that 0.9 will
be deprecated (only last two releases are supported [2]) so if you aim
to support your software after this date, I would suggest to go ahead
with 0.10 (or even wait for 0.11).

To the question what version to use, it depends on the use case. If
you need some feature from 0.10, you have to go to 0.10. Similarly if
you plan to use your software further after this year in secure
manner, 0.9 will not be officially supported. On the other hand,
updating to 0.9 should be less painful to do regualrly as it has less
changes for you (but both of the versions should be ABI compatible).

[0] https://www.libssh.org/files/0.9/
[1] https://www.libssh.org/files/0.10/
[2] https://www.libssh.org/development/security-process/

Regards,
Jakub

On Sat, Jan 27, 2024 at 1:56 AM Johnson Cai  wrote:
>
> Greetings:
>
>
>
> I am a newbie to the libssh.
>
>
>
> I notice that there are 2 versions of libssh: libssh 0.9.x & 0.10.x.
>
>
>
> I wonder:
>
> What the difference is between those 2 versions.
> And if I want to upgrade the current libssh-0.9.0, which one should I use: 
> “0.9.8” or “0.10.6”???
>
>
>
>
>
> Thanks
>
> Johnson Cai
>
>

Re: usermod -S /path/to/app vs. custom server program with libssh

[Jakub Jelen]

Hi,
it mostly depends on the granularity you need in the control of the
SSH session or a limitation of the target system. If you just want
some CLI program to execute remotely, wrapping it in some existing ssh
server (openssh) as a forced command is much less error-prone and much
less work. Its also useful if you still want to keep the standard SSH
service running on the same machine on the same port for management.

On the other hand, if you need more control of the sessions,
authentication, transfers, users, implementing ssh server using libssh
might be your best bet. Its also significantly smaller in regards to
LoC, that the whole OpenSSH, which can limit the attack vector. libssh
can also run with much smaller cryptographic libraries than OpenSSL,
which might be useful for smaller systems/ You can tune many things
using configuration in OpenSSH, but there are limits. In libssh you
can implement callbacks for most of the stuff handling incoming
connection, callbacks, authentication, various requests, which is not
possible with OpenSSH.

Jakub

On Fri, Jan 19, 2024 at 3:31 AM The Geek on Skates
 wrote:
>
> Good evening and happy Friday! :)
>
> What I mean, process-wise, is something like:
>
> At a terminal, user runs ssh gameorwhatever@myserver
> The request goes to sshd, with the key or password or whatever, and the user 
> is in.
> The "gameorwhatever" user's shell is set to /path/to/some/program, and a 
> chroot is in place, so the user uses the game or whatever, and when s/he is 
> done s/he is disconnected from the server.
>
> On the other hand, the other way (and the way I was originally thinking of 
> going for this project), was:
>
> At a terminal, user runs ssh gameorwhatever@myserver
> The request goes to /path/to/some/program, which hopefully handles the key 
> stuff correctly, and hopefully does all the sending/receiving correctly, and 
> all that.
>
>
> So I've been thinking, just out of curiosity, why (and when) would I choose 
> one strategy over the other?  If I want to set up something other than a 
> full-on OS shell, and make it accessible over SSH, what would be the pros and 
> cons of using libssh to create a server program vs. creating a user with 
> minimal access to stuff, doing the whole chroot thing I don't fully 
> understand (YET), and just changing that user's "shell" to the new program?  
> It seems to me that way would eliminate a lot of the learning curve (and room 
> for noob error and easy cracking).  You wouldn't have to do any of the 
> networking stuff yourself, it would be like creating any other command-line 
> app (and assuming you know about things like buffer overflows etc. it's 
> pretty easy to create terminal apps that don't have gaping security holes in 
> them, lol).  And if users accessed it with the standard ssh client, your 
> program would be what reads any parameters people might try (like "ssh 
> user@server /bin/bash" or whatever), so it's not like there's an easy way for 
> someone to get around your program into a Bash shell.  That, compared with 
> implementing a server "from scratch" (well not really from scratch - using 
> libssh I mean) just sounds so much more error-prone, if you don't know all 
> the intricate nuts and bolts of how SSH is supposed to work under the hood.  
> I'm just kind of curious about your thoughts on the advantages of doing it 
> one way vs. the other.  I know C and C++ really well, but apart from some 
> minimal tinkering with the sockets APIs idk much about how to work with SSH 
> (beyond the obvious - I can SSH into servers, create keys and stuff like that 
> - but even the SSH setup I always have to re-research every time lol).  Or 
> maybe I'm just overthinking things. :D
>
> Don't get me wrong - I still want to learn to use libssh (I've heard of some 
> cool things people are doing with their own clients... idk why u would 
> necessarily need/want that, but real-time communications over SSH does sound 
> awesome).  I'm not trying to say one approach or the other to my specific 
> question is better - I'm just interested in getting your thoughts on the best 
> way to "host" (for lack of a better term) a command-line app over SSH.
>
> Anyway, hope you guys have a nice night (or morning), and looking forward to 
> reading your two cents on the subject. :)
>
>

Re: Time of a file on a remote machine via SCP API?

[Jakub Jelen]

Hi,
no, it is not possible with the scp API. The SCP is very limited and
can only send and receive files (and is deprecated [1]).

You could do this though with the SFTP API.

[1] 
https://gitlab.com/libssh/libssh-mirror/-/blob/master/CHANGELOG?ref_type=heads#L24

Regards,.
Jakub

On Thu, Jan 18, 2024 at 6:56 AM Ogogon !!!  wrote:
>
> Greetings, colleagues!
>
> Please tell me, is it possible to get the creation or modification time
> of a file on a remote machine using the SCP API?
> I want to write a utility that will copy only changed files.
>
> Ogogon.
>

Re: CVE-2023-48795: Backporting strict key exchange to older libssh

[Jakub Jelen]

Hi.
Thank you for all the good questions! I will try to reply inline.

On Sat, Dec 30, 2023 at 8:41 PM Sean Whitton  wrote:
>
> Hello,
>
> I am working to backport the fix for CVE-2023-48795 to libssh 0.8.7,
> as part of Debian's Long Term Support effort, funded by Freexian SARL.
> (I will later be seeking to backport the fix to 0.7.3 and 0.6.3 too, as
> part of Freexian's Extended Long Term Support effort.)

To save you some time, I think you will not need to do this for 0.7 and older as
these do not support neither chacha20 cipher nor the etm macs so these should
not be affected.

> I have two queries about this, if I may.
>
> (1) These older libssh do not include the rekeying as implemented in
> commit 58cae236.  Is that rekeying necessary for the strict key
> exchange to be effective?

No. The Rerekying is not necessary for exploiting the CVE-2023-48795.
The exploit can happen only during the first key exchange when the messages
are not yet encrypted.

Note, that even though the libssh 0.8 does not implement the automatic
invocation of rekeying after specific amount of time/transferred data,
the rekeying can be triggered by the other party as described by the
protocol (but there might be some bugs as we do not have test coverage
for this in the old versions as far as I know).

> (2) Does anyone have a utility that tests the strict key exchange?
> Or, does the regular test suite already exercise the relevant code?
> I'm asking because the vulnerability scanner on terrapin-attack.com
> only seems to check for support of strict key exchange, not whether
> it actually works.

I am not aware of any other tool than the one created by the researchers.
But generally, if you get both of the client and server supporting the extension
(can be checked with the tool from terrapin-attack.com) and  everything works
with the strict key exchange (running testsuite, executing some real-world/test
connections to other strict hosts), it works. If it would not, you
would get failures
on the protocol level.

The last resort might be reviewing the debug logs from libssh or the other peer,
making sure the sequence number is reset when running against some
known-to-be-good implementation, either current libssh or openssh. But again,
this mode requires both peers to reset the sequence numbers at the same time
and if this does not happen in one, the MACs will not match and the connection
will be terminated.

Hope it helps,
Jakub

Re: libssh 0.10.6 and libssh 0.9.8 security releases

[Jakub Jelen]

Hi,
I see now the tags are there:

https://git.libssh.org/projects/libssh.git/tag/?h=libssh-0.10.6
https://git.libssh.org/projects/libssh.git/tag/?h=libssh-0.10.6

Jakub

On Wed, Dec 27, 2023 at 11:22 PM Norm Green
 wrote:
>
> I am not seeing a release tag for 0.10.6 in
> https://git.libssh.org/projects/libssh.git .
> Is there supposed to be one?
>
> Norm Green
>
> On 12/25/2023 11:26 AM, Jakub Jelen wrote:
> > Thank you for the update of cygwin! Note, that the 0.10.6 had a
> > regression in IPv6 parsing as mentioned in the updated announcement on
> > the blog (but not yet mentioned here). So please, consider pulling
> > also the fix for following issue:
> >
> > https://gitlab.com/libssh/libssh-mirror/-/issues/227
> >
> > Jakub
> >
> > On Mon, Dec 25, 2023 at 2:12 PM Carlo Bramini  
> > wrote:
> >> Thank you very much!
> >> I updated my packages of libssh to version 0.10.6-1 for CYGWIN into my 
> >> repo:
> >> https://github.com/carlo-bramini/packages-cygwin/tree/main/libssh
> >>
> >> Sincerely,
> >>
> >> Carlo Bramini.
> >>
> >>> Il 18/12/2023 21:54 CET Jakub Jelen  ha scritto:
> >>>
> >>>
> >>> The two new releases of libssh 0.9 and 0.10 address the following
> >>> security issues:
> >>>
> >>>   * CVE-2023-6004: Command Injection using malicious hostname in
> >>> expanded proxycommand. More details can be found in the advisory.
> >>>   * CVE-2023-48795: Avoid potential downgrade attacks by implementing
> >>> strict kex. More details can be found in the advisory.
> >>>   * CVE-2023-6918: Avoid potential use of weak keys in low memory
> >>> conditions by systematically checking return values of MD functions.
> >>> More details can be found in the advisory.
> >>>
> >>> In addition the 0.10 version contains several bugfixes and backports.
> >>> For full list, see the changelog below.
> >>>
> >>> If you are new to libssh you should read our tutorial how to get
> >>> started. Please join our mailing list or visit Matrix channel if you
> >>> have questions.
> >>>
> >>> You can read the full advisories, changelog and download updated
> >>> libssh on the following announcement post:
> >>>
> >>> https://www.libssh.org/2023/12/18/libssh-0-10-6-and-libssh-0-9-8-security-releases/
> >
>
>

Re: CVE-2023-48795: Backporting strict key exchange to older libssh

[Jakub Jelen]

Hi.
Thank you for all the good questions! I will try to reply inline.

On Sat, Dec 30, 2023 at 8:41 PM Sean Whitton  wrote:
>
> Hello,
>
> I am working to backport the fix for CVE-2023-48795 to libssh 0.8.7,
> as part of Debian's Long Term Support effort, funded by Freexian SARL.
> (I will later be seeking to backport the fix to 0.7.3 and 0.6.3 too, as
> part of Freexian's Extended Long Term Support effort.)

To save you some time, I think you will not need to do this for 0.7 and older as
these do not support neither chacha20 cipher nor the etm macs so these should
not be affected.

> I have two queries about this, if I may.
>
> (1) These older libssh do not include the rekeying as implemented in
> commit 58cae236.  Is that rekeying necessary for the strict key
> exchange to be effective?

No. The Rerekying is not necessary for exploiting the CVE-2023-48795.
The exploit can happen only during the first key exchange when the messages
are not yet encrypted.

Note, that even though the libssh 0.8 does not implement the automatic
invocation of rekeying after specific amount of time/transferred data,
the rekeying can be triggered by the other party as described by the
protocol (but there might be some bugs as we do not have test coverage
for this in the old versions as far as I know).

> (2) Does anyone have a utility that tests the strict key exchange?
> Or, does the regular test suite already exercise the relevant code?
> I'm asking because the vulnerability scanner on terrapin-attack.com
> only seems to check for support of strict key exchange, not whether
> it actually works.

I am not aware of any other tool than the one created by the researchers.
But generally, if you get both of the client and server supporting the extension
(can be checked with the tool from terrapin-attack.com) and  everything works
with the strict key exchange (running testsuite, executing some real-world/test
connections to other strict hosts), it works. If it would not, you
would get failures
on the protocol level.

The last resort might be reviewing the debug logs from libssh or the other peer,
making sure the sequence number is reset when running against some
known-to-be-good implementation, either current libssh or openssh. But again,
this mode requires both peers to reset the sequence numbers at the same time
and if this does not happen in one, the MACs will not match and the connection
will be terminated.

Hope it helps,
Jakub

Re: libssh 0.10.6 and libssh 0.9.8 security releases

[Jakub Jelen]

Thank you for the update of cygwin! Note, that the 0.10.6 had a
regression in IPv6 parsing as mentioned in the updated announcement on
the blog (but not yet mentioned here). So please, consider pulling
also the fix for following issue:

https://gitlab.com/libssh/libssh-mirror/-/issues/227

Jakub

On Mon, Dec 25, 2023 at 2:12 PM Carlo Bramini  wrote:
>
> Thank you very much!
> I updated my packages of libssh to version 0.10.6-1 for CYGWIN into my repo:
> https://github.com/carlo-bramini/packages-cygwin/tree/main/libssh
>
> Sincerely,
>
> Carlo Bramini.
>
> > Il 18/12/2023 21:54 CET Jakub Jelen  ha scritto:
> >
> >
> > The two new releases of libssh 0.9 and 0.10 address the following
> > security issues:
> >
> >  * CVE-2023-6004: Command Injection using malicious hostname in
> > expanded proxycommand. More details can be found in the advisory.
> >  * CVE-2023-48795: Avoid potential downgrade attacks by implementing
> > strict kex. More details can be found in the advisory.
> >  * CVE-2023-6918: Avoid potential use of weak keys in low memory
> > conditions by systematically checking return values of MD functions.
> > More details can be found in the advisory.
> >
> > In addition the 0.10 version contains several bugfixes and backports.
> > For full list, see the changelog below.
> >
> > If you are new to libssh you should read our tutorial how to get
> > started. Please join our mailing list or visit Matrix channel if you
> > have questions.
> >
> > You can read the full advisories, changelog and download updated
> > libssh on the following announcement post:
> >
> > https://www.libssh.org/2023/12/18/libssh-0-10-6-and-libssh-0-9-8-security-releases/
>

libssh 0.10.6 and libssh 0.9.8 security releases

[Jakub Jelen]

The two new releases of libssh 0.9 and 0.10 address the following
security issues:

 * CVE-2023-6004: Command Injection using malicious hostname in
expanded proxycommand. More details can be found in the advisory.
 * CVE-2023-48795: Avoid potential downgrade attacks by implementing
strict kex. More details can be found in the advisory.
 * CVE-2023-6918: Avoid potential use of weak keys in low memory
conditions by systematically checking return values of MD functions.
More details can be found in the advisory.

In addition the 0.10 version contains several bugfixes and backports.
For full list, see the changelog below.

If you are new to libssh you should read our tutorial how to get
started. Please join our mailing list or visit Matrix channel if you
have questions.

You can read the full advisories, changelog and download updated
libssh on the following announcement post:

https://www.libssh.org/2023/12/18/libssh-0-10-6-and-libssh-0-9-8-security-releases/

Heads-up: Security releases ahead!

[Jakub Jelen]

Hi,
this is a heads-up that there will be libssh security updates on
Monday, December 18th, 2023. Please make sure that your libssh
installations will be updated soon after the release!

There are various issues fixed affecting both client and server

Impacted components:
client (CVSS around 4)
server (CVSS around 4)

Best regards,
Jakub Jelen

Wrapping up 2023 GSoC

[Jakub Jelen]

Hi all,
The libssh organization participated in the Google Google Summer of
Code (GSoC) program for the second time this year. I just published an
article describing this year projects and outcomes. Any
comments/feedback welcomed!

https://www.libssh.org/2023/09/07/wrapping-up-2023-gsoc/

Best regards,
Jakub Jelen

Re: Question on tarball source files

[Jakub Jelen]

Sounds like you are using OpenSSL 3.0 built without deprecated API. I
think we did not test this thoroughly as we were encountering some
issues in 0.10 branch when migrating to openssl 3.0 as some of the
operations were not possible back in the time.

But in any case, the libgcrypt-compat should not be built only when
the detected openssl version is < 1.1.1

https://gitlab.com/libssh/libssh-mirror/-/blob/libssh-0.10.5/src/libcrypto-compat.h?ref_type=tags#L10
https://gitlab.com/libssh/libssh-mirror/-/blob/libssh-0.10.5/src/CMakeLists.txt#L259

Can you share the cmake options you are using, output of the cmake run
and `CMakeCache.txt` to verify the openssl version is detected
correctly?

What container image are you using as a base for your build?

Jakub

On Tue, Jun 13, 2023 at 12:36 PM Maher, Katie  wrote:
>
> Hi,
>
> Thanks for your response. Below are some of the issues I'm getting. I think 
> it's because its having problems reading the libcrypto-compat.h file
>
> /root/externals/libssh/src/libcrypto-compat.c:107:32: error: unknown type 
> name 'RSA'
>   107 | void RSA_get0_crt_params(const RSA *r,
>   |^~~
> /root/externals/libssh/src/libcrypto-compat.c:108:32: error: unknown type 
> name 'BIGNUM'
>   108 |  const BIGNUM **dmp1, const BIGNUM **dmq1,
> /root/externals/libssh/src/libcrypto-compat.c:114:18: error: request for 
> member 'dmq1' in something not a structure or union
>   114 | *dmq1 = r->dmq1;
>   |  ^~
> /root/externals/libssh/src/libcrypto-compat.c:226:23: error: implicit 
> declaration of function 'OPENSSL_malloc' 
> [-Werror=implicit-function-declaration]
>   226 | EVP_MD_CTX *ctx = OPENSSL_malloc(sizeof(EVP_MD_CTX));
>   |   ^~
> /root/externals/libssh/src/libcrypto-compat.c:226:45: error: 'EVP_MD_CTX' 
> undeclared (first use in this function); did you mean 'EVP_MD_CTX_new'?
>   226 | EVP_MD_CTX *ctx = OPENSSL_malloc(sizeof(EVP_MD_CTX));
>   | ^~
>   |     EVP_MD_CTX_new
>
>
>
> Kind Regards,
> Katie
>
> -Original Message-
> From: Jakub Jelen 
> Sent: 13 June 2023 09:05
> To: libssh@libssh.org
> Subject: Re: Question on tarball source files
>
> Hello,
> the 0.10.5 is the latest version that should work fine with OpenSSL 3.0. 
> There were some changes since then in master but it will take some time 
> before they will be released.
> Can you post the errors you are getting? We are running CI against OpenSSL 
> 3.0 also in the stable-0.10 branches and all looks good:
>
> https://gitlab.com/libssh/libssh-mirror/-/commits/stable-0.10
>
> Regards,
> Jakub
>
> On Mon, Jun 12, 2023 at 5:36 PM Maher, Katie  wrote:
> >
> > Hi libssh team,
> >
> >
> >
> > I just wanted to ask a question about the tarballs listed under 
> > https://www.libssh.org/files/  . We are building a docker image that uses 
> > OpenSSL 3 and are trying to use libssh v. 0.10.5 in it. However, I have 
> > been getting many errors coming from the libssh/src/libcrypto-compat.c 
> > file. I can see from your gitlab repo that this file was removed since 
> > about October of last year, however the tarball source files still have 
> > this file. Just wondering where I can get the most up to date tarball 
> > source file for v. 0.10.5? Or maybe I am missing something?
> >
> >
> >
> > Thanks in advance! 
> >
> >
> >
> > Kind regards,
> >
> > Katie
> >
> >
>
>

Re: Question on tarball source files

[Jakub Jelen]

Hello,
the 0.10.5 is the latest version that should work fine with OpenSSL
3.0. There were some changes since then in master but it will take
some time before they will be released.
Can you post the errors you are getting? We are running CI against
OpenSSL 3.0 also in the stable-0.10 branches and all looks good:

https://gitlab.com/libssh/libssh-mirror/-/commits/stable-0.10

Regards,
Jakub

On Mon, Jun 12, 2023 at 5:36 PM Maher, Katie  wrote:
>
> Hi libssh team,
>
>
>
> I just wanted to ask a question about the tarballs listed under 
> https://www.libssh.org/files/ . We are building a docker image that uses 
> OpenSSL 3 and are trying to use libssh v. 0.10.5 in it. However, I have been 
> getting many errors coming from the libssh/src/libcrypto-compat.c file. I can 
> see from your gitlab repo that this file was removed since about October of 
> last year, however the tarball source files still have this file. Just 
> wondering where I can get the most up to date tarball source file for v. 
> 0.10.5? Or maybe I am missing something?
>
>
>
> Thanks in advance! 
>
>
>
> Kind regards,
>
> Katie
>
>

Re: Proposal for High level sftp api for uploads and downloads

[Jakub Jelen]

On Tue, Jun 6, 2023 at 4:41 PM Eshan Kelkar  wrote:
>
> Thanks a lot for the inputs.
>
> Based on the suggestions the api will look something as follows :
>
> enum sftp_file_transfer_direction_e
> {
> SFTP_FILE_TRANSFER_DIRECTION_LOCAL_TO_LOCAL,
> SFTP_FILE_TRANSFER_DIRECTION_LOCAL_TO_REMOTE,
> SFTP_FILE_TRANSFER_DIRECTION_REMOTE_TO_LOCAL,
> SFTP_FILE_TRANSFER_DIRECTION_REMOTE_TO_REMOTE
> } ;
>
> struct sftp_file_transfer_struct
> {
> enum sftp_file_transfer_direction_e direction;
>
> union
> {
> int local_fd;
> sftp_file remote_file;
> } source, target;
>
> size_t chunk_size;
> size_t in_flight_requests;
>
> void *user_data;
> void (*progress_callback)(--parameters not yet decided);
> };
>
> typedef struct sftp_file_transfer_struct* sftp_file_transfer;
>
> sftp_file_transfer sftp_file_transfer_new()
> {
> /* Allocate a new file transfer structure, assign default
>  * values to the members and return the structure's
>  * address
>  */
> }
>
> enum sftp_file_transfer_options_e
> {
> SFTP_FILE_TRANSFER_OPTIONS_DIRECTION,
>
> SFTP_FILE_TRANSFER_OPTIONS_SOURCE_LOCAL,
> SFTP_FILE_TRANSFER_OPTIONS_SOURCE_REMOTE,
> SFTP_FILE_TRANSFER_OPTIONS_TARGET_LOCAL,
> SFTP_FILE_TRANSFER_OPTIONS_TARGET_REMOTE,
>
> SFTP_FILE_TRANSFER_OPTIONS_CHUNK_SIZE,
> SFTP_FILE_TRANSFER_OPTIONS_IN_FLIGHT_REQESTS,
>
> SFTP_FILE_TRANSFER_OPTIONS_USER_DATA
> SFTP_FILE_TRANSFER_OPTIONS_PROGRESS_CALLBACK
> } ;


Note here that I am a bit worried about the length of the names as
they already have ~40 characters, fitting them reasonably on one line
will be hard.

I would probably propose to drop the FILE_TRANSFER part or shorten it
to FT or similar. The same for the direction enum.

> int sftp_file_transfer_options_set  (sftp_file_transfer ft, enum 
> sftp_file_transfer_options_e option,  void *value);
>
> void sftp_file_transfer_free(sftp_file_transfer ft);
>
>> If the short reads occurs for normal files, I think the right thing is
>> to fail and report the issue to the user. If the file was already
>> partially transferred, it might make sense to provide some information
>> how much was transferred and maybe provide a way to resume partial
>> transfers, but I would probably keep this for later time. But it would
>> be good to think about this possible extension where we would need to
>> update the offset in the file structure with the size of the target file
>> (or again check how openssh does this).
>
>
> For being able to support partial transfers, I think we should
> begin read-writes on the files from current offsets of the local file,
> remote sftp file instead of necessarily starting from offset 0.
>
>  For example, say we are reading a file (for the sake of this sftp file
> transfer) and the read offset for that file initially is 10 (when 
> sftp_file_transfer()
> is called) and the file size is 1000 bytes. Then the read operation will be
> started not from offset 0 but from offset 10 and the transfer will occur for
> (1000 - 10) bytes.
>
> This will help to support and resume partial transfers, but it puts the 
> responsibility on
> the user to set offsets depending on where he/she wants to begin read/write 
> from
> before calling this sftp_file_transfer() to start read/writes from that 
> offset. If user
> wants to start the transfer of a file from the offset 100 not 0, then he must 
> set the offset
> of that file to 100 (using sftp_seek() for remote files and lseek() for local 
> files) and
> then call sftp_file_transfer().

I think this approach is suitable for the low-level api, but the
high-level API needs to handle this somehow internally automatically.
I think by default it should truncate the target file and reset the
offset of the source file to 0. If the user elects to use some offset,
I think it should be given as an high-level API option.

One of the high-level options might be the attempt to resume partial
transfers, similarly as you can see in the sftp from openssh. I do not
think how practical would it be to read files from other specific
offsets or write to some specific offsets using sftp.

> The user should also be made aware that a call to sftp_file_transfer()
> updates the offset of the files. i.e if initially offset is 0 and he calls the
> sftp_file_transfer() for the file and it successfully transfers the whole file
> then the offset after sftp_file_transfer() returns will be at the end of the
> file.
>
> The sftp_file_transfer() function will return the number of bytes transferred
> successfully and -1 on encountering some error before transferring even
> a single byte provided the file to transfer had > 0 bytes. If the file to 
> transfer
> is a 0 byte file the function will simply return 0.
>
> (We can use off_t or int64_t for type of number of bytes transferred
> [not unsigned as on error we have to return SSH_ERROR i.e -1], off_t
> is the standard type for representing file size/file offsets, but on 32 bit 
> systems
> its of 32 bits and signed which limits the file size it can store to 2^31-1 

Fwd: Proposal for High level sftp api for uploads and downloads

[Jakub Jelen]

Resending to the mailing list too.


 Forwarded Message 
Subject: Re: Proposal for High level sftp api for uploads and downloads
Date: Fri, 2 Jun 2023 10:54:56 +0200
From: Jakub Jelen 
To: Eshan Kelkar 

Thank you for the great write-up!

I put some comments and thoughts inline. Let me know if some of the are 
unclear.


On 5/31/23 09:38, Eshan Kelkar wrote:

Libssh needs a high level api for uploading and
downloading files. Functions like sftp_put() and
sftp_get() need to be introduced which the users
can call simply to upload and download files instead
of having to write their own functions to perform uploads
and downloads using the low level read/write api's.


One more point why we do that is that the API needs to have reasonable 
throughput. With the current synchronous API, the performance is 
terrible and there was only low-level asynchronous API for downloads 
(hard to guess how much used though).



This mail suggests approaches that can be followed
to develop that api.
Some terminology :
1. local_fd - is the file descriptor [obtained using open()
or creat()] of a file on the local machine of the user.

2.  remote_file  - is a sftp file handle [obtained using
sftp_open()] of a file on the connected server.

3. concurrent_requests -  This is the number of requests
we initially issue before trying to get the responses.

Say you are downloading and you have 20 concurrent
requests, this means that first we have issued 20 read
requests, and then when we are trying to get/wait for the
response of the first request, the server may be processing
or may have processed the other 19 requests (This is the
advantage of asynchronous request-response pattern over
synchronous request-response where we would have issued
the next request [and server would have processed it] only
after getting a response of the first request).

And after getting the response of the first request, we issue
another request if needed and then try to get the responses
of the other outstanding requests and repeat this procedure
for them too.

Though you can see this name "concurrent_requests" is not
the best as the requests are not being issued in a concurrent
manner here, neither are they being processed concurrently by
the server. So if a better name comes to your mind, kindly suggest.


Reading through this, I would probably consider slightly better naming. 
These requests are in fact not concurrent, but work as you describe 
them. This is number of in-fligth requests, that are sequentially sent, 
but handling of the server responses is interleaved with other requests.


My proposal would be to call them in_flight_requests or 
interleaved_requests, but there might be better names. I would like to 
avoid the parallel/concurrent wording, which suggests there is some real 
threading/parallelism involved.


The OpenSSH's sftp manual page describes this as "num requests", which I 
also find quite unclear (and they default to 64):



Specify how many requests may be outstanding at any one time.


What you describe above is the current way how the asynchronous 
transfers are done. I assume for performance, the chunksize, number of 
in-fly requests and other parameters need to be tuned, but we should 
provide some reasonable default.


Other option is, that there might be completely different way to do 
that, which we should probably research/try before settling on 
particular solution.



4. chunk_size -  The number of bytes we usually issue a
read/write request for, if the number of bytes to read/write
is less than this chunk_size then the request is issued for
those many number of bytes and not chunk_size number
of bytes.


It is not completely clear to me what you try to describe in the second 
part of the paragraph. This is indeed one of the parameters that affect 
the throughput and resulting transfer speed/protocol overhead.



How the api can look from User's perspective :

Approach 1 :
--
The user has to pass each of the 4 required things
for the transfer to the put, get functions.

For the default values of concurrent_requests and
chunk_size we can provide macros (which expand
to default values suggested by libssh) which the user
can use if he/she is not interested in setting some
custom values.

int sftp_put(int local_fd,
                    sftp_file remote_file,
                    int concurrent_requests,
                    size_t chunk_size);

int sftp_get(int local_fd,
                    sftp_file remote_file,
                    int concurrent_requests,
                    size_t chunk_size);

Approach 2 :
-
Store these 4 things in a structure, make user be able
to configure the number of concurrent_requests and
chunk_size if he/she wants to according to the requirements.

/* in sftp.h file */
typedef struct sftp_file_transfer_struct* sftp_file_transfer;

/* in sftp.c file */

struct sftp_file_transfer_s

Re: [EXTERNAL] Re: ssh_options_set not working?

[Jakub Jelen]

On 5/31/23 14:49, Kerrison, Adam wrote:

Well I've forked it and tried to create a merge but after asking for my credit 
card (really!?) gitlab thinks I am robot. I've given up for now, I don't have 
enough time to fight it. Maybe I will look at it again later


I see your merge request, but only one commit from that. Looks like you 
either deleted your fork or changed it to the private?:


https://gitlab.com/libssh/libssh-mirror/-/merge_requests/378

For this you should be able to work without verifying account with your 
credit card.. but I have account for years so I am not sure about the 
process.


The other option is to send the patches here to the mailing list, if it 
would be more comfortable for you.



Gitlab seems a hell of a lot more work than github ... sigh


Unfortunately, it looks like that is the case for new users.

Jakub


-Original Message-
From: Jakub Jelen 
Sent: 31 May 2023 11:59
To: libssh@libssh.org
Subject: Re: [EXTERNAL] Re: ssh_options_set not working?

On 5/30/23 17:25, Kerrison, Adam wrote:

I've made it work   I need to set the server to client options, not the client 
to server ones (obviously). It’s a bit fiddly as there is no way for code to 
get the list of support and default methods. I found functions to do this in 
kex.c but these symbols aren't exposed in the .so/DLL, not sure how to do that.


Good to hear that! Yeah, there can be different lists for different directions 
for ciphers and hmacs, but in most of the cases it really makes sense to set 
both of the directions to the same algorithms (wondering if we should not have 
an API (without the _C_S/_S_C suffixes) to set both of them to avoid such 
confusion).


I've created a git clone and added my ssh_options_get() changes to
branch - how do I create a PR? When I try to push I get a 403. I might
have some other little changes too so being able to push would be
handy


You will need to fork the repository on gitlab and push to your fork and then 
open a merge request (the same as pull request on github) against the main 
repository:

https://urldefense.com/v3/__https://gitlab.com/libssh/libssh-mirror__;!!PEZBYkTc!ZMTfG7v0rQO-rpXIO7giiW03FU7rWL7G_vhWrcoPaEv3r-mE7VtMgBj_5m7kcLHamC9jn3utIicgSxzB$

Regards,
Jakub


Thanks

Adam

-Original Message-
From: Kerrison, Adam
Sent: 30 May 2023 12:11
To: libssh@libssh.org
Subject: RE: [EXTERNAL] Re: ssh_options_set not working?

I am using libssh 0.10.5 on Windows. I've confirmed it was built with 
WITH_GEX=1 (that’s the default and we've turned it off). I've added verbose 
logging at the function level (see below) and tried also setting 
SSH_OPTIONS_HOSTKEYS too.

I also tried implementing support for these options in ssh_options_get() which 
works but the values are initialized to NULL and the existing code treats that 
as an error ☹ My code works to retrieve the value after it has been set with 
ssh_options_set() (you can see that in the log as NEW KEYEX). I don't know 
where the values in the session struct would actually get set to handle the 
initial NULL value.

Here is the log:

SETTING KEYEX
curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nist
p521,diffie-hellman-group18-sha512,diffie-hellman-group16-sha512,diffi
e-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hel
lman-group1-sha1,diffie-hellman-group-exchange-sha1
NEW KEYEX =
curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nist
p521,diffie-hellman-group18-sha512,diffie-hellman-group16-sha512,diffi
e-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hel
lman-group1-sha1,diffie-hellman-group-exchange-sha1
SETTING CIPHERS
chacha20-poly1305,aes256-...@openssh.com,aes128-...@openssh.com,aes256
-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-cbc
SETTING HMACS
hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-
e...@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-sha1
SETTING HOST_KEYS
ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp52
1,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
[2023/05/30 12:06:28.416222, 2] ssh_connect:  libssh 0.10.5 (c)
2003-2023 Aris Adamantiadis, Andreas Schneider and libssh
contributors. Distributed under the LGPL, please refer to COPYING file
for information about your rights, using threading threads_winlock
[2023/05/30 12:06:28.416222, 3] getai:  host 10.49.32.30 matches an IP
address
[2023/05/30 12:06:28.417199, 2] ssh_socket_connect:  Nonblocking
connection socket: 296
[2023/05/30 12:06:28.423080, 2] ssh_connect:  Socket connecting, now
waiting for the callbacks to work
[2023/05/30 12:06:28.423080, 3] ssh_connect:  current state : 1
[2023/05/30 12:06:28.447504, 4] ssh_socket_pollcallback:  Poll
callback on socket 296 (POLLOUT ), out buffer 0
[2023/05/30 12:06:28.447504, 3] ssh_socket_pollcallback:  Received
POLLOUT in connecting state
[2023/05/30 12:06:28.448483, 1] socket_callback_connected:  Socket
connection callback: 1 (0)
[2023/05/30 12:06:28.455678

Re: [EXTERNAL] Re: ssh_options_set not working?

[Jakub Jelen]

:
[2023/05/30 12:06:28.543518, 4] ssh_list_kex:  languages server->client:
[2023/05/30 12:06:28.544493, 1] ssh_kex_select_methods:  kex error : no match for 
method encryption server->client: server 
[aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-...@lysator.liu.se],
 client 
[chacha20-poly1...@openssh.com,aes256-...@openssh.com,aes128-...@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,]
[2023/05/30 12:06:28.544493, 3] ssh_connect:  current state : 9

-Original Message-
From: Jakub Jelen 
Sent: 29 May 2023 11:22
To: libssh@libssh.org
Subject: [EXTERNAL] Re: ssh_options_set not working?

On 5/26/23 17:17, Kerrison, Adam wrote:

Hello

I am trying to enable all supported key exchange methods, ciphers and
HMACs to handle connecting to some truly ancient servers. The setup code is:

    ssh_session session = ssh_new();

    fprintf(stderr, "SETTING KEYEX %s\n", ALL_KEYEX_METHODS);

   if(ssh_options_set(session, SSH_OPTIONS_KEY_EXCHANGE,
ALL_KEYEX_METHODS) < 0) {

     fprintf(stderr, "FAILED TO SET KEYEX\n");

     }

     fprintf(stderr, "SETTING CIPHERS %s\n", ALL_CIPHERS);

      if(ssh_options_set(session, SSH_OPTIONS_CIPHERS_C_S, ALL_CIPHERS)
<
0) {

        fprintf(stderr, "FAILED TO SET CIPHERS\n");

    }

    fprintf(stderr, "SETTING HMACS %s\n", ALL_HMACS);

    if(ssh_options_set(session, SSH_OPTIONS_HMAC_C_S, ALL_HMACS) < 0) {

      fprintf(stderr, "FAILED TO SET HMACS\n");

    }

Where the ALL_* values are constants defining all the supports things
(see below)

When I run the code my connection fails. The output is:

SETTING KEYEX
curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nist
p521,diffie-hellman-group18-sha512,diffie-hellman-group16-sha512,diffi
e-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hel
lman-group1-sha1,diffie-hellman-group-exchange-sha1

SETTING CIPHERS
chacha20-poly1305,aes256-...@openssh.com,aes128-...@openssh.com,aes256
-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-cbc

SETTING HMACS
hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-
e...@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-sha1

ERROR: failed to connect: kex error : no match for method kex algos:
server
[diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1],
client
[curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecd
h-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha25
6,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-h
ellman-group18-sha512] (code 2)

So the ssh_options_set() calls aren’t failing but the values don’t
seem to have been applied as the client keyex list doesn’t include the
diffie-helman SHA1 methods that I set?


This API ignores any unknown algorithms, for example to avoid failing hard when 
parsing openssh configuration files. I do not think there is an API to retrieve 
the enabled algorithms, but the ssh_options_get() could be very simply extended 
to return the list of enabled algorithms for double-checking this. Feel free to 
propose the merge request!

The two algorithms supported by the server 
[diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1] are supported 
by libssh master, but they are not enabled by default in current versions. But 
using the ssh_options_set() should enable them.

The list of the algorithms you list in the outputs also differ both in content 
and order which sounds like the setting of the algorithms was not effective for 
some reason.


What am I doing wrong here?


What libssh version are you using? Can you bump the log verbosity and check the 
logs for some more information?

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.




--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: ssh_options_set not working?

[Jakub Jelen]

On 5/26/23 17:17, Kerrison, Adam wrote:

Hello

I am trying to enable all supported key exchange methods, ciphers and 
HMACs to handle connecting to some truly ancient servers. The setup code is:


   ssh_session session = ssh_new();

   fprintf(stderr, "SETTING KEYEX %s\n", ALL_KEYEX_METHODS);

  if(ssh_options_set(session, SSH_OPTIONS_KEY_EXCHANGE, 
ALL_KEYEX_METHODS) < 0) {


    fprintf(stderr, "FAILED TO SET KEYEX\n");

    }

    fprintf(stderr, "SETTING CIPHERS %s\n", ALL_CIPHERS);

     if(ssh_options_set(session, SSH_OPTIONS_CIPHERS_C_S, ALL_CIPHERS) < 
0) {


       fprintf(stderr, "FAILED TO SET CIPHERS\n");

   }

   fprintf(stderr, "SETTING HMACS %s\n", ALL_HMACS);

   if(ssh_options_set(session, SSH_OPTIONS_HMAC_C_S, ALL_HMACS) < 0) {

     fprintf(stderr, "FAILED TO SET HMACS\n");

   }

Where the ALL_* values are constants defining all the supports things 
(see below)


When I run the code my connection fails. The output is:

SETTING KEYEX 
curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group18-sha512,diffie-hellman-group16-sha512,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1


SETTING CIPHERS 
chacha20-poly1305,aes256-...@openssh.com,aes128-...@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-cbc


SETTING HMACS 
hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-sha1


ERROR: failed to connect: kex error : no match for method kex algos: 
server [diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1], 
client 
[curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512] (code 2)


So the ssh_options_set() calls aren’t failing but the values don’t seem 
to have been applied as the client keyex list doesn’t include the 
diffie-helman SHA1 methods that I set?


This API ignores any unknown algorithms, for example to avoid failing 
hard when parsing openssh configuration files. I do not think there is 
an API to retrieve the enabled algorithms, but the ssh_options_get() 
could be very simply extended to return the list of enabled algorithms 
for double-checking this. Feel free to propose the merge request!


The two algorithms supported by the server 
[diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1] are 
supported by libssh master, but they are not enabled by default in 
current versions. But using the ssh_options_set() should enable them.


The list of the algorithms you list in the outputs also differ both in 
content and order which sounds like the setting of the algorithms was 
not effective for some reason.



What am I doing wrong here?


What libssh version are you using? Can you bump the log verbosity and 
check the logs for some more information?


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Looking for examples on using libssh as a server

[Jakub Jelen]

/test_server/default_cb.c#L795

I think this should give you some idea and help you started.

If you would be willing to write a couple of paragraphs about writing 
ssh server, we would be very happy to accept them into the tutorial, as 
this is quite common topic, but nobody picked this up yet.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: libssh 0.9.7 and 0.10.5 were released

[Jakub Jelen]

On 5/15/23 18:09, Orion Poplawski wrote:

On 5/15/23 04:04, Jakub Jelen wrote:

On 5/9/23 19:25, Jakub Jelen wrote:

On 5/8/23 19:52, Jakub Jelen wrote:

On 5/8/23 04:05, Orion Poplawski wrote:

On 5/4/23 06:23, Jakub Jelen wrote:

Hello,

the libssh team released libssh 0.9.7 and 0.10.5, fixing previously
announced security issues CVE-2023-1667 and CVE-2023-2283:

https://www.libssh.org/2023/05/04/libssh-0-10-5-and-libssh-0-9-7-security-releases/


We're seeing a test failure just on i686 on Fedora rawhide:

40/62 Test #40: torture_rekey ***Failed   23.34 sec
[==] tests: Running 14 test(s).
OK: SSH-2.0-OpenSSH_9.0
[ RUN  ] torture_rekey_default
[   OK ] torture_rekey_default
[ RUN  ] torture_rekey_time
[   OK ] torture_rekey_time
[ RUN  ] torture_rekey_recv
[   OK ] torture_rekey_recv
[ RUN  ] torture_rekey_send
[   OK ] torture_rekey_send
[ RUN  ] torture_rekey_different_kex
[  ERROR   ] --- 0x20 != 0x40
[   LINE   ] ---
/builddir/build/BUILD/libssh-0.10.5/tests/client/torture_rekey.c:522:
error: Failure!
[  FAILED  ] torture_rekey_different_kex
[ RUN  ] torture_rekey_send_compression_delayed
[   OK ] torture_rekey_send_compression_delayed
[ RUN  ] torture_rekey_recv_compression_delayed
[   OK ] torture_rekey_recv_compression_delayed
[ RUN  ] torture_rekey_server_different_kex
OK: SSH-2.0-OpenSSH_9.0
[  ERROR   ] --- 0x20 != 0x40
[   LINE   ] ---
/builddir/build/BUILD/libssh-0.10.5/tests/client/torture_rekey.c:597:
error: Failure!
[  FAILED  ] torture_rekey_server_different_kex
[ RUN  ] torture_rekey_server_send
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_server_send
[ RUN  ] torture_rekey_guess_send
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_send
[ RUN  ] torture_rekey_guess_wrong_send
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_wrong_send
[ RUN  ] torture_rekey_server_recv
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_server_recv
[ RUN  ] torture_rekey_guess_recv
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_recv
[ RUN  ] torture_rekey_guess_wrong_recv
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_wrong_recv
[==] tests: 14 test(s) run.
[  PASSED  ] 12 test(s).
[  FAILED  ] tests: 2 test(s), listed below:
[  FAILED  ] torture_rekey_different_kex
[  FAILED  ] torture_rekey_server_different_kex
   2 FAILED TEST(S)


any idea what might be causing that?



Hi,
I was hoping I debugged all these issues while working on the release, but
it looks like there are still some timing/memory/architecture variables.

This error happens in case the rekey did not happen as expected (unexpected
size of digest size). I was bumping the amount of sent data in [1] and [2]
in both branches, which looked like solving the problem in upstream tests.
Other option might be adding some sleep between the sending and processing
the packets to make sure the server gets its turn, but hard to say if this
would help ... the packet processing and rekey is asynchronous ... but
there might better ways to do that.

[1]
https://gitlab.com/libssh/libssh-mirror/-/commit/31a33fd2fd0fdad7c814748fdff75c7390c7f06e
 [0.9]
[2]
https://gitlab.com/libssh/libssh-mirror/-/commit/dc1254d53e4fc6cbeb4797fc6ca1c9ed2c21f15c
 [0.10]

Regards,


  From my understanding, this is an issue of the OpenSSH in Rawhide. I can
reliably reproduce it in mock and it goes away when I try the same code in
Fedora 38 (regardless of architecture).

There are several patches in rawhide openssh that are missing from the F38
version so I will continue some investigation tomorrow.


This is a Fedora's OpenSSH bug on i686 (or OpenSSL one):

https://bugzilla.redhat.com/show_bug.cgi?id=2203241

We are still investigating the real cause.

In the meantime, the libssh in Fedora rawhide was updated with skipping this
test. Updates in older versions are landing as they do not have this issue.

Regards,


Thank you for the investigation and the updates.


For the record also here, the bottom-line is that it is really an libssh 
test issue. I updated all stable version of Fedora with the 0.10.5 
version and verified that just giving more time for the (new) openssh 
server is really enough to make the test working. The upstream patch is 
here for anyone interested:


https://gitlab.com/libssh/libssh-mirror/-/merge_requests/370

I will also backport it to the 0.10 branch and Fedora rawhide as soon as 
it will get merged upstream.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: libssh 0.9.7 and 0.10.5 were released

[Jakub Jelen]

On 5/9/23 19:25, Jakub Jelen wrote:

On 5/8/23 19:52, Jakub Jelen wrote:

On 5/8/23 04:05, Orion Poplawski wrote:

On 5/4/23 06:23, Jakub Jelen wrote:

Hello,

the libssh team released libssh 0.9.7 and 0.10.5, fixing previously 
announced security issues CVE-2023-1667 and CVE-2023-2283:


https://www.libssh.org/2023/05/04/libssh-0-10-5-and-libssh-0-9-7-security-releases/


We're seeing a test failure just on i686 on Fedora rawhide:

40/62 Test #40: torture_rekey ***Failed   23.34 sec
[==] tests: Running 14 test(s).
OK: SSH-2.0-OpenSSH_9.0
[ RUN  ] torture_rekey_default
[   OK ] torture_rekey_default
[ RUN  ] torture_rekey_time
[   OK ] torture_rekey_time
[ RUN  ] torture_rekey_recv
[   OK ] torture_rekey_recv
[ RUN  ] torture_rekey_send
[   OK ] torture_rekey_send
[ RUN  ] torture_rekey_different_kex
[  ERROR   ] --- 0x20 != 0x40
[   LINE   ] --- 
/builddir/build/BUILD/libssh-0.10.5/tests/client/torture_rekey.c:522: 
error: Failure!

[  FAILED  ] torture_rekey_different_kex
[ RUN  ] torture_rekey_send_compression_delayed
[   OK ] torture_rekey_send_compression_delayed
[ RUN  ] torture_rekey_recv_compression_delayed
[   OK ] torture_rekey_recv_compression_delayed
[ RUN  ] torture_rekey_server_different_kex
OK: SSH-2.0-OpenSSH_9.0
[  ERROR   ] --- 0x20 != 0x40
[   LINE   ] --- 
/builddir/build/BUILD/libssh-0.10.5/tests/client/torture_rekey.c:597: 
error: Failure!

[  FAILED  ] torture_rekey_server_different_kex
[ RUN  ] torture_rekey_server_send
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_server_send
[ RUN  ] torture_rekey_guess_send
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_send
[ RUN  ] torture_rekey_guess_wrong_send
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_wrong_send
[ RUN  ] torture_rekey_server_recv
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_server_recv
[ RUN  ] torture_rekey_guess_recv
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_recv
[ RUN  ] torture_rekey_guess_wrong_recv
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_wrong_recv
[==] tests: 14 test(s) run.
[  PASSED  ] 12 test(s).
[  FAILED  ] tests: 2 test(s), listed below:
[  FAILED  ] torture_rekey_different_kex
[  FAILED  ] torture_rekey_server_different_kex
  2 FAILED TEST(S)


any idea what might be causing that?



Hi,
I was hoping I debugged all these issues while working on the release, 
but it looks like there are still some timing/memory/architecture 
variables.


This error happens in case the rekey did not happen as expected 
(unexpected size of digest size). I was bumping the amount of sent 
data in [1] and [2] in both branches, which looked like solving the 
problem in upstream tests. Other option might be adding some sleep 
between the sending and processing the packets to make sure the server 
gets its turn, but hard to say if this would help ... the packet 
processing and rekey is asynchronous ... but there might better ways 
to do that.


[1] 
https://gitlab.com/libssh/libssh-mirror/-/commit/31a33fd2fd0fdad7c814748fdff75c7390c7f06e [0.9]
[2] 
https://gitlab.com/libssh/libssh-mirror/-/commit/dc1254d53e4fc6cbeb4797fc6ca1c9ed2c21f15c [0.10]


Regards,


 From my understanding, this is an issue of the OpenSSH in Rawhide. I 
can reliably reproduce it in mock and it goes away when I try the same 
code in Fedora 38 (regardless of architecture).


There are several patches in rawhide openssh that are missing from the 
F38 version so I will continue some investigation tomorrow.


This is a Fedora's OpenSSH bug on i686 (or OpenSSL one):

https://bugzilla.redhat.com/show_bug.cgi?id=2203241

We are still investigating the real cause.

In the meantime, the libssh in Fedora rawhide was updated with skipping 
this test. Updates in older versions are landing as they do not have 
this issue.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: libssh 0.9.7 and 0.10.5 were released

[Jakub Jelen]

On 5/8/23 19:52, Jakub Jelen wrote:

On 5/8/23 04:05, Orion Poplawski wrote:

On 5/4/23 06:23, Jakub Jelen wrote:

Hello,

the libssh team released libssh 0.9.7 and 0.10.5, fixing previously 
announced security issues CVE-2023-1667 and CVE-2023-2283:


https://www.libssh.org/2023/05/04/libssh-0-10-5-and-libssh-0-9-7-security-releases/


We're seeing a test failure just on i686 on Fedora rawhide:

40/62 Test #40: torture_rekey ***Failed   23.34 sec
[==] tests: Running 14 test(s).
OK: SSH-2.0-OpenSSH_9.0
[ RUN  ] torture_rekey_default
[   OK ] torture_rekey_default
[ RUN  ] torture_rekey_time
[   OK ] torture_rekey_time
[ RUN  ] torture_rekey_recv
[   OK ] torture_rekey_recv
[ RUN  ] torture_rekey_send
[   OK ] torture_rekey_send
[ RUN  ] torture_rekey_different_kex
[  ERROR   ] --- 0x20 != 0x40
[   LINE   ] --- 
/builddir/build/BUILD/libssh-0.10.5/tests/client/torture_rekey.c:522: 
error: Failure!

[  FAILED  ] torture_rekey_different_kex
[ RUN  ] torture_rekey_send_compression_delayed
[   OK ] torture_rekey_send_compression_delayed
[ RUN  ] torture_rekey_recv_compression_delayed
[   OK ] torture_rekey_recv_compression_delayed
[ RUN  ] torture_rekey_server_different_kex
OK: SSH-2.0-OpenSSH_9.0
[  ERROR   ] --- 0x20 != 0x40
[   LINE   ] --- 
/builddir/build/BUILD/libssh-0.10.5/tests/client/torture_rekey.c:597: 
error: Failure!

[  FAILED  ] torture_rekey_server_different_kex
[ RUN  ] torture_rekey_server_send
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_server_send
[ RUN  ] torture_rekey_guess_send
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_send
[ RUN  ] torture_rekey_guess_wrong_send
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_wrong_send
[ RUN  ] torture_rekey_server_recv
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_server_recv
[ RUN  ] torture_rekey_guess_recv
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_recv
[ RUN  ] torture_rekey_guess_wrong_recv
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_wrong_recv
[==] tests: 14 test(s) run.
[  PASSED  ] 12 test(s).
[  FAILED  ] tests: 2 test(s), listed below:
[  FAILED  ] torture_rekey_different_kex
[  FAILED  ] torture_rekey_server_different_kex
  2 FAILED TEST(S)


any idea what might be causing that?



Hi,
I was hoping I debugged all these issues while working on the release, 
but it looks like there are still some timing/memory/architecture 
variables.


This error happens in case the rekey did not happen as expected 
(unexpected size of digest size). I was bumping the amount of sent data 
in [1] and [2] in both branches, which looked like solving the problem 
in upstream tests. Other option might be adding some sleep between the 
sending and processing the packets to make sure the server gets its 
turn, but hard to say if this would help ... the packet processing and 
rekey is asynchronous ... but there might better ways to do that.


[1] 
https://gitlab.com/libssh/libssh-mirror/-/commit/31a33fd2fd0fdad7c814748fdff75c7390c7f06e [0.9]
[2] 
https://gitlab.com/libssh/libssh-mirror/-/commit/dc1254d53e4fc6cbeb4797fc6ca1c9ed2c21f15c [0.10]


Regards,


From my understanding, this is an issue of the OpenSSH in Rawhide. I 
can reliably reproduce it in mock and it goes away when I try the same 
code in Fedora 38 (regardless of architecture).


There are several patches in rawhide openssh that are missing from the 
F38 version so I will continue some investigation tomorrow.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: libssh 0.9.7 and 0.10.5 were released

[Jakub Jelen]

On 5/8/23 04:05, Orion Poplawski wrote:

On 5/4/23 06:23, Jakub Jelen wrote:

Hello,

the libssh team released libssh 0.9.7 and 0.10.5, fixing previously 
announced security issues CVE-2023-1667 and CVE-2023-2283:


https://www.libssh.org/2023/05/04/libssh-0-10-5-and-libssh-0-9-7-security-releases/


We're seeing a test failure just on i686 on Fedora rawhide:

40/62 Test #40: torture_rekey ***Failed   23.34 sec
[==] tests: Running 14 test(s).
OK: SSH-2.0-OpenSSH_9.0
[ RUN  ] torture_rekey_default
[   OK ] torture_rekey_default
[ RUN  ] torture_rekey_time
[   OK ] torture_rekey_time
[ RUN  ] torture_rekey_recv
[   OK ] torture_rekey_recv
[ RUN  ] torture_rekey_send
[   OK ] torture_rekey_send
[ RUN  ] torture_rekey_different_kex
[  ERROR   ] --- 0x20 != 0x40
[   LINE   ] --- 
/builddir/build/BUILD/libssh-0.10.5/tests/client/torture_rekey.c:522: 
error: Failure!

[  FAILED  ] torture_rekey_different_kex
[ RUN  ] torture_rekey_send_compression_delayed
[   OK ] torture_rekey_send_compression_delayed
[ RUN  ] torture_rekey_recv_compression_delayed
[   OK ] torture_rekey_recv_compression_delayed
[ RUN  ] torture_rekey_server_different_kex
OK: SSH-2.0-OpenSSH_9.0
[  ERROR   ] --- 0x20 != 0x40
[   LINE   ] --- 
/builddir/build/BUILD/libssh-0.10.5/tests/client/torture_rekey.c:597: 
error: Failure!

[  FAILED  ] torture_rekey_server_different_kex
[ RUN  ] torture_rekey_server_send
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_server_send
[ RUN  ] torture_rekey_guess_send
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_send
[ RUN  ] torture_rekey_guess_wrong_send
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_wrong_send
[ RUN  ] torture_rekey_server_recv
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_server_recv
[ RUN  ] torture_rekey_guess_recv
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_recv
[ RUN  ] torture_rekey_guess_wrong_recv
OK: SSH-2.0-OpenSSH_9.0
[   OK ] torture_rekey_guess_wrong_recv
[==] tests: 14 test(s) run.
[  PASSED  ] 12 test(s).
[  FAILED  ] tests: 2 test(s), listed below:
[  FAILED  ] torture_rekey_different_kex
[  FAILED  ] torture_rekey_server_different_kex
  2 FAILED TEST(S)


any idea what might be causing that?



Hi,
I was hoping I debugged all these issues while working on the release, 
but it looks like there are still some timing/memory/architecture variables.


This error happens in case the rekey did not happen as expected 
(unexpected size of digest size). I was bumping the amount of sent data 
in [1] and [2] in both branches, which looked like solving the problem 
in upstream tests. Other option might be adding some sleep between the 
sending and processing the packets to make sure the server gets its 
turn, but hard to say if this would help ... the packet processing and 
rekey is asynchronous ... but there might better ways to do that.


[1] 
https://gitlab.com/libssh/libssh-mirror/-/commit/31a33fd2fd0fdad7c814748fdff75c7390c7f06e 
[0.9]
[2] 
https://gitlab.com/libssh/libssh-mirror/-/commit/dc1254d53e4fc6cbeb4797fc6ca1c9ed2c21f15c 
[0.10]


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

libssh 0.9.7 and 0.10.5 were released

[Jakub Jelen]

Hello,

the libssh team released libssh 0.9.7 and 0.10.5, fixing previously 
announced security issues CVE-2023-1667 and CVE-2023-2283:


https://www.libssh.org/2023/05/04/libssh-0-10-5-and-libssh-0-9-7-security-releases/

Special thanks to GitHub Security Lab for finding these issues, many 
thanks to all the people who contribute to libssh!


May the 4th be with you!

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Restrict SSH server to execute just a single program

[Jakub Jelen]

On 4/13/23 21:41, Jose David Bravo A wrote:

[...]
And my other question is:

I implemented an SSH server using the example in ssh_server.c as a base.

The purpose of this SSH server is to only allow the execution of a 
single program, without bash, port forwarding, or agent forwarding. Will 
these additional functionalities be disabled if my callbacks are 
configured like this?:


struct ssh_server_callbacks_struct server_cb = {
         .userdata = ,
         .auth_password_function = auth_password,
         .channel_open_request_session_function = channel_open};

struct ssh_channel_callbacks_struct channel_cb = {
     .userdata = ,
     .channel_pty_request_function = pty_request,
     .channel_pty_window_change_function = pty_resize,
     .channel_shell_request_function = shell_request,
     .channel_data_function = data_function};

ssh_callbacks_init(_cb);
ssh_callbacks_init(_cb);

Or will the client be able to execute any of these "forbidden" 
functionalities?


The client should not be able to initiate any forwarding when there is 
no respective channel callback to handle them on the server side.


But it should be very easy to verify that by trying to run OpenSSH 
client with some forwarding options and observe the output.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Receiving and setting TERM env

[Jakub Jelen]

On 4/13/23 21:37, Jose David Bravo A wrote:

Hello,

I implemented an SSH server using the example in ssh_server.c as a base.

In the exec_pty function, I'm executing another program that uses ncurses.

I believe I need to pass the client's TERM environment variable to the 
PTY allocated to that client so that the ncurses program knows how to 
display itself properly. Am I correct?


How can I receive the TERM environment variable sent by the client and 
set it in the allocated PTY?


Correct. As you can see in the SSH specification, the TERM environment 
variable is passed as part of the SSH_MSG_CHANNEL_REQUEST of type 
"pty-req" so in your code you should find it in your ssh_message 
structure when you handle this message under msg->channel_request.TERM.


https://www.rfc-editor.org/rfc/rfc4254#section-6.2

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Issues with ssh_channel_accept_forward() and reverse port forwarding

[Jakub Jelen]

On 4/12/23 11:36, Jakub Jelen wrote:

On 4/10/23 23:29, Orion Poplawski wrote:

It appears from reading
https://api.libssh.org/stable/libssh_tutor_forwarding.html that in 
order to

implement reverse port forwarding one must continually call
ssh_channel_accept_forward() in order to accept any possible 
connections from

the remote side.  Is this correct?

It presents a couple challenges:

* It's a very inefficient method - polling vs. event driven

* It can generate a huge amount of log messages as 
ssh_channel_accept() logs

an error every time it is called and there is nothing to accept:

[2023/04/10 12:17:34.044502, 1] ssh_channel_accept:  No channel 
request of

this type from server

See also https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1421

So:

* If polling is indeed the only mechanism available here, libssh 
should not be

emitting an error in this case.  Possibly a DEBUG or TRACE level message
instead, but honestly enabling it for anything like x2goclient that does
continual polling will just swamp the logs.

* Is there a possibility of implementing a callback method to accept 
remote

connections?


 From what I read, this is about the client side logs. I think 
downgrading the message to DEBUG or TRACE would be the least thing we 
can do and it sounds like a reasonable solution. Do you want to open a 
merge request?


Regarding the polling, the tutorial is quite dated so it does not 
provide any information about the connectors and callbacks. Right now, 
there are x11 and auth_agent callbacks available in the channels. Adding 
a similar handler into the ssh_execute_client_request() for handling 
SSH_CHANNEL_FORWARDED_TCPIP should not be hard. I think the reason it is 
not there yet is that nobody asked for that before or nobody implemented 
this.


Skiming through the issue tracker, there is an request for this 
actually, even with a patch, but it will require some work and test 
coverage to get merged:


https://gitlab.com/libssh/libssh-mirror/-/issues/43
Oh, my bad. This request is about server side. But the client side 
should be very similar though. Please, open a new issue tracking this. 
Or MR if you would like to contribute the changes.


Rerards.
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Issues with ssh_channel_accept_forward() and reverse port forwarding

[Jakub Jelen]

On 4/10/23 23:29, Orion Poplawski wrote:

It appears from reading
https://api.libssh.org/stable/libssh_tutor_forwarding.html that in order to
implement reverse port forwarding one must continually call
ssh_channel_accept_forward() in order to accept any possible connections from
the remote side.  Is this correct?

It presents a couple challenges:

* It's a very inefficient method - polling vs. event driven

* It can generate a huge amount of log messages as ssh_channel_accept() logs
an error every time it is called and there is nothing to accept:

[2023/04/10 12:17:34.044502, 1] ssh_channel_accept:  No channel request of
this type from server

See also https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1421

So:

* If polling is indeed the only mechanism available here, libssh should not be
emitting an error in this case.  Possibly a DEBUG or TRACE level message
instead, but honestly enabling it for anything like x2goclient that does
continual polling will just swamp the logs.

* Is there a possibility of implementing a callback method to accept remote
connections?


From what I read, this is about the client side logs. I think 
downgrading the message to DEBUG or TRACE would be the least thing we 
can do and it sounds like a reasonable solution. Do you want to open a 
merge request?


Regarding the polling, the tutorial is quite dated so it does not 
provide any information about the connectors and callbacks. Right now, 
there are x11 and auth_agent callbacks available in the channels. Adding 
a similar handler into the ssh_execute_client_request() for handling 
SSH_CHANNEL_FORWARDED_TCPIP should not be hard. I think the reason it is 
not there yet is that nobody asked for that before or nobody implemented 
this.


Skiming through the issue tracker, there is an request for this 
actually, even with a patch, but it will require some work and test 
coverage to get merged:


https://gitlab.com/libssh/libssh-mirror/-/issues/43

Help is always welcomed.

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: GSoC 2023

[Jakub Jelen]

On 3/28/23 01:02, Igor Putovny wrote:

Dear all,

I am an undergraduate student of computer science and I am interested in 
participating in libSSH GSoC project.


I took a look at project ideas and I would be interested in /Support for 
OpenSSH connection multiplexing/ and /Support for FIDO/U2F keys on the 
client side/.


I would like to ask you for more information about the scope of these 
projects and other knowledge or skills you may be expecting.


Thank you very much for your time.


Hi,
please read through the mailing list history for last months. We are 
getting many very similar questions like this. Read also through the 
page describing the GSoC requirements [1].


We already had couple of people asking for the FIDO project (but no 
proposal submitted yet), but I am not aware of anyone interested in the 
connection multiplexing.


I hope the description on the website with the links should give you 
some basic information to get you started, think about the problem and 
ask some questions. We would be happy to answer specific questions 
either here on mailing list or on matrix/irc channels.


[1] https://www.libssh.org/development/google-summer-of-code/

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: GSOC 2023 participation

[Jakub Jelen]

On 3/25/23 12:11, shivam tiwari wrote:

Hello
My name is Shivam Tiwari and I am very interested in participating in 
GSOC for the Ivy repository. I have reviewed the project requirements 
and feel that my skills and experience align with what the project is 
looking for.


Ivy or libssh?

I am a Final year Engineering CS student with experience in open source 
Python,C/C++. I am excited to contribute to the libssh repository and 
learn more about Security and Cryptography
Here is my Github Profile link:- https://github.com/Shivam7-1 
<https://github.com/Shivam7-1>

I have question:-
In this year How many Student are selecting by libssh?


I was just answering in the other thread that we count with one or max 
two students. We are small organization.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: GSOC query

[Jakub Jelen]

On 3/25/23 12:09, shivam tiwari wrote:

Hello mentor
I have one question that how many Students are will be accepted by 
libssh for GSOC 2023 project ?


Hello,
libssh is a small organization so we will be accepting only one or 
maximum two students if there will be very good project proposals. We 
need to make sure we can give you full attention throughout the summer, 
guide you through the project, provide feedback and help you succeed.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Unable to compile 0.10.4 on Windows

[Jakub Jelen]

On 3/20/23 15:50, Kerrison, Adam wrote:
I’ve been trying to build 0.10.4 on Windows using VS 2015 Update 3 
(community) as we are moving things to OpenSSL 3.x


Here is what I am running (from a VS developer prompt):

cmake -G "Visual Studio 14 2015 Win64" C:\srclibssh-0.10.4 
-DCMAKE_INSTALL_PREFIX=C:\builds  -DCMAKE_BUILD_TYPE=Releasee 
-DCMAKE_SYSTEM_VERSION=6.1  -DOPENSSL_ROOT_DIR=C:\pkgs\openssl-3.0.8 
-DZLIB_INCLUDE_DIR=C:\pkgs\zlib-1.2.11\include 
-DZLIB_LIBRARY_DEBUG=C:\pkgs\zlib-1.2.11\lib\zlibwapi.lib 
-DZLIB_LIBRARY_RELEASE=C:\pkgs\zlib-1.2.11\lib\zlibwapi.lib 
-DCMAKE_USE_WIN32_THREADS_INIT=1 -DWITH_SERVER=ON -DWITH_GSSAPI=ON


And I get:

-- The C compiler identification is unknown

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - failed

-- Check for working C compiler: C:\Program Files (x86)\Microsoft Visual 
Studio 14.0\VC\BIN\x86_amd64\cl.exe


-- Check for working C compiler: C:\Program Files (x86)\Microsoft Visual 
Studio 14.0\VC\BIN\x86_amd64\cl.exe - broken


CMake Error at C:/Program 
Files/CMake/share/cmake-3.26/Modules/CMakeTestCCompiler.cmake:67 (message):


   The C compiler

     "C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\BIN\x86_amd64\cl.exe"


   is not able to compile a simple test program.

   It fails with the following output:

     Change Dir: C:/builds/CMakeFiles/CMakeScratch/TryCompile-ix1aqv

     Run Build Command(s):C:/Program Files 
(x86)/MSBuild/14.0/bin/MSBuild.exe cmTC_7d48c.vcxproj 
/p:Configuration=Debug /p:Platform=x64 /p:VisualStudioVersion=14.0 /v:n 
&& Microsoft (R) Build Engine version 14.0.25420.1


     Copyright (C) Microsoft Corporation. All rights reserved.

     Build started 20/03/2023 14:36:06.

     Project 
"C:\builds\CMakeFiles\CMakeScratch\TryCompile-ix1aqv\cmTC_7d48c.vcxproj" 
on node 1 (default targets).


     PrepareForBuild:

   Creating directory "cmTC_7d48c.dir\Debug\".

   Creating directory 
"C:\builds\CMakeFiles\CMakeScratch\TryCompile-ix1aqv\Debug\".


   Creating directory "cmTC_7d48c.dir\Debug\cmTC_7d48c.tlog\".

     InitializeBuildStatus:

   Creating "cmTC_7d48c.dir\Debug\cmTC_7d48c.tlog\unsuccessfulbuild" 
because "AlwaysCreate" was specified.


     ClCompile:

   C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\bin\x86_amd64\CL.exe /c /W1 /WX- /O2 /D _MBCS /D 
"CMAKE_INTDIR=\"Debug\"" /Gm- /MD /GS /fp:precise /Zc:wchar_t 
/Zc:forScope /Zc:inline /Fo"cmTC_7d48c.dir\Debug\\" 
/Fd"cmTC_7d48c.dir\Debug\vc140.pdb" /Gd /TC /errorReport:queue 
"C:\builds\CMakeFiles\CMakeScratch\TryCompile-ix1aqv\testCCompiler.c"


     TRACKER : error TRK0002: Failed to execute command: ""C:\Program 
Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\CL.exe" 
@C:\Users\adam\AppData\Local\Temp\tmpb254535fb3324f56bea10ac7806c08c6.rsp". The operation completed successfully. [C:\builds\CMakeFiles\CMakeScratch\TryCompile-ix1aqv\cmTC_7d48c.vcxproj]


Its failed but the operation completed successfully!? I found the C code 
its trying to compile and I can compile that manually without issue.


I don’t know enough about cmake to debug this – can anyone give me some 
pointers?


I realize this is an old compiler but it was already installed so I was 
trying to use it for some tests … I can upgrade but I would like to 
avoid that if there is a simpler solution


Hi,
I am not a windows developer so I do not have much experience with 
building with VS. The version 14 is not one of the latest so before 
debugging further, I would try with some newer compiler. We are now 
running a CI with VS 15 and it works just ok:


https://gitlab.com/libssh/libssh-mirror/-/jobs/3963003368

You can check how the libssh is built in the ci also in our gitlab 
configuration to make sure all dependencies are installed on your side:


https://gitlab.com/libssh/libssh-mirror/-/blob/master/.gitlab-ci.yml#L459

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: GSOC Project discussion : Async sftp implementation

[Jakub Jelen]

On 3/20/23 15:41, Eshan Kelkar wrote:

Hi Jakub,

The description of the project in [1] is written in the more high-level
way, which would basically mean creating some "SFTP IO structure" with
information about chunksize, max number of on-the-fly transfers, local
FD and remove SFTP handle and this would handle calling the low-level
functions we discuss above, transparently. Just having the file
descriptor inside of libssh might already avoid one copy from the
application buffer to libssh.


Thanks for this description, it's clear now that a high level api
(which internally uses a low level api) for async upload and download is
to be created  as a part of this project.

Apart from this, should creation of async variants of
sftp_open, sftp_opendir, sftp_readdir, sftp_stat etc also be
a part of this project?


No, these are really simple commands that return just couple of bytes of 
data in very short time. Having these functions with async semantics 
will not give us any advantage from the synchronous version as there is 
really not much we could split (unlike in case of reading or writing, 
which can be megabytes or gigabytes of data that needs to be transferred 
and that can be simply split to chunks and handled async).



(I believe once async read and write are provided the user may expect
async variants of the these functionalities too, so creating async
variants of them should also be a part of this project)


As you can see in the benchmarks_async_sftp_down(), the async part is 
only the download/read.


The async variant could be useful if you would like to download/upload 
several files in parallel and would not want to be blocked on opening a 
new file, but still I believe the performance improvement would be 
negligible.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Record SSH session

[Jakub Jelen]

On 3/16/23 02:53, Jose David Bravo A wrote:

Hello,

Is there any way to record a SSH session, like script/replayscript 
functionality but using libssh?


If that's not a functionality that the lib has, may you please point me 
in the direction of how this can be implemented, for example using 
ssh_client.c ?


There is no functionality for this in libssh. There are several 
standalone tools, for example tlog (which is nicely integrated in RHEL).


It really depends on your use case, if you want to record it on the 
client or on the server or if you have some pre-existing tools or 
formats for storing recordings.


If you are up to the client, the ssh client example is using connectors 
for the IO handling. To plug the recording in, I think you can create 
your own callbacks that would do the logging and call the default 
callbacks (or reimplement them as they do not look like part of the API):


https://gitlab.com/libssh/libssh-mirror/-/blob/master/examples/ssh_client.c#L206

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: GSOC Project discussion : Async sftp implementation

[Jakub Jelen]

tion :)

Best regards,
Jakub



Thanks,
Eshan



On Tue, Mar 7, 2023 at 4:52 PM Jakub Jelen <mailto:jje...@redhat.com>> wrote:


On 3/7/23 10:58, Eshan Kelkar wrote:
 > Hello Jakub,
 >
 >     I would suggest starting from the benchmark code
 >     we have in tests/benchmarks/, which has an example of async
donwload
 >     (but there is only the download part -- the upload part does not
 >     exist now).
 >
 >
 > As per your suggestion, I have read that example and have gone
through
 > the source code to understand how the current async read is working
 > using sftp_async_read_begin and sftp_async_read. Please correct
me if I
 > am wrong but the way I understand how the api currently works is
like this.
 >
 > First let me go through the synchronous read function which will
help us
 > to better understand how the async read api works :
 >
 > [sync_read refers to the sftp_read function in normal(blocking
mode) in
 > src/sftp.c]
 > sync_read(file_handle, buffer_to_read_into, count)
 > {
 > NOTE : In the text sftp session refers to the session
corresponding to the
 > file_handle received in the  parameter
 >
 > //Phase-1 (Registering the request)
 > //--
 > Step- 1 : Get an id for this read request with respect to the sftp
 > session corresponding
 > to the file whose handle is received in the parameter.
 > Step-2 : Pack  a ssh_buffer with the id, file handle, offset and
count
 > of bytes to read.
 > Step-3 : Write a packet using sftp_packet_write to send a read
request
 > along with
 > this ssh_buffer.
 > Step-4 : After a successful Step-3 free this ssh_buffer as its no
longer
 > needed and
 > its data has been sent along with the packet
 >
 > //Phase-2(Waiting for the request to get processed)
 > 
 > Now the packet gets sent along with the request id. The server
processes it
 > and sends a packet back again containing the same id as in the
request.
 > The id is kept the same to match the request and response. The
incoming
 > packets
 > from the server are read using sftp_packet_read_and_dispatch
which reads
 > a packet
 > and adds it to a queue of messages from the server corresponding
to this
 > sftp session.
 >
 > The waiting is done like this
 > msg=NULL;
 > while(msg==NULL)
 > {
 > read_and_dispatch - read a response packet and add message to queue
 > sftp_dequeue - try to dequeue a message from the queue
corresponding to
 > the id we got in Phase-1 and assign whatever it returns to the msg
 > variable. In case
 > the queue doesn't contain any message with the id of Phase-1 the
dequeue
 > function
 > returns NULL which gets assigned to msg and the loop runs again.
 > }//while(msg==NULL) ends
 >
 > After we receive the message corresponding to the send request.
 > If the message contains some data(i.e msg->packet_type is
SSH_FXP_DATA),
 > write that data in the location whose address has been received
in the
 > parameter.
 >
 > So the loop of Phase-2 is responsible for the waiting, which is
 > essentially reading the
 > response packet adding the message received in it to a
 > queue(corresponding to a sftp session)
 > and then the loop checks whether the response received was
corresponding
 > to the request sent
 > (matching of request and response based on the id of Phase-1) and
if not
 > then the loop runs again.
 > }//sync_read ends

This sounds correct.

 > This explanation of synchronous read is important to understand
how the
 > asynchronous read currently
 > works, asynchronous read api is divided into two functions
 > sftp_async_read_begin and sftp_async_read
 >
 > sftp_async_read_begin(file_handle, count)
 > {
 > Phase-1's code(Registering request by sending a packet) of sync_read
 > comes here
 > and return the id for the request to the user which he'll pass while
 > calling sftp_async_read
 > }
 >
 > sftp_async_read(file_handle, where_to_store, bytes_to_read,
request_id)
 > {
 > Phase-2's code to wait for the response message corresponding to the
 > request with that
 > request_id as received in parameter and then writing the data
which came
 > in that message
 > comes here
 > }

Correct.

 > Now one prob

Re: GSOC Project discussion : Async sftp implementation

[Jakub Jelen]

is ready and then a lot of waiting, which will rapidly 
increase in case the remote host is far away. This is not very suitable 
if we are striving for high throughput and speeds for the transfers such 
as in SFTP.


If you build the benchmarks under the libssh, you can test the speeds 
yourself (against localhost it is not very informative as when you would 
try to transfer the data across the half of the country or Earth, but it 
should give you the idea)


[jjelen@t490s obj (poll-block)]$ ./tests/benchmarks/benchmarks  -h localhost
ping RTT : 0.065000 ms
SSH request times : 0.134000 ms ; 0.094000 ms ; 0.063000 ms
SSH RTT : 0.097000 ms. Theoretical max BW (win=128K) : 1.319588 Gbps
parse error :
localhost : benchmark_raw_download : 746.649597 Mbps
localhost : benchmark_sync_sftp_upload : 9.228348 Mbps
localhost : benchmark_sync_sftp_download : 94.978531 Mbps
localhost : benchmark_async_sftp_download : 6.836124 Gbps


Hence according 
to me sftp_async_read_begin
may also block if say the channel corresponding to that sftp session is 
too much saturated/dirty

with pending writes.


Correct. But given that for the download we write just the requests, 
this is very unlike case, but certainly worth investigating. This is 
much more likely to happen on the sending side (for example with the 
async upload).


So technically this operation is not an 
asynchronous one, its synchronous in
the sense that the control will return after the packet for registering 
the read request has been written

to the underlying send buffer (corresponding to the channel).

So is this current state of async read acceptable ?


Yes, but the blocking properties would be worth investigating and 
improve if time permits anyway.


One may argue that the chances of blocking in case of registering a read 
request are less
because we're sending less info in the packet  : request id, from where 
we have to read and from
what offset, but still a scope for blocking still exists and certainly 
this kind of approach won't work for async write.
As in the write request we also send the data to write using 
sftp_packet_write and in this case the chances of

blocking are significant if too much data is to be sent.


Correct (as I mentioned above before finalizing reading your whole message).

Kindly comment on my interpretation of the code, and answer whether the 
current state of async
read is as desired or not. If not, please give a rough overview of how 
it should be and

what is expected out of the async libssh api.


This async API exists only for the upload so the upload speeds 
(sftp_write) are several orders of magnitude slower. And we need to 
support this direction too, which is the main part of the project.


(For example - my interpretation of the async read is that user issues a 
read
request using an api function call, the function returns and he 
continues to do
what he wants to do while the the read request is handled by the api and 
the
data received from the server is written to the buffer supplied by the 
user. API has some
means to communicate[via callbacks or some data structure of which user 
has access]

to the user about the state of the operation)


I do not think we want an async in this extent that the user would be 
able to do anything and the stuff would just happen in the "background". 
The calling application still needs to drive the uploads/downloads, 
either via callbacks or be in control of how many "concurrent" request 
of writes are issued.


Moving the whole logic to io_uring will certainly add some additional 
complexity and make it less compatible (as mentioned by others) so if we 
can do without that, it is probably my preference.


Hope, it helps. Let me know if you will need some more clarifications.

Regards,
Jakub



Thanks,
Eshan Kelkar




On Sun, Mar 5, 2023 at 5:30 PM Jakub Jelen <mailto:jje...@redhat.com>> wrote:


On 3/3/23 06:36, Eshan Kelkar wrote:
 > Hi, I am Eshan Kelkar and would like to create the async sftp for
libssh
 > as the GSOC project. I have gone through liburing to understand what
 > async i/o is and how it is implemented using io_uring. So in this
async
 > sftp implementation I believe we can place calls to the liburing api
 > functions from inside of the async sftp api functions so that things
 > occur asynchronously.
 >
 > Another approach that comes to my mind is that on a call to async
sftp
 > api function a seperate thread gets created which does the
waiting and
 > all and on completion places a call to the callback function
notifying
 > that the operation has occurred. The second approach is async
 > conceptually as the user of api can continue his job after the
call as
 > the waiting occurs on the separate thread but this approach seems
a bit
 > "naive" as for each api call a new thread gets created which is
 

Re: GSOC Project discussion : Async sftp implementation

[Jakub Jelen]

On 3/3/23 06:36, Eshan Kelkar wrote:
Hi, I am Eshan Kelkar and would like to create the async sftp for libssh 
as the GSOC project. I have gone through liburing to understand what 
async i/o is and how it is implemented using io_uring. So in this async 
sftp implementation I believe we can place calls to the liburing api 
functions from inside of the async sftp api functions so that things 
occur asynchronously.


Another approach that comes to my mind is that on a call to async sftp 
api function a seperate thread gets created which does the waiting and 
all and on completion places a call to the callback function notifying 
that the operation has occurred. The second approach is async 
conceptually as the user of api can continue his job after the call as 
the waiting occurs on the separate thread but this approach seems a bit 
"naive" as for each api call a new thread gets created which is resource 
expensive.


Kindly comment on these two approaches and suggest any other approach 
which you have in mind to implement the async sftp api, those 
suggestions will help me prepare better before sending in the proposal.


Hello Eshan,
first of all, sorry for late reply. I saw your message on IRC, but 
before I got back to reply, you were already away so thank you for 
patience to reach out to us on other channels.


The async SFTP implementation is one of our priorities and one of the 
more complicated tasks. I would suggest starting from the benchmark code 
we have in tests/benchmarks/, which has an example of async donwload 
(but there is only the download part -- the upload part does not exist now).


I do not think it is a good idea to spawn more threads as it would 
require a lot of synchronization. The example in the benchmarks can run 
several download requests from a single thread, which can help saturate 
the network connection without the need for threads.


I did not read much about io_uring yet, but it sounds like it solves the 
issues we have with speed of synchronous writes/reads caused by context 
switching so this would be our preference. There are already some 
hints/comments in the following issues, so if you will have some more 
questions, comments, feel free to ask here or in either of the following 
issues:


https://gitlab.com/libssh/libssh-mirror/-/issues/65
https://gitlab.com/libssh/libssh-mirror/-/issues/124

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

locked sockets in poll and server blocking issue

[Jakub Jelen]

Hi Aris,
I spent last couple of weeks figuring out an issue we hit with the sftp 
server that large packets were blocking the libssh server indefinitely 
because of the poll socket is locked in the nested call to poll, but the 
packet writing code attempts to do blocking write.


My question is mostly regarding the lock in the poll code. My 
understanding is that its main purpose is to avoid the callbacks on the 
incoming packets being called recursively (which is never a good idea), 
but I think the lock should not affect the POLLOUT events to avoid 
deadlocks like this.


What do you think? The issue is described in [1] with reproducer in [2]. 
I have proposed a fix in [3] but I am not sure what all side effects 
this could have.


Aris, as you wrote most of this code, can you have a look if my analysis 
makes sense or if I miss something?


[1] https://gitlab.com/libssh/libssh-mirror/-/issues/181
[2] https://gitlab.com/libssh/libssh-mirror/-/merge_requests/340
[3] 
https://gitlab.com/libssh/libssh-mirror/-/merge_requests/345/diffs?commit_id=cc0d146a76dc3ba7bbca66e2666abebd9f4087dc


Thanks,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Hardware device

[Jakub Jelen]

11:token=CryptoServer%20Token0;object=SSH-key doesn't exist.


[2022/12/22 17:49:00.601394, 3] ssh_userauth_publickey_auto:  Trying to 
authenticate with C:\Users\Dennis/.ssh/id_ed25519


[2022/12/22 17:49:00.632921, 1] ssh_pki_import_pubkey_file:  Error 
opening C:\Users\Dennis/.ssh/id_ed25519.pub: No such file or directory


[2022/12/22 17:49:00.648312, 1] ssh_pki_import_privkey_file:  Error 
opening C:\Users\Dennis/.ssh/id_ed25519: No such file or directory


[2022/12/22 17:49:00.679591, 3] ssh_userauth_publickey_auto:  Private 
key C:\Users\Dennis/.ssh/id_ed25519 doesn't exist.


[2022/12/22 17:49:00.695713, 3] ssh_userauth_publickey_auto:  Trying to 
authenticate with C:\Users\Dennis/.ssh/id_ecdsa


[2022/12/22 17:49:00.726494, 1] ssh_pki_import_pubkey_file:  Error 
opening C:\Users\Dennis/.ssh/id_ecdsa.pub: No such file or directory


[2022/12/22 17:49:00.757865, 1] ssh_pki_import_privkey_file:  Error 
opening C:\Users\Dennis/.ssh/id_ecdsa: No such file or directory


[2022/12/22 17:49:00.773702, 3] ssh_userauth_publickey_auto:  Private 
key C:\Users\Dennis/.ssh/id_ecdsa doesn't exist.


[2022/12/22 17:49:00.805660, 3] ssh_userauth_publickey_auto:  Trying to 
authenticate with C:\Users\Dennis/.ssh/id_rsa


[2022/12/22 17:49:00.836304, 1] ssh_pki_import_pubkey_file:  Error 
opening C:\Users\Dennis/.ssh/id_rsa.pub: No such file or directory


[2022/12/22 17:49:00.851924, 1] ssh_pki_import_privkey_file:  Error 
opening C:\Users\Dennis/.ssh/id_rsa: No such file or directory


[2022/12/22 17:49:00.883218, 3] ssh_userauth_publickey_auto:  Private 
key C:\Users\Dennis/.ssh/id_rsa doesn't exist.


[2022/12/22 17:49:00.914533, 2] ssh_userauth_publickey_auto:  Tried 
every public key, none matched


User Authentication failed:

[2022/12/22 17:49:00.929338, 3] packet_send2:  packet: wrote [type=1, 
len=32, padding_size=11, comp=20, payload=20]


Error allocating SFTP session

-----Original Message-
From: Jakub Jelen 
Sent: Wednesday, December 7, 2022 4:21 AM
To: libssh@libssh.org
Subject: Re: Hardware device

On 12/5/22 14:38, Dennis Gnatowski wrote:

 > I am following the example from

 > 
(https://developers.redhat.com/blog/2020/10/28/smart-cards-support-in- 
<https://developers.redhat.com/blog/2020/10/28/smart-cards-support-in->


 > libssh#build_and_use_libssh_with_pkcs__11

 > <https://developers.redhat.com/blog/2020/10/28/smart-cards-support-in-

 > libssh#build_and_use_libssh_with_pkcs__11>)

 >

 >    int rc;

 >

 >    char priv_uri[1042] =

 > “pkcs11:token=my-token;object=my-object;type=private?pin-value=1234”;

 >

 >    rc = ssh_options_set(session, SSH_OPTIONS_IDENTITY, priv_uri);

 >

 >    assert_int_equal(rc, SSH_OK)

 >

 >    rc = ssh_userauth_publickey_auto(session, NULL, NULL);

 >

 > but using:

 >

 > char priv_uri[1042] =

 > "pkcs11:object=SSH-key-acme?pin-value=;manufacturer=IBM?module-pat

 > h=/usr/lib64/pkcs11/PKCS11_API.so";

This does not look like a valid URI. There can be only one question 
mark, path is separated by semicolons and query parts are separated by 
ampersands so it should be something like:


pkcs11:object=SSH-key-acme;manufacturer=IBM?pin-value==/usr/lib64/pkcs11/PKCS11_API.so

see the uri syntax in https://datatracker.ietf.org/doc/html/rfc7512 
<https://datatracker.ietf.org/doc/html/rfc7512>


Regards,

--

Jakub Jelen

Crypto Team, Security Engineering

Red Hat, Inc.



--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Hardware device

[Jakub Jelen]

On 12/5/22 14:38, Dennis Gnatowski wrote:
I am following the example from 
(https://developers.redhat.com/blog/2020/10/28/smart-cards-support-in-libssh#build_and_use_libssh_with_pkcs__11 <https://developers.redhat.com/blog/2020/10/28/smart-cards-support-in-libssh#build_and_use_libssh_with_pkcs__11>)


   int rc;

   char priv_uri[1042] = 
“pkcs11:token=my-token;object=my-object;type=private?pin-value=1234”;


   rc = ssh_options_set(session, SSH_OPTIONS_IDENTITY, priv_uri);

   assert_int_equal(rc, SSH_OK)

   rc = ssh_userauth_publickey_auto(session, NULL, NULL);

but using:

char priv_uri[1042] = 
"pkcs11:object=SSH-key-acme?pin-value=;manufacturer=IBM?module-path=/usr/lib64/pkcs11/PKCS11_API.so";


This does not look like a valid URI. There can be only one question 
mark, path is separated by semicolons and query parts are separated by 
ampersands so it should be something like:


pkcs11:object=SSH-key-acme;manufacturer=IBM?pin-value==/usr/lib64/pkcs11/PKCS11_API.so

see the uri syntax in https://datatracker.ietf.org/doc/html/rfc7512

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Hardware device

[Jakub Jelen]

On 12/3/22 17:46, Dennis Gnatowski wrote:
I’m trying to use the library with keys stored in a hardware device to 
transfer file(s) via SFTP to a remote server.


I did get things working using the sftp client (Linux) with the “-i 
” and “-o ” options.


This is OpenSSH, completely different implementation than libssh. But 
the usage should be as close as possible.


I tried putting the PKCS11 URI in the SSH_OPTIONS_IDENTITY option with 
no success.


What errors you got? Libssh 0.10.x should already have support for the 
pkcs11 uris.



How do I specify or pass-in the PKCS11 Provider to the library?


In Fedora, the libssh is using p11-kit proxy, which groups all the 
registered in p11-kit. Or you can pass the pkcs11 provider path through 
the pkcs11 uri.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Secuirty devroom at FOSDEM 2023

[Jakub Jelen]

Hi all,
we are once again organizing Security dervoom on next year FOSDEM 2023. 
Do you have some interesting project or topic you would like to share 
with open-source community related to libssh or to security in general? 
It would be great to see you there!


All the information is available on the github or on official website:

https://github.com/security-devroom/fosdem-2023
https://fosdem.org/2023/schedule/track/security/

If you are planning to come along and say hi, it would be great to meet 
in you person.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Review swap for python-tpm2-pytss

[Jakub Jelen]

Hi all,
I am looking forward getting the above package into Fedora, which is now 
a dependency for a package I already maintain, tpm2-pkcs11.


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2135713


Thanks,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Getting error string from a failed ssh command

[Jakub Jelen]

On 10/4/22 00:36, Norm Green wrote:

Hello libssh list,

If I run a command over ssh that fails from the Linux command line:

normg@moop>ssh hood foo
bash: foo: command not found
normg@moop>echo $?
127


I get an error string ("bash: foo: command not found") and an error code 
(127). For example:

My question is how to do the equivalent with libssh ?
If I do this after opening a session and a channel:

int rc = ssh_channel_request_exec(sshChannel, "foo");
int bytesReady = ssh_channel_poll_timeout(sshChannel, timeout, FALSE);

returns -127 and:

int numRead = ssh_channel_read_timeout(sshChannel,
                      resultBuffer.nextWriteByte(),
                      (int) resultBuffer.bytesFree(),
                      0, // timeout: block in poll, not here
                      0);

returns 0, so I don't get the error string back from libssh.
How can I get the error string result from the failed command using 
libssh ?


I think you need to set the `is_stderr` argument of the 
`ssh_channel_read_timeout()` to true to get this message as it will most 
likely be on the standard error instead of standard output you are querying.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: X.509 certificate support

[Jakub Jelen]

On 7/26/22 11:13, Roman Janota wrote:

Hello,

I was wondering if there is a support for authentication via X.509 
certificate (as this email archive 
<https://archive.libssh.org/libssh/2015-03/000.html> suggests). If 
it can be done, is it possible to extract the client's certificate on 
the server side after a successful authentication? If so, can you please 
clarify which API calls to use. Thank you in advance.


Hi,
it is not possible to use X.509 certificates for authentication in 
libssh. There is RFC 6187 and there are patches for OpenSSH to work with 
raw X.509 certificates, but they were never merged into the upstream 
because it hugely increases attack surface:


https://roumenpetrov.info/secsh/index.html

Instead, the OpenSSH developers implemented a SSH certificates that 
partially work also in libssh. These are discussed in the above 
mentioned link, but the libssh supports them only as a opaque blobs read 
from files so they are usable only for the client side authentication. 
The server side implementation is still missing.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Parsing private key PK - Invalid key tag or value

[Jakub Jelen]

uy53N8qwsv1p7zJshg0aoYbM7EOyo9sVawQCaYrA06kHxmPFZkD0f6XR2GZCAZIHseZDJFuHS9QLXnxE85Ajp5iL_qFzl8rGWGBEvfOypszgAoYNMjY3H__cU4lzbZlmS_Wb7STXlEi44rHpxHF0HqJPkQL43QD3_tEF0KY0wQKBgAOxz9XiHqAJpHvGFA5Fnn_SorbrSEUNrGLFz7ixg56UqBZjig4Rb4pQsgpDWtYhaR9gkFC8jSD7AlVQI7Oj1-C6DjCiLF1gVzlfQujzVF0sE2i91dT4R3Jo52xBE9VPMZXXUqJa2UaysfGRaEINRhZK-_bIVVvyF_oWoNuxX0aJAoGBAMcM73tUL5Dn6Fh9ASqjqJF_pS7ZTAq7cPFv93kLy-VYaaD45Pf4e-W_YeqFX96epBddVNZyWlOFjpHVawy5qmB_i94LxBaOy4nxMWqowpQ0bqeTj3rj3rmUIdCdaQ4Ng_rD-VysOtn4JxQiZc5mDZ0zY4t88jAZtYqYHDgxQkyL

And it looks like the MbedTLS does not know how to parse these keys

There is a bit more about it in

https://crypto.stackexchange.com/questions/35093/why-ssh-gen-makes-difference-between-pem-and-pkcs8

For the question whether the headers matter or not:

https://stackoverflow.com/questions/20065304/differences-between-begin-rsa-private-key-and-begin-private-key

When going through the implementation, the openssl is much less strict 
about them but the mbedtls is quite picky and if you mix them, it will 
notwork. Moreover, libssh supports now in the mbedtls backend only the 
legacy PEM headers (with key type in) and the PKCS8 ones are rejected.


I refactored a bit the mbedtls implementaiton of key parsing in so it is 
able to parse the keys you provided in the previous email. Can you check 
if this solves your issue (indeed after fixing your key headers):


https://gitlab.com/libssh/libssh-mirror/-/merge_requests/260

I would like to give it a better look to cross check the various key 
types and formats against libgcrypt and openssl too.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Keep alive the session after remote execution of the commands

[Jakub Jelen]

On 6/30/22 10:42, Javad Rahimi wrote:

Hello,

We have developed a simple ssh client application based on this 
<https://api.libssh.org/stable/libssh_tutor_command.html> example 
(libssh: Chapter 4) to run a command remotely and return the results. 
However, the ssh server disconnects the connection after executing the 
command and returning the result.

However, it doesn't happen for all SSH servers.
Is there any way to force the ssh server to keep alive the session after 
executing


I think this depends on the server configuration. OpenSSH servers by 
default allow creating more channels/sessions per connection 
(MaxSessions default is 10 in sshd_config), but if you connect to other 
SSH implementation or if somebody configured the server not to allow 
opening more sessions/channels, then this might fail.


Please, review the server configuration, but if the server 
configuration/implementation does not allow this, there is nothing else 
you could do. Only run all the commands as part of the shell as 
mentioned by Andreas previously.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Keep alive the session after remote execution of the commands

[Jakub Jelen]

On 6/30/22 13:38, Javad Rahimi wrote:


Hi Antenore,

Thank you very much. I have attached my demo code.


Its always helpful to see a libssh client and server debug logs to get a 
grasp of what is going on there, where, why and what is actually failing 
in the code.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Parsing private key PK - Invalid key tag or value

[Jakub Jelen]

On 6/30/22 07:43, Heiko Thiery wrote:

Hi,

I use netopeer2 with libnetconf2 in combination with libssh and
mbedtls. When trying to open a SSH connection I get the following
message:

[INF]: LN: Accepted a connection on 0.0.0.0:830 from 127.0.0.1:38712.
[INF]: SR: Session 128 (user "root", CID 38) created.
[2022/06/28 07:31:06.841984, 1] pki_private_key_from_base64:  Parsing
private key PK - Invalid key tag or value
[ERR]: LN: Failed to set hostkey "genkey" (/tmp/gyFsev).

Switching to use openSSL does not show this error.

Anyone have an explanation for this?


Do you have example key with this issue?

I think the mbedtls and gcrypt did not have PEM parser or there were 
some limitations.


It might also be that the openssl you are using is generating keys with 
some specific functionality that is not supported by mbedtls parser.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Pageant support in libssh

[Jakub Jelen]

Hi,
we are going through some older issues and found your commit in regards 
to adding pageant support, but unfortunately, without a needed sign-off:


https://gitlab.com/libssh/libssh-mirror/-/issues/45

Are you still interested in this feature? Can you submit it as a merge 
request on the gitlab? It will probably require some more work to get it 
into the shape where both ssh-agent and pageant can be used on windows, 
but it looks like there are people interested, see for example the 
following PR:


https://gitlab.com/libssh/libssh-mirror/-/merge_requests/202

Thanks,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Libssh merge requests regarding compiler options

[Jakub Jelen]

Hi Carlo,
I am writing to you regarding your merge requests, which are missing 
your sign-off:


https://gitlab.com/libssh/libssh-mirror/-/merge_requests/223
https://gitlab.com/libssh/libssh-mirror/-/merge_requests/224

I attached the commits with correct signoff to merge them into libssh, 
but I need you "sign-off" at least as a reply to this email on the 
libssh mailing list so I can merge them.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.From 3ea42d42d70ce3bbe3e3b195e2874a232de15574 Mon Sep 17 00:00:00 2001
From: Carlo Bramini 
Date: Sat, 5 Feb 2022 13:45:29 +
Subject: [PATCH 1/2] keygen2 requires also ${ARGP_LIBRARY}

Signed-off-by: Carlo Bramini 
Reviewed-by: Jakub Jelen 
---
 examples/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/CMakeLists.txt b/examples/CMakeLists.txt
index c688b6a3..466865f7 100644
--- a/examples/CMakeLists.txt
+++ b/examples/CMakeLists.txt
@@ -66,7 +66,7 @@ if (UNIX AND NOT WIN32)
 
 add_executable(keygen2 keygen2.c ${examples_SRCS})
 target_compile_options(keygen2 PRIVATE ${DEFAULT_C_COMPILE_FLAGS})
-target_link_libraries(keygen2 ssh::ssh)
+target_link_libraries(keygen2 ssh::ssh ${ARGP_LIBRARY})
 
 endif()
 endif (UNIX AND NOT WIN32)
-- 
2.34.3


From 69eb57519fd0b637b9940ba395ff68c16a1e7096 Mon Sep 17 00:00:00 2001
From: Carlo Bramini 
Date: Sat, 5 Feb 2022 13:05:40 +
Subject: [PATCH 2/2] Don't set "-fstack-clash-protection" option on Windows

Signed-off-by: Carlo Bramini 
Reviewed-by: Jakub Jelen 
---
 CompilerChecks.cmake | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/CompilerChecks.cmake b/CompilerChecks.cmake
index 5bdc05c3..9acae281 100644
--- a/CompilerChecks.cmake
+++ b/CompilerChecks.cmake
@@ -85,9 +85,11 @@ if (UNIX)
 endif()
 endif (WITH_STACK_PROTECTOR_STRONG)
 
-check_c_compiler_flag_ssp("-fstack-clash-protection" WITH_STACK_CLASH_PROTECTION)
-if (WITH_STACK_CLASH_PROTECTION)
-list(APPEND SUPPORTED_COMPILER_FLAGS "-fstack-clash-protection")
+if (NOT WINDOWS AND NOT CYGWIN)
+check_c_compiler_flag_ssp("-fstack-clash-protection" WITH_STACK_CLASH_PROTECTION)
+if (WITH_STACK_CLASH_PROTECTION)
+list(APPEND SUPPORTED_COMPILER_FLAGS "-fstack-clash-protection")
+endif()
 endif()
 
 if (PICKY_DEVELOPER)
-- 
2.34.3

Re: Deadlock on key re-exchange handling when a forward tunnel is open

[Jakub Jelen]

On 4/30/22 19:47, PFLANZER Moritz wrote:

Hello,

The attached example opens a forwarding tunnel, waits for a client to 
connect to a local socket and joins the two together using the connector 
API. This is working fine until the remote server requests a key 
re-exchange after a gigabyte of data has been transferred via the 
channel. Then the poll loop deadlocks.


The problem seems to be that the handling of the key re-exchange is 
initiated from the poll callback. Before the callback the events of the 
file descriptor are cleared to prevent race conditions on the poll. Then 
with the events still cleared the key re-exchange handler waits for the 
remote server to transmit its new keys. But since the events for the 
file descriptor are still empty poll will never signal that a new 
message can be read from the file descriptor.


Please find a small example program attached that reproduces the 
problem. A test setup could look like the following:


# Listen on port 1
$ nc -kl 1 | pv -b > /dev/null

# Run the example program
$ ./examples/tunnel

# Send data to port 5
$ dd if=/dev/zero bs=10M | pv -b | nc 127.0.0.1 5

I also attached (the tail of) an strace capture of what is happening and 
the patch I applied to libssh to get a few more prints along the way.


I started looking into how to potentially fix the problem but so far 
it's not clear to me how the interaction between the key re-exchange 
handlers and the poll callbacks was designed to work. Would be great to 
get some pointers how a fix should look like.


Hello,
thank you for the report. Can you open a new issue on gitlab to keep 
this tracked?


https://gitlab.com/libssh/libssh-mirror

This sounds like something more people can hit.

I wrote the key re-exchange support in libssh couple of years back so I 
hope I would be able to clarify if you have some particular questions. 
It was highly inspired by the code used in openssh, but I might have 
missed some corner cases.


Thanks,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: How to get started with contribution

[Jakub Jelen]

On 4/8/22 12:04, GOHIL DEEPAK KIRAN wrote:

Respected Sir/Madam,

I am Deepak Gohil, a computer science undergrad, I have just completed my first 
semester at Indian Institute of Information Technology Vadodara. I am new to 
open source but I am well aware of C,C++, socket programming in C. I would love 
to contribute to your organisation but could you please tell me how to get 
started ?
Hoping to hear from you soon.


Hi,
please read through the general GSoC page on

https://www.libssh.org/development/google-summer-of-code/

And also through the maling list archive. This question was asked 
several times during last month. But in short, contributions are done 
through gitlab and we have some issues that might be great to get you 
started:


https://gitlab.com/libssh/libssh-mirror/-/issues

We would be happy to answer you some specific questions once you will 
learn a bit more about our project.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re:

[Jakub Jelen]

On 3/13/22 15:58, Karani Vinay Kumar wrote:
Hello LIBSSH team! I'm new to open source and I have some prior 
knowledge on C programming language. I would like to participate in GSOC 
along with LIBSSH. Give me some suggestions about how do I start and 
work on it.


Hi Karani,
thank you for reaching out to us. The information about participation in 
the project through the GSoC is described in the following page:


https://www.libssh.org/development/google-summer-of-code/

There are suggestions how to start using and contributing to libssh.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Using openssh local unix domain socket

[Jakub Jelen]

On 2/3/22 03:10, Monty Wiseman wrote:

Is there a way to open a session by using / opening an existing
openssh UDS as specified by ControlPath?


At this moment, there is no support in libssh for openssh connection 
multiplexing.


If you have a good use for this, contributions are welcomed.

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: ssh_channel_open_session only works the first time called

[Jakub Jelen]

On 11/3/21 11:23, Thorsten R. wrote:

On 11/2/21 15:46, Jakub Jelen wrote:

Hi,
does your Cisco switch support more channels? You can try it for
example with openssh with connection multiplexing using
ControlMaster/ControlPath.


That's an interesting point. Did not know that multiplexing is possible.
But this is what I got:

First terminal
==
tr@LinuxMint19:~/$ ssh -o ControlMaster=yes -o 
ControlPath=~/.ssh/control-%h_%p_%r admin@192.168.4.219

Password: 
gwswitch1#

Second terminal
===
tr@LinuxMint19:~/$ ssh -o ControlPath=~/.ssh/control-%h_%p_%r 
admin@192.168.4.219
mux_client_request_session: session request failed: Session open refused 
by peer


This is the failure to open a session channel.


Password: 
gwswitch1#


OpenSSH implements fallback opening a new connection if the remote does 
not allow this.



Output on first terminal after second terminal connects:
gwswitch1#channel 3: open failed: resource shortage:
gwswitch1#

It seems that multiplexing is not possible on Cisco switches.
But now I am a little bit confused. I thought that calling

ssh_channel_close(channel);
ssh_channel_free(channel);

closes the shell and the session in a way that I can open a new one if 
needed.


Right. This closes the session channel, but connection is still open. 
With other servers, what you do might work just fine. With OpenSSH 
server, you can probably emulate this with "MaxSessions 1" in sshd_config.


What is the right way to open a SSH connection, open a terminal/shell, 
execute a few commands in it with


ssh_channel_write()
ssh_channel_read_nonblocking()

and close the shell without losing the connection?


This is not the most common use case. Generally, you want to execute 
command and exit or open a shell, execute commands, collect results and 
again exit the connection.


If you want to send more commands in some longer timespan, you will 
probably have to open a shell and handle the IO yourself as described in 
the following tutorial chapter:


https://api.libssh.org/stable/libssh_tutor_shell.html

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: ssh_channel_open_session only works the first time called

[Jakub Jelen]

On 11/2/21 14:05, libssh.org...@thorsten-reichelt.de wrote:

Hello!

I am trying to implement a simple "activate/deactive port" function for
a Cisco switch in C++.


Hi,
does your Cisco switch support more channels? You can try it for example 
with openssh with connection multiplexing using ControlMaster/ControlPath.


I do not see anything wrong on the first sight, but the exception comes 
from an error writing some packet. Can you step through that part of the 
code for example with gdb to see what is failing where. I would start 
around ssh_socket_unbuffered_write() after the first call to your function.


Also, the important question is which libssh version are you using? Is 
it up to date?


Jakub


For that I initialize a new SSH conection to the switch, which works
great, and then I am doing the following:

void activePort() {
   ssh_channel channel = ssh_channel_new(getSession());
   if (ssh_channel_open_session(channel) < 0)
   {
     // print the ssh_get_error() string
     return;
   }
   ssh_channel_request_pty(channel);
[...]
   read/write from and to channel
[...]
   ssh_channel_close(channel);
   ssh_channel_free(channel);
}

In my program I can call activatePort() excactly one times.
The second time I call activatePort() the ssh_channel_open() method
returns -1 and ssh_get_error() shows:

"Socket error: No error"

The last log message is: "channel_open: Sent a SSH_MSG_CHANNEL_OPEN type
session for channel 44"

Below is an extract of the first-run logs and from the second run.

What am I doing wrong? :(

=

FIRST RUN
=
[2021/11/02 13:49:10.891679, 2] channel_open:  Creating a channel 43
with 64000 window and 32768 max packet
[2021/11/02 13:49:10.891679, 3] ssh_packet_need_rekey:  packet:
[data_rekey_needed=0, out_blocks=5, in_blocks=2
[2021/11/02 13:49:10.892676, 3] ssh_socket_unbuffered_write:  Enabling
POLLOUT for socket
[2021/11/02 13:49:10.892676, 3] packet_send2:  packet: wrote [type=90,
len=44, padding_size=19, comp=24, payload=24]
[2021/11/02 13:49:10.893673, 3] channel_open:  Sent a
SSH_MSG_CHANNEL_OPEN type session for channel 43
[2021/11/02 13:49:11.887885, 3] ssh_packet_socket_callback:  packet:
read type 91 [len=28,padding=10,comp=17,payload=17]
[2021/11/02 13:49:11.47, 3] ssh_packet_process:  Dispatching handler
for packet type 91
[2021/11/02 13:49:11.47, 3] ssh_packet_channel_open_conf:  Received
SSH2_MSG_CHANNEL_OPEN_CONFIRMATION
[2021/11/02 13:49:11.889845, 2] ssh_packet_channel_open_conf:  Received
a CHANNEL_OPEN_CONFIRMATION for channel 43:3
[2021/11/02 13:49:11.890856, 2] ssh_packet_channel_open_conf:  Remote
window : 8192, maxpacket : 4096

SECOND RUN
==
[2021/11/02 13:49:12.669605, 2] channel_open:  Creating a channel 44
with 64000 window and 32768 max packet
[2021/11/02 13:49:12.670603, 3] ssh_packet_need_rekey:  packet:
[data_rekey_needed=0, out_blocks=13, in_blocks=17
[2021/11/02 13:49:12.671609, 3] ssh_socket_unbuffered_write:  Enabling
POLLOUT for socket
[2021/11/02 13:49:12.671609, 1] ssh_socket_exception_callback:  Socket
exception callback: 2 (0)
[2021/11/02 13:49:12.672598, 1] ssh_socket_exception_callback:  Socket
error: No error
[2021/11/02 13:49:12.673644, 3] packet_send2:  packet: wrote [type=90,
len=44, padding_size=19, comp=24, payload=24]
[2021/11/02 13:49:12.673644, 3] channel_open:  Sent a
SSH_MSG_CHANNEL_OPEN type session for channel 44
Socket error: No error

===






--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Help request for authentication with certicates

[Jakub Jelen]

On 10/27/21 16:26, Marco wrote:

Hi all and thanks for attention.

I have some difficulties in authentication using certificate from C 
application using ssh to a server correctly configured, I think.


I've generate a private and public key and signed the public with the 
certification authority private key to have -cert.pub with desired 
principals (principals are in /etc/ssh/auth_principals/%u at server side)


The server is configured to recognize the CA and has authentication 
principals


Using ssh from shell I have no issue.

With c application following tutorial and after setting session with 
username, ip, port, I try public key using cert file,it succeed, then I 
try to authenticate with private key but I have Access denied.


AFAIK the OpenSSH (ssh from shell) automatically loads the existing 
-cert.pub files when it founds them alongside of the private and public 
key files. I am not sure if this functionality is implemented in libssh, 
but from what you describe, it looks like the case.


The certificate and public key authentication are both using the pubkey 
authentication method, but they are using different "key type" (or 
mechanism -- for example ssh-ed25519 or 
ssh-ed25519-cert-...@openssh.com, which will use different content of 
the authentication packets (you should be able to see this difference in 
debug mode of both server and clients).


I think this works as expected from the protocol point of view. If you 
think libssh should also try to find matching certificates and use them 
for the authentication, contributions are welcomed:


https://gitlab.com/libssh/libssh-mirror

Hope it helps,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: parsing "Include" Keyword in ssh config

[Jakub Jelen]

On 9/19/21 11:23 PM, emak wrote:

Hi all

I use Remmina which apparently uses libssl as library to create the SSH 
Tunnels. There is an option to parse the ~/.ssh/config file which works 
fine.


If - for the sake of simplicity - I have my config files for different 
subjects independently, but added to the main config with the "Include" 
Keyword, they are not parsed.


How could that be fixed? The dev of Remmina told me to ask you guys. See 
also: https://gitlab.com/Remmina/Remmina/-/issues/2604


What libssh version is remina using in your system. In the issue I read 
you use snap, but I am not sure where are the versions pulled from. 
snapcraft.conf lists just libssh-dev.


The include keyword is supported in libssh-0.9 as well as in libssh-0.8 
so I assume you will use some corner case that works in openssh but not 
in libssh.


First of all, can you provide a minimal configuration reproducer that 
works for you with openssh, but not with libssh? Debug log from libssh 
would be also helpful as libssh writes some information about parsing 
configuration files, but I am not sure about the way how to turn the 
logging through remina. Alternatively, you can try building some 
examples programs from libssh repository to see how your configuration 
is parsed.


Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

[Fedora-legal-list] Re: Brainpool Curves in Fedora (openssl, libgcrypt, gnupg)

[Jakub Jelen]

On 3/18/21 4:10 PM, Ben Cotton wrote:

On Thu, Mar 18, 2021 at 10:06 AM Jakub Jelen  wrote:


We need to strip these curves from upstream tarballs and it would be
great to have this resolved (in either way) rather sooner than later.


The Brainpool curves are not approved for use in Fedora at this time.


Hi,
I wanted to bring up this topic once more again as it was suggested that 
if the curves are build-time disabled we should be able to go around 
without hobbling the source tarball. I proposed the following change to 
libgcrypt to support build-time disabling brainpool curves and I wanted 
to double-check if this approach is legally acceptable:


https://dev.gnupg.org/T5520#149566

Thanks,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

libssh 0.9.6 was released

[Jakub Jelen]

Hello,

the libssh team released libssh 0.9.6, fixing previously announced 
security issue CVE-2021-3634:


https://www.libssh.org/2021/08/26/libssh-0-9-6-security-release/

Thanks to all the people who contribute to libssh!

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: More GSSAPI on Windows: user auth hangs?

[Jakub Jelen]

On 8/23/21 6:10 PM, Kerrison, Adam wrote:
I’ve spent a while trying to test the GSSAPI support on Windows and I 
can’t make it work ☹I’ve attached a simple program which just tries to 
connect and authenticate with a server. It assumes you have a valid 
Kerberos configuration and a ticket.


If I run this on Linux is just works. On Windows, it hangs in 
ssh_userauth_gssapi(). The program enables packet level logging and on 
Windows I see this before it hangs:


[2021/08/23 17:01:39.112369, 4] ssh_socket_pollcallback:  Poll callback 
on socket 756 (POLLIN ), out buffer 0


[2021/08/23 17:01:39.112369, 3] ssh_packet_socket_callback:  packet: 
read type 61 [len=176,padding=15,comp=160,payload=160]


[2021/08/23 17:01:39.113484, 3] ssh_packet_process:  Dispatching handler 
for packet type 61


Packet type 61 -> SSH2_MSG_USERAUTH_GSSAPI_TOKEN

On Linux, I see the same message sequence but immediately followed by:

[2021/08/23 17:05:07.856296, 3] 
ssh_packet_userauth_gssapi_token_client:  Received 
SSH_MSG_USERAUTH_GSSAPI_TOKEN


I think this must be something about how I’ve built libssh but its odd 
as the first part of the GSSAPI auth definitely works (I see the GSSAPI: 
sending token message for example). I’d also expect things to crash if 
the function was missing (i.e. a NULL pointer)


I’m not holding out a lot of hope that anyone will have a clue about 
what is going on here but I thought I’d ask anyway …


Hi,
my guess is that on Linux you built libssh with server and on Windows 
without.


The packet number SSH2_MSG_USERAUTH_GSSAPI_TOKEN is shared with 
SSH2_MSG_USERAUTH_INFO_RESPONSE, which is implemented only if built with 
server, which is indeed wrong and should be fixed. See the following 
part of the code:


https://gitlab.com/libssh/libssh-mirror/-/blob/master/src/messages.c#L1018

This would explain the hang, as the packet is correctly accepted, but no 
response is sent to peer.


Feel free to test my theory and propose a fix.

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Heads-up: Security releases ahead!

[Jakub Jelen]

Hi,
this is a heads-up that there will be libssh security updates on
Thrursday, August 26th. Please make sure that your libssh
installations will be updated soon after the release!
Impacted components:

server and client (CVSS 5.3, Medium)

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: [PATCH] channels: Fix segfaults when the channel data is freed

[Jakub Jelen]

On 8/15/21 10:01 PM, Artyom V. Poptsov wrote:

Hello,

I've found that some channel procedures in libssh 0.9.3 on Ubuntu 
GNU/Linux 20.04 (and the latest versions from Git) fails with SEGFAULT 
when a parent session of a channel is freed.


I investigated the errors and found that some "channels.h" procedures 
(namely 'ssh_channel_is_open' and 'ssh_channel_is_closed') try to 
determine whether the parent session is alive by checking 
'channel->session->alive' variable.  But when a channel is freed by 
'ssh_channel_do_free' procedure, its 'session' field is set to NULL.  In 
that situation calling e.g. 'ssh_channel_is_open' on a channel will lead 
to a SEGFAULT.


The patch to fix that behavior is attached to the email.

I ran "make test" on the libssh sources with my changes and all tests 
have passed successfully.


Thank you for the patch!

It looks fine to me technically, but can you adjust the formatting to 
match the coding style? Mostly minor details as spaces after "if" and 
aligning opening braces of multiline conditions (with moving the && to 
the end of previous lines) and replacing "! channel->session" with 
explicit check for NULL.


Do you have a simple way how to reproduce the behavior you encountered 
inside of the testsuite to make sure we will not reintroduce the issue 
in the future?


You can also submit a merge request in gitlab, which will run all testes 
on different configurations:


https://gitlab.com/libssh/libssh-mirror/

Thanks,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re: [PATCH] channels: Fix segfaults when the channel data is freed

[Jakub Jelen]

On 8/15/21 10:01 PM, Artyom V. Poptsov wrote:

Hello,

I've found that some channel procedures in libssh 0.9.3 on Ubuntu 
GNU/Linux 20.04 (and the latest versions from Git) fails with SEGFAULT 
when a parent session of a channel is freed.


I investigated the errors and found that some "channels.h" procedures 
(namely 'ssh_channel_is_open' and 'ssh_channel_is_closed') try to 
determine whether the parent session is alive by checking 
'channel->session->alive' variable.  But when a channel is freed by 
'ssh_channel_do_free' procedure, its 'session' field is set to NULL.  In 
that situation calling e.g. 'ssh_channel_is_open' on a channel will lead 
to a SEGFAULT.


The patch to fix that behavior is attached to the email.

I ran "make test" on the libssh sources with my changes and all tests 
have passed successfully.


Thank you for the patch!

It looks fine to me technically, but can you adjust the formatting to 
match the coding style? Mostly minor details as spaces after "if" and 
aligning opening braces of multiline conditions (with moving the && to 
the end of previous lines) and replacing "! channel->session" with 
explicit check for NULL.


Do you have a simple way how to reproduce the behavior you encountered 
inside of the testsuite to make sure we will not reintroduce the issue 
in the future?


You can also submit a merge request in gitlab, which will run all testes 
on different configurations:


https://gitlab.com/libssh/libssh-mirror/

Thanks,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

[Spice-devel] libcacard 2.8.1 release

[Jakub Jelen]

Hi all,

I just released a minor update to libcacard. Tarballs are available in 
the gitlab:


https://gitlab.freedesktop.org/spice/libcacard/-/releases/v2.8.1

It is signed with my new key:

0477 44C8 76CB 4EDD 6655 D1DF 91DB 0399 A3DD E969

https://keys.openpgp.org/search?q=jje...@redhat.com

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.

Re:

[Jakub Jelen]

Hi,
yourhe above code has couple of issues including the missing hostkey
verification and authentication. Both of these need to be completed before
opening a sftp session as discussed in the first part of the tutorial

https://api.libssh.org/master/libssh_tutor_guided_tour.html

I assume this boils down to this hard-to-parse error. I assume it would be
more useful if we would have better error message in this case. I assume
the failing function here is ssh_channel_new(). In any case, adding more
verbosity might point you to the right place.

Regards,
Jakub

On Wed, Jun 30, 2021 at 6:37 AM Achmad Fathoni  wrote:

> I am trying to make a simple connection to SFTP server using libssh0.9.5
> with this program.
>
> //https://api.libssh.org/master/libssh_tutor_sftp.html#sftp_read
> #include 
> #include 
> #include 
>
> using namespace std;
>
> int main(){
> ssh_session sshs = ssh_new();
> if(sshs == NULL){
> cerr << "Error allocating SSH session: " << ssh_get_error(sshs) <<
> endl;
> return SSH_ERROR;
> }
> //using hostname doesn't work either.
> ssh_options_set(sshs, SSH_OPTIONS_HOST, "192.168.2.15");
> ssh_options_set(sshs, SSH_OPTIONS_USER, "reach");
>
> //This is fine
> int rc = ssh_connect(sshs);
> if(rc != SSH_OK){
> cerr << "Error connecting to localhost: " << ssh_get_error(sshs)
> << endl;
> return SSH_ERROR;
> }
>
> //Error is here
> sftp_session sftps = sftp_new(sshs);
> if(sftps == NULL){
> cerr << "Error allocating SFTP session: " << ssh_get_error(sshs)
> << endl;
> return SSH_ERROR;
> }
>
> sftp_free(sftps);
> ssh_disconnect(sshs);
> ssh_free(sshs);
> return 0;
> }
>
> Above program prints `Error allocating SFTP session: sftp_new: Out of
> memory` . I can connect to SFTP in reach@192.168.2.15 using other
> software. Can somebody help me?
>
>

Re: RedShift

[Jakub Jelen]

On 6/25/21 5:19 AM, ToddAndMargo via users wrote:

Hi All,

Fedora 34
Xfce 4.14
redshift-1.12-11.fc34.x86_64
redshift-gtk-1.12-11.fc34.x86_64

Hi All,

Red Shift is all screwed up again:


Unable to connect to GeoClue. Unable to get location from provider:

https://github.com/jonls/redshift/issues/318#issuecomment-865667340

is back in full force.


Is there an alternatives to Red Shift?


Gnome integrated this in its own settings as a "Night Light" couple of 
years back and I am using that to satisfaction. But I assume it will not 
solve your issues on xfce ...


https://www.addictivetips.com/ubuntu-linux-tips/gnome-night-light-mode/

Regards,
--
Jakub Jelen
Crypto Team, Security Engineering
Red Hat, Inc.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Cross compilation with openssl > 1.0.2

[Jakub Jelen]

On 5/19/21 1:39 PM, Andrey Strunin wrote:

Hi,

Actually I just built the whole library (before even reading your 
message).
I did it with nasty hack of disabling the whole libcrypto-compat.c 
with `#if 0`.


I think there is some problem with detection OPENSSL version when 
cross compiling (in my logs I saw that it detected 1.0.2k. It looks 
like it found a host library...)


UPD:
Just added this line to my toolchain cmake file and removed `#if 0` 
hack from libcrypto-compat.c:

SET(OPENSSL_VERSION 3.0.0)

Everything builds great.

Thanks,
Andrey

ср, 19 мая 2021 г. в 13:25, Anderson Sasaki <mailto:ansas...@redhat.com>>:




On Wed, May 19, 2021 at 11:26 AM Andrey Strunin
mailto:acrapmons...@gmail.com>> wrote:

Thank you for the response,

I am using my own cmake toolchain file that sets compiler and
sysroot. It worked great when it was openssl 1.0.2 in sysroot.

Here is the content of my toolchain.cmake file:

#CMAKE Toolchain file for PowerPC
# this one is important
SET(CMAKE_SYSTEM_NAME Linux)
#this one not so much
SET(CMAKE_SYSTEM_VERSION 1)

# specify the cross compiler
SET(CMAKE_C_COMPILER

/localhome/new_sdk/gnss_tcc-glibc_cgl/x86-linux2/ppc_e500v2-target-linux-gnu-gcc)
SET(CMAKE_CXX_COMPILER

/localhome/new_sdk/gnss_tcc-glibc_cgl/x86-linux2/ppc_e500v2-target-linux-gnu-g++)

# where is the target environment
SET(CMAKE_FIND_ROOT_PATH
 /localhome/new_sdk/gnss_tcc-glibc_cgl/sysroot)

# Local plaform dependent toolchain outputs
SET(CMAKE_LOCAL_BASE_ROOT_PATH
 /localhome/new_sdk/gnss_tcc-glibc_cgl/sysroot)

# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Here is the output with openssl related errors:
https://pastebin.com/raw/NrMXi5M8
<https://pastebin.com/raw/NrMXi5M8>

I should have clarified the version of libssh I am using. It's
the latest 0.9.5. However, I have the same build issue (maybe
with slightly different errors, but still related to openssl)
with older versions (such as 0.8.9).

Thanks,
Andrey


Hello,

After checking the log you linked, I suspect cmake failed to
detect the OpenSSL version and included libcrypto-compat.c into
the sources. In my machine (Fedora 33), I see this line when
running cmake to generate the configuration:

-- Found OpenSSL: /usr/lib64/libcrypto.so (found suitable version
"1.1.1k", minimum required is "1.0.1")

Please check if cmake found the dynamic library you expected.
Maybe you will have to tweak the places where cmake searches for
libraries in your custom environment.

In my machine, the "OPENSSL_FOUND" and "OPENSSL_VERSION" are set
by the cmake module "FindOpenSSL.cmake" which is located at
/usr/share/cmake/Modules.

Regards,
Anderson

It would be useful to debug the issue further to provide a proper 
solutions also for cross-compiling. We just use normal find_package():


https://gitlab.com/libssh/libssh-mirror/-/blob/master/CMakeLists.txt#L61

It would be worth checking what it does for openssl and if there is 
something to adjust for cross-compiling. In Fedora, I have 
/usr/share/cmake/Modules/FindOpenSSL.cmake, which handles this. First, 
make sure it is up-to-date. From my fast read-through, I would consider 
using OPENSSL_ROOT_DIR pointing to the place where your openssl is 
installed.


Regards,

--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Cross compilation with openssl > 1.0.2

[Jakub Jelen]

On 5/18/21 10:15 AM, Andrey Strunin wrote:

Hi,

Do you have any plans to fix the issue with libssh cross compilation 
with newer openssl?
https://github.com/CESNET/netopeer2/issues/856#issuecomment-791481305 
<https://github.com/CESNET/netopeer2/issues/856#issuecomment-791481305>


I need libssh library for libnetconf2 and netopeer and system we use 
should not have old openssl.


The libssh works just fine with new openssl when compiled directly, so 
this sounds like some issue with the cross-compilation process or 
handling of the cross-compilation in either libssh, openssl or netopeer2.


I unfortunately do not much experience with cross-compilation, but I 
guess you will need to provide more commands you used for the 
cross-compilation of particular pieces and errors you got.


Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: [PATCH] packet: Change the last argument of ssh_packet_encrypt to uint32_t

[Jakub Jelen]

On 5/11/21 6:30 AM, Xiang Xiao wrote:

Andreas,
My signoff email was just sent to 'contribut...@libssh.org 
<mailto:contribut...@libssh.org>'. Please check it.


Thank you,
it looks fine.

I just pushed couple of changes from the gitlab merge requests, but I 
had to revert the ones that had wrong signoff/author combination. Can 
you resend them again? Either here or on gitlab according to your 
preference. These are just the three commits here on the mailing list.


Thanks,
Jakub

On Mon, May 10, 2021 at 8:58 PM Andreas Schneider <mailto:a...@cryptomilk.org>> wrote:


On Sunday, 9 May 2021 16:47:58 CEST Xiang Xiao wrote:
 > to match the implemntation in packet_crypt.c
 >
 > Signed-off-by: Xiang Xiao mailto:xiaoxi...@xiaomi.com>>

Hi Xian Xiao,

thank you very much for your contributions. Your author email
differes from
the email signing off the commit. So it is not clear if you're
contributing as
an individual contributor or on behave of a company.

If you're submitting on behave of your company, we need a
Certificate of
Origin.

https://git.libssh.org/projects/libssh.git/tree/CONTRIBUTING.md
<https://git.libssh.org/projects/libssh.git/tree/CONTRIBUTING.md>

Now the problem is that the commits went in before we had a
Certificate of
Origin from you.

This means we need to revert the patches which already went upstream
till this
is clarified. You need to send patches where the author sign-off
matches.

I hope you understand that.

Sorry for not replying earlier but I attended a conference last week
and
didn't check mails.


Thanks


         Andreas


 > Change-Id: Ib76c3585f67dae22ed0f1dfc10dadcd03c762032
 > ---
 >  include/libssh/packet.h | 2 +-
 >  1 file changed, 1 insertion(+), 1 deletion(-)
 >
 > diff --git a/include/libssh/packet.h b/include/libssh/packet.h
 > index 8fc7ce42..561bba8e 100644
 > --- a/include/libssh/packet.h
 > +++ b/include/libssh/packet.h
 > @@ -80,7 +80,7 @@ int ssh_packet_decrypt(ssh_session session, uint8_t
 > *destination, uint8_t *sourc size_t start, size_t encrypted_size);
 >  unsigned char *ssh_packet_encrypt(ssh_session session,
 >                                    void *packet,
 > -                                  unsigned int len);
 > +                                  uint32_t len);
 >  int ssh_packet_hmac_verify(ssh_session session, const void
*data, size_t
 > len, unsigned char *mac, enum ssh_hmac_e type); int
 > ssh_packet_set_newkeys(ssh_session session,


-- 
Andreas Schneider a...@cryptomilk.org <mailto:a...@cryptomilk.org>

GPG-ID:     8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D





--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: [PATCH] packet: Change the last argument of ssh_packet_encrypt to uint32_t

[Jakub Jelen]

On 5/9/21 4:47 PM, Xiang Xiao wrote:

to match the implemntation in packet_crypt.c

Signed-off-by: Xiang Xiao 
Change-Id: Ib76c3585f67dae22ed0f1dfc10dadcd03c762032
---
  include/libssh/packet.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/libssh/packet.h b/include/libssh/packet.h
index 8fc7ce42..561bba8e 100644
--- a/include/libssh/packet.h
+++ b/include/libssh/packet.h
@@ -80,7 +80,7 @@ int ssh_packet_decrypt(ssh_session session, uint8_t 
*destination, uint8_t *sourc
  size_t start, size_t encrypted_size);
  unsigned char *ssh_packet_encrypt(ssh_session session,
void *packet,
-  unsigned int len);
+  uint32_t len);
  int ssh_packet_hmac_verify(ssh_session session, const void *data, size_t len,
 unsigned char *mac, enum ssh_hmac_e type);
  int ssh_packet_set_newkeys(ssh_session session,



Thank you for the patches. They look fine.

I submitted them as a MR in gitlab with a fix for CI to trigger a CI on 
them:


https://gitlab.com/libssh/libssh-mirror/-/merge_requests/172

Thanks,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: [PATCH] [#48/T22] Added missing server reply on auth-agent-req

[Jakub Jelen]

Hi,
thank you for the patch. Can you submit it as a merge request in gitlab?

https://gitlab.com/libssh/libssh-mirror/-/merge_requests

On 5/7/21 12:29 AM, Jeremy Cross wrote:

[#48/T22] Added missing server reply on auth-agent-req when a
  reply was requested by the client. PuTTY for Windows chokes without this
  reply if "Allow agent forwarding" is enabled. Reply will be successful if
  channel_auth_agent_req_function callback is defined. Based on an unmerged
  patch by Jon Simons.

Signed-off-by: Jeremy Cross 
--
diff --git a/src/channels.c b/src/channels.c
index 4eea885b..663dbcaf 100644
--- a/src/channels.c
+++ b/src/channels.c
@@ -692,7 +692,7 @@ SSH_PACKET_CALLBACK(channel_rcv_close) {
  SSH_PACKET_CALLBACK(channel_rcv_request) {
ssh_channel channel;
char *request=NULL;
-uint8_t status;
+uint8_t want_reply;
  int rc;
(void)user;
(void)type;
@@ -705,7 +705,7 @@ SSH_PACKET_CALLBACK(channel_rcv_request) {
  
  	rc = ssh_buffer_unpack(packet, "sb",

,
-   );
+   _reply);
if (rc != SSH_OK) {
SSH_LOG(SSH_LOG_PACKET, "Invalid MSG_CHANNEL_REQUEST");
return SSH_PACKET_USED;
@@ -815,11 +815,29 @@ SSH_PACKET_CALLBACK(channel_rcv_request) {
if (strcmp(request, "auth-agent-...@openssh.com") == 0) {
  SAFE_FREE(request);
  SSH_LOG(SSH_LOG_PROTOCOL, "Received an auth-agent-req request");
-ssh_callbacks_execute_list(channel->callbacks,
-   ssh_channel_callbacks,
-   channel_auth_agent_req_function,
-   channel->session,
-   channel);
+
+int status = SSH2_MSG_CHANNEL_FAILURE;


Please, keep the variables declaration in the beginning of blocks. I 
think it is not explicitly stated anywhere, but some older C standards 
and compiler implementation have issues with this.



+ssh_callbacks_iterate(channel->callbacks, ssh_channel_callbacks,
+channel_auth_agent_req_function){
+ssh_callbacks_iterate_exec(channel_auth_agent_req_function,
+   channel->session,
+   channel);
+/* in lieu of a return value, if the callback exists it's supported */
+status = SSH2_MSG_CHANNEL_SUCCESS;
+break;
+}
+ssh_callbacks_iterate_end();
+
+if (want_reply) {
+rc = ssh_buffer_pack(session->out_buffer,
+ "bd",
+ status,
+ channel->remote_channel);
+if (rc != SSH_OK) {
+return SSH_PACKET_USED;
+}
+ssh_packet_send(session);
+}
  
  return SSH_PACKET_USED;

}
@@ -828,7 +846,7 @@ SSH_PACKET_CALLBACK(channel_rcv_request) {
 * client requests. That means we need to create a ssh message to be 
passed
 * to the user code handling ssh messages
 */
-   
ssh_message_handle_channel_request(session,channel,packet,request,status);
+   
ssh_message_handle_channel_request(session,channel,packet,request,want_reply);
  #else
  SSH_LOG(SSH_LOG_WARNING, "Unhandled channel request %s", request);
  #endif


Otherwise it looks fine.

Thanks,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Authenticate with pki

[Jakub Jelen]

On 5/5/21 7:53 PM, John Dunn wrote:

  > Hi John... I've hit this before myself.


You need to call ssh_pki_copy_cert_to_privkey(pubKey, privateKey) after 
ssh_pki_import_privkey_base64() and before ssh_userauth_publickey() to
add the public key certificate to the private key before authenticating.



Hope that helps!
Jeremy.


That did! Thanks!

It's odd that requirement isn't documented as far as I can tell. It's also not 
used in the authentication example here ( 
https://gitlab.com/libssh/libssh-mirror/-/blob/master/examples/authentication.c 
) either. I wonder if that's only required in some cases, and if that's the 
case how one would know that it needed to be done.


Interesting. In the original message, there was no mention of the 
certificates, just public and private keys, which should work as described.


If the certificate is needed for authentication, it indeed, requires 
loading it beforehand and separately. I do not think we have a lot of 
documentation about these, but contributing examples for this or updates 
for documentation, would be welcomed.


Thanks,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Authenticate with pki

[Jakub Jelen]

On 5/4/21 11:10 PM, John Dunn wrote:

I am having difficulties authenticating using pki. I have a private/public key 
pair that allows me to authenticate with a server via

ssh -i  @

The private key is password protected so I am prompted for the password but 
beyond that I am able to connect without any user interaction. I'm trying to 
replicate the same functionality using libssh using the following code

void connect_via_ssh(
   const char* host,
   int port,
   const char* user,
   const char* path_to_pub,
   const char* path_to_priv,
   const char* priv_pass
)
{
   ssh_session ssh = ssh_new();
   int verbosity = SSH_LOG_FUNCTIONS;
   long timeout = 30;
   ssh_options_set(ssh, SSH_OPTIONS_HOST, host);
   ssh_options_set(ssh, SSH_OPTIONS_LOG_VERBOSITY, );
   ssh_options_set(ssh, SSH_OPTIONS_PORT, );
   ssh_options_set(ssh, SSH_OPTIONS_USER, user);
   ssh_options_set(ssh, SSH_OPTIONS_TIMEOUT, );

   int rc = ssh_connect(ssh);
   ssh_key key = NULL;

   rc = ssh_pki_import_pubkey_file(path_to_pub, );
   if (rc != SSH_OK)
   {
 printf("Error ssh_pki_import_pubkey_file\r\n");
 return;
   }

   rc = ssh_userauth_try_publickey(ssh, NULL, key);
   ssh_key_free(key);
   if (rc != SSH_AUTH_SUCCESS)
   {
 printf("ssh_userauth_try_publickey : %s\r\n", ssh_get_error(ssh));
 exit(0);
   }

   rc = ssh_pki_import_privkey_file(path_to_priv, priv_pass, NULL, NULL, );
   if (rc != SSH_OK)
   {
 printf("Error ssh_pki_import_privkey_file\r\n");
 return;
   }

   rc = ssh_userauth_publickey(ssh, NULL, key);
   if (rc != SSH_AUTH_SUCCESS)
   {
 printf("ssh_userauth_publickey : %s\r\n", ssh_get_error(ssh));
 return;
   }
   // create channel, etc...
}

Everything works fine until the call to ssh_userauth_publickey - that returns 
SSH_AUTH_DENIED. I've verified the exact same keypair can be used with ssh so 
I'm guessing I'm missing a step in my code. Here are the last lines of debug 
output. Any suggestions would be appreciated.

John

[2021/05/04 14:05:27.896286, 2] ssh_pki_import_privkey_base64:  Trying to 
decode privkey passphrase=true
[2021/05/04 14:05:27.896286, 2] ssh_pki_openssh_import:  Opening OpenSSH 
private key: ciphername: aes256-cbc, kdf: bcrypt, nkeys: 1
[2021/05/04 14:05:27.897285, 3] pki_private_key_decrypt:  Decryption: 32 key, 
16 IV, 16 rounds, 16 bytes salt
[2021/05/04 14:05:27.997018, 3] ssh_key_algorithm_allowed:  Checking ssh-ed25519 with 
list 

[2021/05/04 14:05:27.997455, 3] ssh_socket_unbuffered_write:  Enabling POLLOUT 
for socket
[2021/05/04 14:05:27.997455, 3] packet_send2:  packet: wrote [type=50, len=208, 
padding_size=9, comp=198, payload=198]
[2021/05/04 14:05:27.997455, 4] ssh_socket_pollcallback:  Poll callback on 
socket 744 (POLLOUT ), out buffer 0
[2021/05/04 14:05:27.998455, 4] ssh_socket_pollcallback:  sending control flow 
event
[2021/05/04 14:05:27.998455, 4] ssh_packet_socket_controlflow_callback:  
sending channel_write_wontblock callback
[2021/05/04 14:05:28.008735, 4] ssh_socket_pollcallback:  Poll callback on 
socket 744 (POLLIN ), out buffer 0
[2021/05/04 14:05:28.009231, 3] ssh_packet_socket_callback:  packet: read type 
51 [len=48,padding=11,comp=36,payload=36]
[2021/05/04 14:05:28.009231, 3] ssh_packet_process:  Dispatching handler for 
packet type 51
[2021/05/04 14:05:28.009231, 1] ssh_packet_userauth_failure:  Access denied for 
'publickey'. Authentication that can continue: publickey,keyboard-interactive
[2021/05/04 14:05:28.009231, 2] ssh_packet_userauth_failure:  Access denied for 
'publickey'. Authentication that can continue: publickey,keyboard-interactive
ssh_userauth_publickey : Access denied for 'publickey'. Authentication that can 
continue: publickey,keyboard-interactive


This is ssh-ed25519, which should work just fine quite much everywhere. 
I would check the server debug log for the reason why the key was rejected.


Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: How to Build LIBSSH on Previous version like 0.9.3 or 0.9.4,

[Jakub Jelen]

On 4/9/21 10:34 AM, V Sidnal, Nagraju wrote:

Hi All,

Recently portfile.cmake  has changed, due to which I m not able to 
figure out how to revert to old version of LIBSSH for BUILDING.


Earlier there was VERSION variable in this file. Now it is not there. 
Please suggest.


You can not revert to old version with changing of constant. you need to 
download older tarball or checkout different git revision (or tag) to 
get to older version of libssh.


Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Need Help Regarding::SSH blocking and Non-Blocking Mode

[Jakub Jelen]

On 4/5/21 12:28 PM, V Sidnal, Nagraju wrote:

Hi All,

When I’m creating a session, by default it create blocking session.

If I use same blocking session to call *SSH_CONNECT(SESSION),* with 
timeout of 30 Seconds, For Invalid IP address it gets return after 30 
seconds.


When I set this to nonblocking by using *ssh_set_blocking(SESSION,0)**, 
If now, I do SSH_CONNECT(SESSION),* it returns immediately with*SSH_AGAIN.*


It means in nonblocking mode I need to try *SSH_CONNECT(SESSION) 
*repeatedly, until my expected timeout value  or return SSH_OK, example 
in my case for 30 seconds.


Apart from above observation, What is the impact of  blocking and 
non-blocking mode?


Which one is recommended. Which one to use in which scenarios.


It only shifts the responsibilities between your application and the 
library. If you do not want to bother with timeouts, using blocking mode 
is better for your application. If you have work to be done in the 
meantime or you use some custom polling, non-blocking operations (not 
just connect) are more suitable for your application.


Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

[Fedora-legal-list] Re: Brainpool Curves in Fedora (openssl, libgcrypt, gnupg)

[Jakub Jelen]

On 11/10/20 2:18 PM, Ben Cotton wrote:

On Tue, Nov 10, 2020 at 4:52 AM Timothée Ravier  wrote:


The ECC Brainpool Curves [1][2] are currently not available in Fedora as 
according to this BZ [3], this needs Fedora Legal approval.
Could someone from the legal team take a look to see if there are any blockers 
regarding Brainpool Curves inclusion in Fedora?


Thanks for bringing this up. I'll check on it.



Hi Ben,
did you get back to look into this during last months (busy ones were they)?

We need to strip these curves from upstream tarballs and it would be 
great to have this resolved (in either way) rather sooner than later.


My main concern is the libgcrypt but guys handling other packages would 
like to hear an authoritative answer too:


https://bugzilla.redhat.com/show_bug.cgi?id=1413618

Thanks,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: JuiceSSH

[Jakub Jelen]

On 3/15/21 10:19 PM, Naftali Oziel wrote:


Hi, i use a product for android called JuiceSSH and reached out to them 
directly if support can be added for obfuscated ssh so that it can I can 
have this integrated with Bitvise that obfuscated ssh was enabled and 
requires a keyword.


The JuiceSSH team stated that I should reach out to  your org directly 
for consideration and if its added as support they will add it to their 
app.  any direction or feedback is appreciated.


Can you clarify what are you trying to achieve?

Jakub

Re: OpenSSH SHA-1 deprecation, developing FAQ, etc

[Jakub Jelen]

On 3/10/21 6:58 PM, Daniel Pocock wrote:


Hi all,

I put some comments on the OpenSSH mailing list[1] about UpdateHostKeys
and other SHA-1 related changes.

The OpenSSH release notes simply tell people to update OpenSSH.  In
practice, people who use distributions like Fedora, RHEL and CentOS are
going to wait for a package.  Security conscious users who can't
completely disable ssh may use the MACs parameter in ssh_config,
sshd_config or both.

What does it mean from a Fedora perspective?  For example:

- did anybody already write any wiki page, FAQ or guide for Fedora users
to navigate the SHA-1 issue in SSH?

- will Fedora be more proactive than upstream in disabling SHA-1 or will
Fedora simply follow the timeline from upstream?

Regards,

Daniel


1.
https://lists.mindrot.org/pipermail/openssh-unix-dev/2021-March/039194.html


Hi,
Fedora disabled RSA with SHA1 in Fedora 33. Previously, we did the same 
thing in FIPS mode.


https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2

I see that most of the myths and wrong assumptions were already busted 
and your questions answered. Please, let me know if something is still 
unclear.


We do not have separate wiki page about SSH, but you are welcomed to 
create one if you would find to have the information summarized. The 
hard stuff is keeping it up to date.


Maybe even better place for this would be a system administrator guide, 
which has already a section about OpenSSH, which I was recently updating 
to current version:


https://pagure.io/fedora-docs/system-administrators-guide

Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: custom banner

[Jakub Jelen]

On 2/17/21 5:13 PM, tangying212 wrote:

Hello Andreas,
Uhm,
   Can you please share the solution/guide/instructions/setup to customize the 
banner before using the ssh_connect() function.I found the custombanner in the 
struct ssh_session->opt, but I don't know how to use it.please help me,thanks.


Hi,
it looks like libssh does not allow changing this in the client 
applications through API. That part of string is usually used by 
applications which can use it to detect various bugs or specification 
deviations (at least in case of OpenSSH, there is whole bunch of compat 
code). So unless you have really good reason to change it, I would try 
to avoid it.


The custombanner is used only in the server side of libssh and requires 
using private header file session.h to access the internal session 
variable session->opts.custombanner.


If there is a good reason to use different banner, I would suggest to 
update the function ssh_send_banner() in client.c to use the 
custombanner and update options.c to allow setting this through 
ssh_options_set(session, SSH_OPTIONS_CUSTOM_BANNER, "the banner").


Best regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: How can I open one channel and than execute several different commands in libssh?

[Jakub Jelen]

On 2/7/21 2:17 AM, Bruno Buzzi Brassesco wrote:

Hi,
I do not have my notebook now.
But you have to open a channel per each command.


Right,
or you will need to send separate commands in separate channel, because 
after ssh_channel_request_exec() shorthand, the underlying channel is 
closed.


The other possibility is to handle the IO for yourself and run the 
separate commands in a single shell as described in the following 
chapter of a tutorial:


https://api.libssh.org/stable/libssh_tutor_shell.html#opening_shell

Regards,
Jakub


Regards,
Bruno

El sáb., 6 de febrero de 2021 22:14, 孙世龙 sunshilong 
mailto:sunshilong...@gmail.com>> escribió:


Hi,list

For example i want to open one session and one channel and then
execute severeal different commands. I have InitializeSSHSession and
Initialize SSH channel methods can be seen below.

void Computer::InitializeSSHSession()
  {
  ssh_session remoteSSHSession = ssh_new();

if ( remoteSSHSession )
{
     QString password = this->GetPassword();
     QString remoteIP = this->GetIP();
     QString userName = this->GetUserNameW();

     ssh_options_set(remoteSSHSession, SSH_OPTIONS_HOST,
remoteIP.toStdString().c_str());
     ssh_options_set(remoteSSHSession, SSH_OPTIONS_LOG_VERBOSITY,
);
     ssh_options_set(remoteSSHSession, SSH_OPTIONS_PORT, );
     ssh_options_set(remoteSSHSession, SSH_OPTIONS_USER,
userName.toStdString().c_str());

     int remoteConnection = ssh_connect(remoteSSHSession);
     if ( remoteConnection == SSH_OK )
     {
         int authenticateControl =
ssh_userauth_password(remoteSSHSession, NULL,
password.toStdString().c_str());
         if ( authenticateControl == SSH_AUTH_SUCCESS )
         {
             InitializeSSHChannel(remoteSSHSession);
         }
         else
         {
             remoteSSHSession = NULL;
         }
     }
     else
     {
         remoteSSHSession = NULL;
     }
}
else
{
      remoteSSHChannel = NULL;
}
}

void Computer::InitializeSSHChannel(ssh_session remoteSSHSession)
{
remoteSSHChannel = ssh_channel_new(remoteSSHSession);

if ( remoteSSHChannel )
{
     int channelControl = ssh_channel_open_session(remoteSSHChannel);
     if ( channelControl != SSH_OK )
     {
         EventLogger::LogMessage(true, "SSH channel sesssion failed!");
         ssh_channel_free(remoteSSHChannel);
     }
}
  }

And in the main, I am initializing session and getting channel like
this:

  InitializeSSHSession();
  ssh_channel channel = GetSSHChannel();

And then

   int rc = ssh_channel_request_exec(channel, "ls -l");

It is okay it is executed correctly but when i want to execute another
command it is not execute, I should return the beginning of process
first initialize session and getting channel again.

It is not good solution for every command. Is it possible to do that
once initialize session than use it again and again for every command
?




--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: libssh and libgcrypt recent vulnerability

[Jakub Jelen]

On 1/30/21 8:36 PM, Andreas Schneider wrote:

On Friday, 29 January 2021 22:42:27 CET Aris Adamantiadis wrote:

Hi everyone.


Hi Aris,
  

Libgcrypt has been an itch that scratched both Andreas and me for a
while. Till now, the biggest problem was the workload associated in
maintaining the gcrypt backend (mostly with external contributions, but
still). This backend was generously contributed by people who wanted
libssh in debian at a time when OpenSSL had licensing issues, and I
accepted it at a time when I wasn't aware of the implications.

Today it seems to me that that in addition to this workload problem, the
libgcrypt maintainers aren't on the same page as libssh in terms of CI
and code quality in general, especially for a security software. This
twitter thread in particular highlights this:
https://twitter.com/FiloSottile/status/1355192385123340296


I also saw this thread already.
  

I propose we evaluate how many users depend on our libgcrypt build and
get rid of it for the next version, if it's possible.


I agree.


Licensing issues
with OpenSSL is in my opinion not a sufficient reason anymore to keep
libgcrypt support.


We have a mbedtls backend and mbedtls is available under GPL 2.0 or Apache 2.0
License. If someone really wants a diffent backend I would suggest to add a
libnettle based backend.


By stripping libgcrypt out, we can also more easily
introduce new ciphers and focus on getting them right on two backends
instead of three. This has been one of the reasons I haven't worked on
libssh recently. Adding diffie-helman-group-exchange with support for
three crypto backend was a very tedious task.


This would also mean that we can e.g. get rid of our chacha2020-poly1305
implementation as both OpenSSL and mbedtls are offering it!


Here is my patch, feel free to comment and test it.

https://gitlab.com/arisada/libssh-mirror/-/commit/1ed690e8f5c33ea73d06ab83fc
9eb3283fdfbedf


Will look into it on Monday. Thanks!


Hi,
thank you for starting this discussion with actual commit proposed. We 
talked about this for some time already and this incident is raising the 
issue more priority again. For Fedora, we do not need libgcrypt backend, 
but I would certainly like to get hold of the ones who contributed this 
code before we will remove it altogether (I was not here at that time so 
I do not know the whole story).


On the technical note, the changeset is missing is removal of libgcrypt 
reference from doc/introduction.dox (and sign-off trailers).


The other question is whether we want to remove it now or after 0.10.0 
release which should be at sight. I am still a bit hesitant to do it 
from day to day without announcement and some grace-period.


Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Function behaves differently when libssh is compiled statically

[Jakub Jelen]

On 2/1/21 2:31 PM, Anderson Sasaki wrote:



- Original Message -

From: "petergeorgenm" 
To: libssh@libssh.org
Sent: Monday, February 1, 2021 2:04:18 PM
Subject: Function behaves differently when libssh is compiled statically

I wrote a simple connection setup following the tutorial:
//main.c
#pragma comment(lib, "user32")
#pragma comment(lib, "Advapi32")
#pragma comment(lib, "Shell32")
#pragma comment(lib, "Ws2_32")

#include 
#include 
#include 
#include 

int main(void){
int ret_c=0;
int rc;
int port=22;
ssh_session the_session=ssh_new();
if(the_session==NULL) {printf("1\n"); return -1;}

ssh_options_set(the_session, SSH_OPTIONS_HOST, "user@1.2.3.4");
ssh_options_set(the_session, SSH_OPTIONS_PORT, );

rc=ssh_connect(the_session);
if(rc !=SSH_OK) {
ssh_free(the_session);
printf("2, %d\n", rc);
getchar();
} else {
printf("success\n");
getchar();
}

ssh_disconnect(the_session);
ssh_free(the_session);
return 0;
}

I used vcpkg to install both static and dynamic versions of libssh, they
reside as follows respectively:
C:\Users\User\vcpkg\installed\x86-windows-static\
C:\Users\User\vcpkg\installed\x86-windows\
If I compile the previous code dynamically with:
cl /I C:\Users\User\vcpkg\installed\x86-windows\include main.c /link
C:\Users\User\vcpkg\installed\x86-windows\lib\* /SUBSYSTEM:CONSOLE
and then run, the output I see is:
success

If I compile it statically with:
cl /D LIBSSH_STATIC /I
C:\Users\User\vcpkg\installed\x86-windows-static\include main.c /link
C:\Users\User\vcpkg\installed\x86-windows-static\lib\* /SUBSYSTEM:CONSOLE
and then run, the output I see is:
2, -1

Both versions compile and link without any errors. I also tried to use putty
to ssh to user@1.2.3.4 and it works fine.
Please tell me if I need to provide any more debugging information, or if any
information isn't clear.


Hello,

Could you please try to call ssh_init() before calling any other function from 
libssh (and ssh_finalize() at the end)?
When using dynamic linking this will be a no-op.

This is a requirement when statically linked. It is mentioned in Chapter 8 of 
the tutorial and in the API documentation. I'm sorry that this is not better 
documented.


I believe this was already discussed, but would it be possible to add 
some more noisy safeguard? At this moment, it is inside of ssh_connect() 
setting error quite visibly:


https://gitlab.com/libssh/libssh-mirror/-/blob/master/src/client.c#L512

At this moment, to read the error, one needs to use ssh_get_error() (I 
see it properly documented in the tutorial), but I am wondering if we 
could add this error earlier (even ssh_new?) or add normal 
fprintf(stderr, ...) as this is is quite huge programming issue and is 
most likely something that will be really captured in development 
environment. Even better would be some build-time check, but I do not 
think it is simply possible.


Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Config parser doesn't accept multiple IdentityFile lines

[Jakub Jelen]

On 1/28/21 3:20 PM, Tilo Eckert wrote:

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).


Hi,
thank you for the report. This is indeed oversight and IdentityFile 
should be accepted multiple times similarly as in OpenSSH and similarly 
as few other configuration options.


You can always use a workaround as this:

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


Regards,
Jakub


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






--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Can't connect with some clients

[Jakub Jelen]

On 1/13/21 5:13 PM, Emiliano Gonzalez wrote:

Solved!!!
I'm using mbedcrypto and do not have ChaCha20-Poly1305. Disabling this 
cypher works ok.
But it is allowed to enable in this situation ChaCha20 and 
cipher->max_blocks = ((uint64_t)1 << 30) / cipher->blocksize crash with 
division by zero.

Shouldn't this situation be controlled? It is not an error?


There were couple of bugs in chacha20-poly1350 implementation that 
should be fixed with the following PR:


https://gitlab.com/libssh/libssh-mirror/-/merge_requests/150

Can you check that the PR solves the for you?

Jakub

El mié, 13 de ene. de 2021 a la(s) 07:58, Jakub Jelen (jje...@redhat.com 
<mailto:jje...@redhat.com>) escribió:


On 1/12/21 4:09 PM, Emiliano Gonzalez wrote:
 > I have a ssh server.
 >
 > When I connect with the client on Fedora 32 ssh there are no
problems.
 >
 > With PuTTY: Release 0.74 I can't connect with error: Couldn't
agree a
 > host key algorithm (available: rsa-sha2-512, rsa-sha2-256)

That sounds like an issue of PuTTY, that it can not use the RSA SHA2
hostkey algorithms from RFC8332.

As a workaround, you can configure your server with different hostkeys
(ed25519) so incompatible clients can connect too.

 >  From Centos 7 ssh server crash. In packet.c (line 1862):
 >
 > |/* For smaller blocks use limit of 1 GB as recommended in
RFC4253 */
 > cipher->max_blocks = ((uint64_t)1 << 30) / cipher->blocksize; |
 >
 > cipher->blocksize is 0;

What cipher is used for this connection? There is no cipher that would
have blocksize == 0.

Can you get a debug log?

Regards,
-- 
Jakub Jelen

Senior Software Engineer
    Crypto Team, Security Engineering
Red Hat, Inc.





--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Can't connect with some clients

[Jakub Jelen]

On 1/12/21 4:09 PM, Emiliano Gonzalez wrote:

I have a ssh server.

When I connect with the client on Fedora 32 ssh there are no problems.

With PuTTY: Release 0.74 I can't connect with error: Couldn't agree a 
host key algorithm (available: rsa-sha2-512, rsa-sha2-256)


That sounds like an issue of PuTTY, that it can not use the RSA SHA2 
hostkey algorithms from RFC8332.


As a workaround, you can configure your server with different hostkeys 
(ed25519) so incompatible clients can connect too.



 From Centos 7 ssh server crash. In packet.c (line 1862):

|/* For smaller blocks use limit of 1 GB as recommended in RFC4253 */ 
cipher->max_blocks = ((uint64_t)1 << 30) / cipher->blocksize; |


cipher->blocksize is 0;


What cipher is used for this connection? There is no cipher that would 
have blocksize == 0.


Can you get a debug log?

Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: How to set the disconnect message as a server

[Jakub Jelen]

On 11/23/20 7:21 AM, Adley Phu wrote:
When disconnecting, the SSH protocol allows you to send a uint32 reason 
code and human readable description. See 
https://tools.ietf.org/html/rfc4253#section-11.1 
<https://tools.ietf.org/html/rfc4253#section-11.1> "SSH_MSG_DISCONNECT"


You can receive this message with ssh_get_disconnect_message() but is it 
possible to set the message when disconnecting? Specifically, as a 
server disconnecting a client.


Hi,
at this moment, the ssh_disconnect() function does not take any argument 
to support different disconnect codes. We have all the RFC codes 
defined, but only the SSH_DISCONNECT_BY_APPLICATION is being used:


https://gitlab.com/libssh/libssh-mirror/-/blob/master/src/client.c#L693

If you would find this functionality useful, I would be happy to review 
your patches.


Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.

Re: Timeout not working with sftp_read

[Jakub Jelen]

On 11/18/20 9:06 PM, Makarand Pradhan wrote:

Hello All,

I'm noticing an issue with sftp_read and would highly appreciate advice.

If the link goes during sftp_read, sftp_read does not return. It stays stuck 
even when the session timeout is set to 10 seconds.


The SSH_OPTIONS_TIMEOUT is a connection timeout, not the sftp read timeout.

Regards,
Jakub

Re: [talk-cz] Mazání nepohodlných dat z OSM

[Jakub Jelen]

FYI, dnes jsem revertoval vsechny zmeny udelane panem Gourny. Par tydnu
zpet jsem mel diskuzi jeste s dalsimi cyklisty a nastesti tento postoj
neni sdileny vsemi bikery, tak doufam, ze se toto nebude opakovat.

Relevantni changesety: 9414964, 9414981, 9415, 94150062, 94150115,
94150157(postupne reverty jednotlivych zmen).

Zdravim,
Jakuje

On 10/30/20 1:18 PM, Jan Martinec wrote:
> Ahoj,
>
> To je bohužel smutnej příběh, ale nedá se svítit: utajený a veřejně
> dostupný je kulatý trojúhelník (. Pokud to nemá existovat, ať. Pokud
> se to má zlegalizovat, ať.
>
> "Když se o tom tady nebude mluvit, tak je to vyřešený," je pštrosí
> přístup, navíc úplně marný: najde to někdo jiný, přidá to do Google
> Maps, nebo do Apple Maps, nebo do Waze, nebo do Mapy, nebo to napíše
> na FB...takhle už se - bez zlého úmyslu - proflákly i věci, který byly
> opravdu klasifikovaný jako tajný.
>
> Pokud potřebuje mít v hlavě určený nějaký zrcadlo, na které se bude
> zlobit, že odráží svět - no, co se dá dělat.
>
> Tím se to pro mě stává jednoznačně vandalismem.
>
> Zdar,
> HPM
>
> Dne pá 30. 10. 2020 12:09 uživatel Vladan Kudláč
> mailto:vladankud...@gmail.com>> napsal:
>
> To jsem nechtěl, ale zjevně jsem uživatele Gourny už naštval.
>
> Gourny 
>
> On 2020-10-30 08:42:41 UTC kudlav wrote:
>
> Zdravím,
>
> už to nechci znovu řešit. Na jedné z těchto tras se zabil měsíc
> zpět člověk. Ilegální jsou, protože jsou bez souhlasu majitele
> pozemků. Já nemám dostatečnou páku všechny za Vaší komunity
> přesvědčit, že by to v mapě být nemělo. Takže je to na rozhodnutí
> rovnějších si z nás, kteří mají to štěstí být správci nějakých
> internetových stránek. Dělejte jak uznáte z vhodné.
>
> Trasy, které jsem smazal, jsou ilegální trasy pro jízdu na
> horském kole. V mapách by proto vůbec neměly být.
>
> Zdravím, výše citovaná vaše odpověď je bohužel v rozporu s
> tím, co OpenStreetMap představuje:
>
> /OpenStreetMap is a database based on existing features on the
> ground [2], not something idealized by legalization or
> something somebody believes should or should not be in the
> map.
> [2] 
> https://wiki.openstreetmap.org/wiki/Good_practice#Map_what.27s_on_the_ground/
>
> Bohužel v tomto případě část tras několik členů komunity v
> nedávné době jelo, takže v terénu se cesty určitě nacházejí.
> Mazání tedy ne, lepší možností je změnit vlastnosti cest, aby
> se nejednalo o singletrail ale například jen o lesní pěšinu.
> Podle čeho určujete, které trasy jsou ilegální a které ne?
> Takovéto rozhodování musí být něčím podpořeno.
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: Deprecating SCP

[Jakub Jelen]

On 11/5/20 7:49 PM, Michael Hennebry wrote:

On Wed, 4 Nov 2020, George N. White III wrote:


On Wed, 4 Nov 2020 at 11:39, Michael Hennebry <
henne...@web.cs.ndsu.nodak.edu> wrote:



In this particular case, I'd think the client
could tell that a .BAT file was not a .c file.



Downloading 1000's of files resulting from some HPC calculation
it would be easy to overlook an unwanted file.


To be clear, I'd meant the client could to it automatically.


To be clear, the scp client does finename matching already by default. 
But if there is a recursive download (or a regex matching the malicious 
file), this might not help either.


Not even using sftp, if the file is sneaked inside of the downloaded 
directory. But breaking scp protocol to do that is a matter of inserting 
one command, while SFTP requires significantly more work and the 
downloads can be properly audited (unlike scp, which is just a command 
on the server).


Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: Deprecating SCP

[Jakub Jelen]

On 11/2/20 4:57 PM, francis.montag...@inria.fr wrote:


Hi.

On Mon, 02 Nov 2020 15:44:39 +0100 Jakub Jelen wrote:


Is this something you would like to see in Fedora soon?


No. I prefer a lot to use rsync, because scp:

  - has no dry-run mode
  - is not incremental
  - follows symlinks when used with the -r option
  - has too few options: no --chown --chgrp


Then you are indeed not the target group.


Do you have something against this?


No: users should be free to continue using it (but not with the -r option IMO).


The vulnerability of the -r was not the only issue found in scp over 
last years. And recursive copying of files is handy so I do not think it 
is a good idea to axe just one commandline switch.



Is your use case missing?


With scp no, but I use sshfs for years. This is IMO something to promote.

Ex: Example: a simple 3-way copy, assuming you have root SSH access (with keys)

 mkdir /mnt/hostA
 sshfs -o transform_symlinks root@hostA:/ /mnt/hostA
 rsync -a --delete /mnt/hostA/etc/skel/ root@hostB:/etc/skel


sshfs is using sftp internally so you are already using the sftp. 
Congratulations.


Regards,
--
Jakub Jelen
Senior Software Engineer
Crypto Team, Security Engineering
Red Hat, Inc.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org