The SSH Library!
The SSH Library!

Google Summer of Code

Contributors guidance

The application process consists of next steps:

  • Become acquainted with application process for GSoC.
  • Search mentor for chosen project in mailing list discuss or propose your own project and find a mentor for it.
  • Submit the application/proposal including all requirements at the Google Summer of Code Site.

Requirements before starting search for mentor:

  • Prepare answers to questions about own participation in project.

Application requirements/recommendations:

  • All applications must go through Google’s application system; we can’t accept any application unless it is submitted there.
  • Use a descriptive title in Google’s system. Good example: “libssh: Improve SSH connection fuzzing” Bad example: “My gsoc project”
  • Make it easy for your mentors to give you feedback. If you’re using Google docs, enable comments and submit a “draft” (we can’t see the “final” versions until applications close). If you’re using a format that doesn’t accept comments, make sure your email is on the document and don’t forget to check for feedback!

GSoC libssh organization administrators:

  • Jakub Jelen (jakuje on Matrix)
  • Sahana Prasad (saprasad on Matrix)
  • Andreas Schneider (asn on Matrix)

libssh mentors:

  • Jakub Jelen (jakuje on Matrix)
  • Sahana Prasad (saprasad on Matrix)
  • Eshan Kelkar (eshan_k on Matrix)

Project ideas

Support for FIDO/U2F keys on the client side

The server side support (signature verification) and key type definitions are in place so authenticating using these keys from openssh client to libssh server should already work. But the libssh clients can not use the U2F based keys as well as it can not be used to enroll the hardware for authentication with ssh.

The project should involve adding code paths to create U2F signatures, as well as possibility to test them without the actual hardware in the CI. Here we can get inspiration from OpenSSH, as they provide sk-dummy.so, which can simulate fido/u2f devices. This is packaged in Fedora.

OpenSSH-compatible CLI

The libssh is provided as a library and only provided binaries are examples implementing either specific client or server examples without an attempt to implement a CLI that can support most of the OpenSSH’s CLI use cases and could be used as a drop-in replacement. The libssh should already support most of the use cases (and if not, new issues should be opened and implemented). Similar exercise can be done for server, but there will many more gaps.

  • Difficulty: Medium
  • Project length: 350 hours
  • Language(s): Good knowledge of C
  • Possible Mentors: Jakub Jelen
  • References:

Improve configuration compatibility with OpenSSH

The libssh is trying to be compatible with the OpenSSH configuration files to make the experience for our users as smooth as possible to be able to use only one configuration file for both. But OpenSSH configuration file options grow in complexity and we are not catching up with all the corner cases, which sometimes got reported to us. This project is about understanding the SSH configuration, how it is handled by OpenSSH and adjusting the libssh configuration parser to match as closely as possible, including adding a automated test coverage that can compare results with the OpenSSH parser.

It might be possible to create a fuzzer for the configuration file, that would feed the inputs into both openssh and libssh to verify they result in the same effective configuration.

  • Difficulty: Hard
  • Project length: 350 hours
  • Language(s): Good knowledge of C, understanding of fuzzing testing is a plus
  • Possible Mentors: Jakub Jelen
  • References:

Completed projects

Support for OpenSSH certificates (2024)

The libssh supports OpenSSH certificates as opaque blobs alongside the client keys only to pass them along with the key to some compatible server to verify the authentication. This is ok for basic interoperability with OpenSSH servers configured to accept certificates signed with Users CA, but it does not cover the server use cases (authenticating users), nor the Hosts CA (authenticating servers to clients) use case at all.

Test coverage for GSSAPI Authentication (2024)

The libssh supports GSSAPI authentication for ages. But there is no automated test coverage for neither client nor server, making the code Schrodinger code (both working but more likely broken). This project involves learning how the GSSAPI authentication in SSH protocol works, proposing test cases and implementing them inside of the upstream testsuite with help of the cwrap wrappers. Stretch goal is looking into the GSSAPI Key exchange defined in the same RFC and RFC8732 and testing it well.

async SFTP client (2023)

The SFTP implementation in libssh requires application to call libssh API to send each chunk of data, which is not the fastest option. Our idea is that libssh should provide an API similar to io_uring, where you set up the transfer of the file and libssh will take care of the rest.

Support for OpenSSH connection multiplexing (2023)

The OpenSSH supports sharing several sessions over a single TCP connection, which makes opening new channels faster from cli. The usage of the same MUX protocol is not mandatory, but as we already work with openssh configuration files so, it would probably make sense to implement it in compatible way.

Callback based sftp server (2022)

Currently, the sftp server implementation is based on a huge switch handling all the possible messages. Changing to callback-based model can provide much better customization by the library users