HTML comments are not displayed by a user's browser, but they're available in the source view. JSP comments are removed before the source HTML is returned to the browser.

In many cases where we use comments in our JSPs, we prefer they not appear in the browser-viewable page source. Best case, they're confusing and useless to anybody who looks at them. Worst case, they actually reveal something about our implementation which we'd rather not reveal.

This post is intended to document procedures which can be used to simplify and increase security of remote login procedures to UNIX systems through use of SSH private and public keys.

PuTTY for Windows

PuTTY includes a full suite of programs in addition to the PuTTY executable itself. The top of the download page describes the purpose of each tool. We'll use 3 of those tools in this process.

Creating an SSH private key

PuTTYgen is used for this step. Use the "Generate" button and follow the instructions.

You can choose RSA or DSA key types, and you can change the key size.

Enter a passphrase and "Save private key" somewhere on your local system. Note: Use a passphrase that you can remember but that is stronger than a normal password. Security people usually suggest using whole sentences or combinations of words/phrases. Later we'll configure another program so that you don't have to type this passphrase very often.

Installing the public key on the remote system

There are various ways to do this, but the PuTTYgen window explains what I've found to be the easiest. That is, copy the text from the Key text area at the top of the window and manually add it to the $HOME/.ssh/authorized_keys file on the remote system. authorized_keys can contain multiple lines, one for each public key you wish to allow to connect to the remote system as your user.

The authorized_keys file probably doesn't yet exist, and the .ssh directory may or may not. (The same directory is where ssh places the known_hosts file that contains the public keys for hosts which you have trusted for ssh connections in the past.)

If either doesn't exist and has to be created, ensure that the permissions are as follows

Each line in authorized_keys can also be configured with further options, including restricting a key's use to specific hosts, for instance. The best documentation I found on those options is at this Free BSD man page.

You can, and probably will want to, install the exact same public key on each system on which you want to use key-based authentication.

Using the key pair to login with puTTY

This is the "manual" approach, which isn't necessary if you follow the next step, but I wanted to document it for completeness. Here we explicitly tell a PuTTY session that we'll be authenticating with the private key file we saved earlier.

If you use this approach, when you connect to the remote system, you'll be prompted to enter your private key's passphrase:

You could argue that's actually worse usability than the user ID/password solution since you'll be typing a much longer passphrase, which is where the next step comes in handy.

Automatic key usage with Pageant

Another of the PuTTY programs, Pageant, can act as an agent providing access to private keys and only requiring you to authenticate once for each key.

Once you've added this key file to Pageant and entered your passphrase there, you can leave Pageant running, and all the PuTTY programs will be able to authenticate with your key without your further involvement. In fact, with Pageant running, any attempts to connect to a host which trusts your key will automatically connect even if you haven't explicitly configured your PuTTY session to use key authentication. (See the default, enabled "Attempt authentication using Pageant" checkbox in the above PuTTY screenshot.)

Furthermore, the Pageant tray icon can actually be used to directly launch any saved PuTTY sessions you've created. Right-click on the tray icon and select "Saved Sessions".

Finally, you can use the command-line to pass to Pageant any private keys you want it to automatically load when it starts. This allows you to create a shortcut icon that will prompt you for the necessary passphrases and then start a copy of Pageant ready to be used for subsequent, key-authenticated SSH sessions:

PAGEANT.EXE test-key.ppk

Notes

The private key's passphrase (and a locked workstation) is all that stands between an intruder and your remote logins. As such, the passphrase needs to be non-trivial, and if you're using Pageant, lock your workstation obsessively.

Overview

EFS on AIX was designed so that each file is encrypted with a unique key. The cryptographic information is kept in file-extended attributes. EFS uses Extended Attributes (EA) Version 2. EFS is built into the enhanced journaled file system (JFS2) — it is not a new file system. You can create EFS on a new file system or enable it on a new file system. EFS is only meant for the encryption of data file systems, not for system-based file systems (such as /var and /opt).

You can perform encryption on the entire file system by switching on Inheritance, or by doing it per file.

A key store is used to access data with password protection. This password can be the login password or a different password that root cannot access. - Source

Keystores

Each user on the system will have its own keystore where its public and private keys are stored. This keystore can be protected by a separate password or can be synchronized such that it's protected by the normal login password. I believe this is a system-wide setting, and the default is to synchronize the passwords. User keystores are located in /var/efs/users/<username>

If a user is explicitly granted access to act as a specific group in relation to EFS (in addition to being assigned to that group at the OS level), the group's private and public keys will also be copied into the user's keystore.

Groups also have their own keystores, located in /var/efs/groups/<groupname>.

File encryption

Each file is encrypted with a unique, symmetric (AES) key. For each user or group that is authorized to view the encrypted file, the symmetric key is then itself encrypted with the user/group's public key from its keystore, and that user-specific encrypted version of the key is stored in the file's extended attributes (EAs). That is, there will be one EA for each user and group that has access to the file in question. (See section 2.4 of the AIX V6 Advanced Security Redbook.)

Requirements & Constraints

AIX 6.1

CryptoLite in C (CliC) cryptographic library needs to be installed.

Enable Role Based Access Control (RBAC)

Explicitly enable the system to use EFS. (efsenable command)

Restriction: You cannot export the EFS through NFS.

Tips & Specific Commands

The efsmgr command manages encryption of a file or directory. efskeymgr manages keystores, including loading them into memory or removing them from memory.

To determine whether a particular file or directory is encrypted, issue the following command:

ls -U filename

Encrypted files/directories will have an extra "e" at the end of their access attributes:

drwxr-x---e 5 user group 256 Nov 23 20:44 directory

To determine which keys are loaded into your current session, issue the following command:

efskeymgr -V

Your personal user key and any group keys to which you have access will be listed. The listed keys will determine which encrypted files or directories you can access. Compare the user and group keys listed against the AIX file/directory ownership and permissions.

To add a group's key to a user's keystore, the following command must be executed by a user who has the Admin key loaded:

efskeymgr -k group/<group> -s user/<user>

Note that if the user hasn't yet logged into the system (after EFS was enabled), the keystore won't exist, and this command will fail.

Note also that the user still has to be added to the group via the normal OS mechanism (/etc/group).

Synchronized passwords

If you wish to de-synchronize your keystore password from your login password, or simply to change your keystore password, run the following command:

efskeymgr -n

Even with keystore passwords synchronized to user login passwords, your shell session does not automatically "load" your user's keys unless you've actually entered that password. In particular, if you authenticate via SSH keys, you'll have to explicitly load a new shell in a manner which forces you to enter your password. One way to do this, using the EFS commands, is:

efskeymgr -o ksh

You'll be prompted for the user's "EFS password", which in this case is simply the login password.

In the same manner, if you use "sudo su - " to switch to another user, you will not load that user's keys. But if you use "su - ", where you are forced to provide the user's password, you will load its keys. That is, you have to know a user's password if you want to act as that user and have access to its EFS files/directories. In particular, if you want to start a process which runs as that user and needs access to encrypted locations.

Note: based on this article which I've only recently seen and haven't yet fully parsed, those last two items may no longer be true starting with AIX 6.1 TL4.