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 (jjelen or jakuje on IRC or Matrix)
  • Anderson Sasaki (toshisasaki on Matrix)
  • Andreas Schneider (asn on Matrix)

Project ideas

async SFTP client

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

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.

The libssh can already use any authentication keys through OpenSSL PKCS #11 engines, which should cover most common secrets management systems. One of these might be TPM 2.0, which bounds the key to particular machine with all its pros and cons. These days, there are different and more modern ways of accessing secrets, for example libsecret, which might be an alternative to PKCS #11.

Support for OpenSSH certificates

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.

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.

  • Difficulty: Medium
  • Project length: 175 hours
  • Language(s): Good knowledge of C, knowledge about elliptic curves cryptography or u2f is a plus 😉
  • Possible Mentors: Jakub Jelen
  • References:

Completed projects

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

  • Difficulty: medium
  • Project length: 175 hours
  • Language(s): Good knowledge of C and network programming
  • Possible Mentors: Jakub Jelen
  • References:
    • The ssh server in libssh is using callback to handle various SSH protocol messages or authentication types
  • Student: Zeyu Sheng
  • https://summerofcode.withgoogle.com/programs/2022/projects/Hm79LwKE