OPENSSH: How to Create a Public/Private Key Pair

Install the OpenSSH utility on the machine which will instigate a secure connection request, by downloading the source files and copying them to (say) C:\ OPENSSH.

Open a command console (e.g. Windows cmd), and run the following command, from C:\ OPENSSH:

ssh-keygen -b 2048 -t rsa
Enter file in which to save the key: test_key
Enter passphrase: [create a passphrase, or leave blank for no passphrase]

Two files will be created:


The file contains the public key (which can always be derived from the private key), and which can be provided to a third party to secure an SFT connection, for example.

Sun Solaris UNIX: How to Encrypt and Decrypt a File

SFTP can be used to encrypt a file in transit, but what if file-encryption-at-rest is required?

To encrypt a file “at rest” (i.e. on the file system), two things are required:

  1. the encryption algorithm must be chosen;
  2. an encryption “key” must be generated (or provided by a third party) – this is used to encrypt, and subsequently decrypt, the file.

In this example, a random key is generated in a 3DES format, using the dd utility:

dd if=/dev/urandom of=$HOME/key.3des.24 bs=24 count=1


  • if = file indicates a random key, using the /dev/urandom file
  • of = keyfile is the output file that holds the generated key
  • bs = n is the key size in bytes. For the length in bytes, divide the key length in bits by 8.
  • count = n is the count of the input blocks. The number for n should be 1.

The maximum and minimum key sizes (in bits, not bytes) can be determined using:

encrypt -l

…which gives:

Algorithm Keysize:        Min   Max (bits)
aes                       128   256
arcfour                     8  2048
des                        64    64
3des                      128   192
camellia                  128   256

The newly-generated key file, $HOME/key.3des.24, can then be used to encrypt a TEST.csv file (using the 3DES algorithm), using:

encrypt -a 3des -k $HOME/key.3des.24 -i ./TEST.csv -o ./e.TEST.csv

…and decrypted using:

decrypt -a 3des -k $HOME/key.3des.24 -i ./e.TEST.csv -o ./u.TEST.csv


xmllint : a UNIX utility to check for badly-formed XML data

It’s now commonplace to send or receive data files in XML format. And some eBusiness Suite functionality relies on XML configurations files. For example, BI Publisher data definitions are XML-formatted, and if you try to upload a badly-formed data template file to a BI Publisher data definition, Oracle responds with:

Error: The uploaded file XXAP073_BW_USER_RIGHTS_INT_XDO_DATA_TEMPL.xml is invalid. The file should be in XML-DATA-TEMPLATE format.


Not very helpful.

However, there’s a useful UNIX utility that will parse an XML file, and highlight any badly-formed XML syntax. It’s called xmllint:

xmllint --noout ${XML_FILE} 

It will return 0 (zero) if the XML file contains well-formed XML data; if the XML is badly formed, xmllint will list the specific errors. For example…

bash:dave$ XML_FILE='XML_DATAFILE.xml';
bash:dave$ echo ${XML_FILE}
bash:dave$ xmllint  --noout ${XML_FILE}
XML_DATAFILE.xml:320: parser error : attributes construct error
      <element name='FIRST_NAME' value='FIRST_NAME'/>;
XML_DATAFILE.xml:320: parser error : Couldn't find end of Start Tag element line 320
      <element name='FIRST_NAME' value='FIRST_NAME'/>;

I’ve used this in file transfer interfaces, to check that the XML file being passed contains well-formed XML data, for example:

xmllint  --noout ${XML_FILE}

echo 'XML format validation result : ${VALIDATE_XML}'
if [ ${VALIDATE_XML} != 0 ]; then
  echo ' ';
  echo 'XML data is badly formed';