1

I am using openssl to encrypt my backups before send it to an ftp server where I store them.

At first, when I tried to decrypt the files I was getting this error:

openssl rsautl -decrypt -inkey ../key.server.pem -in enc.key.txt -out key.txt 
RSA operation error 139759177856680:error:0407106B:rsa routines:RSA_padding_check_PKCS1_type_2:block type is not 02:rsa_pk1.c:190:
139759177856680:error:04065072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check     failed:rsa_eay.c:616:

I am following this steps to encrypt.

I thought the problem was with the encryption, but checking the md5sum of the file show me that the file on the server had changed with the one I downloaded from the ftp server. A example:

I have a file called enc.key.txt that contains a passphrase to decrypt the backup:

$ hexdump enc.key.txt
//...
//...
0000100 16e3 c2e3 cecd 2afe eb8c 9617 8d58 *0dd0*
//...

And the hexdump of enc.key.txt once downloaded to my computer differ by one value, in this line: 

//...
0000100 16e3 c2e3 cecd 2afe eb8c 9617 8d58 *0ad0*
//...

I've edited the value with an hex editor and then I was able to decrypt the file, but I don't know why is the file being modified.

I am sending the backups to the ftp server with ncftp like this:

### Dump backup using FTP ###
#Start FTP backup using ncftp
ncftp -u"$FTPU" -p"$FTPP" $FTPS<<EOF
mkdir $FTPD
mkdir $FTPD/$NOW
cd $FTPD/$NOW
put enc.key.txt
lcd $BACKUP
mput *
quit
EOF

Could you help me? Thanks in advance

Community
  • 1
Alejandro Alcalde
  • 211
  • 3
  • 11

1 Answers1

3

The character 0a is Line Feed, and 0d is Carriage Return. In "ASCII Mode", FTP transfers between different operating systems can change these. For instance, a Unix/Linux-native file with LF line termination uploaded to a Windows SharePoint site will have each LF changed to CRLF. Some implementations may simply change the LFs to CRs. Check to be sure you're specifying binary mode in your transfers.

The documentation for ncftp indicates that it defaults to binary mode, but does accept the binary command like most ftp clients do. I'd insert that command before any files are transferred and see if it helps. If it does, that means something is somehow overriding the default.

In this case, the problem apparently isn't ncftp but Filezilla on the other end. It defaults to "Auto", which means that a file with .txt extension is ASS|U|MEd to be ASCII, and it messes with line termination.

Monty Harder
  • 633
  • 4
  • 9
  • I suspected something similar but the default for ncftp is binary. That said I would suggest adding a "binary" command before your put in order to ensure the mode is correct – Phil Jul 23 '13 at 14:42
  • Thanks, I just changed the transfer to binary but didn't solve the problem. – Alejandro Alcalde Jul 23 '13 at 14:49
  • Now the file differ in *0ace* and *0dce*. My computer and the server are running debian. Maybe i have to change as well filezilla to binary? – Alejandro Alcalde Jul 23 '13 at 14:50
  • @algui91, I suggest you to look at `lftp`, `wput` and `curl` tools -- they all are able to perform FTP uploads. On the other hand, do you really need to use insecure procotol? SSH which has can do `SFTP` or simple transfers (using `scp`) does not suffer from the text/binary dichotomy syndrome and is secure. – kostix Jul 23 '13 at 15:12
  • Yes, definitely set filezilla to binary. It defaults to "auto", and when it sees "txt" will mess with line termination. – Monty Harder Jul 23 '13 at 16:03