SSH Digital Certificates not working

Okay, in PeopleTools 8.53 you can now specify a digital certificate for SSH, not sure if this was there in 8.52, but in the past I would put the SSH keys (private and public) out in the sshkeys folders of the application server and reference them in the URL properties for SFTP configurations.

Well, you can now store these in the digital certificates area and just reference it using the alias key.  In order to make this work you need to generate an ssh key pair.  On a Redhat system you should be able to run:


Just follow the prompts.  You will need to have the openssl rpm’s installed.  This should generate and id_rsa and file in the users home directory under the .ssh directory.  You will want to append the key to the authorized_keys file (create it if it does not exist).

cat ~/.ssh/ >> ~/.ssh/authorized_keys

chmod 644 ~/.ssh/authorized_keys

You should be able to check you key by issuing the following:

openssl rsa -in ~/.ssh/id_rsa -check

Now here comes the trick, if you try to copy the public and private key from the SSH window on a windows machine and paste it into the digital store, I found that this would cause the certificate to fail.  I had to sftp the private and public key to my local machine and use my trusty UltraEdit to open the files in unix mode and copy and paste the contents into the digital certificates windows.  It appears that when copying in windows mode it uses the CR/LF versus if you have it in Linux mode it will just have the LF.  This appears to make a big difference.  No errors either way except it just won’t work with the windows format.

NOTE:  If you are copying the .ssh directory from one server to another (multiple application servers) make sure that the permissions on this folder are 700.  If you have a separate batch processing server you will want to ensure that it too has the .ssh folder and keys for the assignment user.

Copy PeopleSoft File Attachments

I was doing some work with file attachments in PeopleSoft over the past couple of weeks and I have to say PeopleSoft’s ability to handle attachments is flat out bad.  However, it does work.  The client I was working with found that storing documents in the database was starting to consume an extreme amount of space which made the database have issues.

In PeopleTools 8.54 there is a batch copy attachment feature that lets you move attachments from one URL to another.  So you can define a URL for sftp and another for the database record and copy attachments to/from those URLs. In 8.53 there is just an online page for this, however, if you are doing a copy of more than about 1000 documents you will want to switch to a batch mode.

I was also fascinated with the orphan cleanup process that looks at the referencing record and the storage record and clears out any non-referenced storage record documents.  PeopleSoft does this by looking for the FILE_ATTACH_SBR subrecord in the record definitions and generates a list of attached file names and then compares that to the records associated with FILE_ATTDET_SBR subrecord.  This process cleared out about 25,000 documents that were not referenced.

When doing the actual copy from the database to the sftp (which was local), I did it in chunks by identifying the correct reference record and specifying that in the file record array for the copyattachment function.  As I had one record that had almost 200,000 documents, which if you don’t specify the reference records it will look at all the records with the FILE_ATTACH_SBR subrecord which in the Finance 9.2 environment I am in was 108 records, however only 8 had references.

I also built an index for the record with the actual document which was unique on the fields:  ATTACHSYSFILENAME, VERSION, FILE_SEQ, which is different then the delivered index thus allowing the look up to be much more efficient.


When building environments with PeopleTools 8.53 & 8.54 everything will be going along tickety boo and it will go to encrypt the passwords and bam:

Error: Process aborted. Possibly due to JVM is not available or missing java class or empty password.

Well, isn’t that interesting.  The PeopleTools 8.53 and 8.54 have a new SALT component to its passwords and clearly uses the Java to do the encryption.  Add %PS_HOME%\jre\bin to the beginning of the PATH variable and re-run data mover and try the encryption of the passwords again.