PPK Security - SFTP

Last modified by Erik Bakker on 2024/09/03 10:33

In this document, we will use the information from the actual root cause analysis to make a generic view that can be used if you run into the same or a similar problem in the future. Finally, the document will describe the situation, the problem, the analysis, and the result.

Should you have any questions, please get in touch with academy@emagiz.com.

1. Situation

When you need to connect to an SFTP there might be an requirement that you need to send a PPK file for authentication. In some cases this PPK file is too 'new' for the underlying library that eMagiz uses to set up a connection to an SFTP.

2. Problem

The problem in this case was that authentication to an SFTP failed, due to a misconfiguration.

3. Analysis

3.1 Reproduction

To reproduce the issue we build a comparable setup in a different eMagiz model using a ppk file (similar to the one used at the client) we generated ourselves and tried to connect to our own SFTP. As a result we got an “invalid private key” exception back. This means that the generated ppk is too new for the library that is used within eMagiz (Invalid Private Key). As a remedy we changed the ppk to a pem as detailed in one of the answers of this question. As a result we got an “Auth cancel” error which was to be expected as our ppk was generated by ourselves and the SFTP we were trying to connect to was not aware of this.

3.2 Analysis

With this information we started comparing our solution to the solution built at the client and we tried to change various aspects of the solution to find reasons why it was working at our end but not at the client side. We concluded that the problem did not lie in using properties or having additional components in the flow that might cause weird behavior.

Because we had a working solution we tried to break it in such a way to reproduce the error. To do we changed the reference to the file and as a result we got the same error as described in the ticket.

Based on this we concluded that the most likely culprit is a configuration error on the part of the user. To validate this we discussed with the client to gain access to the ppk in question and we tried to call the external SFTP mentioned in the ticket. This failed due to the “invalid private key” error, so not a “FileNotFound” error. This leads us to conclude that when the reference to the file is made correctly the connection will work once the ppk is changed into a pem and correctly uploaded to the flow in question.

4. Result

Once the ppk was changed into a pem and the configuration mistakes were removed the flow worked again and the SFTP could be accessed again.

5. Suggested Additional Readings