Search code examples
opensslftpzipsftptar

FTP file in secure way - Openssl to encrypt and decrypt a folder/files - gzip: stdin: not in gzip format tar: Child died with signal 13

Red Hat Enterprise Linux Server release 7.9 (Maipo)

OpenSSL 1.1.0f 25 May 2017 (Library: OpenSSL 1.1.1g FIPS 21 Apr 2020)

The end-user doesn't have a SFTP server setup and gave me a FTP server to get some artifacts. To transfer the file over internet to FTP, it's better to secure the file first and for that I used the following post: https://www.tecmint.com/encrypt-decrypt-files-tar-openssl-linux/

Basically, to create the secure .tar.gz / a .tgz file from a folder, I used the following command to password-protect and encrypt it, it worked.

# tar -czf - * | openssl enc -e -aes256 -out secured.tar.gz

and to decrypt the file, use the following (I'm not using -C <folder> option) like mentioned as per the post to put the contents of secured .tar.gz file into some folder):

# openssl enc -d -aes256 -in secured.tar.gz | tar xz

This worked on my machine for encrypting and decrypting (prompts for password and does it's job).

When the end-user got the same file (md45sum value of the files is same at my end and their end, they got the following error message.

  • PS: They entered the correct password as using the same password works, on my side.

In my case, the file is with .tgz extension.

$ openssl enc -d -aes256 -in secure-artifact-package-1.0.0.tgz | tar xz -C artifact_1.0.0
enter aes-256-cbc decryption password:
 
gzip: stdin: not in gzip format
tar: Child died with signal 13
tar: Error is not recoverable: exiting now
error writing output file

Told them to try with -C artifact_1.0.0 and got the same error mesg.

Why this error mesg is comming when the password is correct?

Solution

  • End-user was using an older version of OpenSSL on their side and that seems like to have caused this password related problem during decryption i.e. if a file is created using the above way using OpenSSL version X and if you try to decrypt it using OpenSSL version Y, then this issue comes.

    After end-user installed the same OpenSSL version (or possibly a newer version than mine would resolve as well), the issue went away.

    The issue was resolved after installing the following OpenSSL version on their Linux machine.

    OpenSSL 1.1.0f 25 May 2017 (Library: OpenSSL 1.1.1g FIPS 21 Apr 2020)