This wiki page used to describe Openwall sysadmin team's conventions from circa 2010 and is mostly not being updated since then. Then content is still relevant, but is missing proper references to recent OpenSSH versions' additions such as Ed25519 and bcrypt_pbkdf.
The current “Openwall standard” is to use SSH-2 4096-bit RSA keys. These may be generated with ssh-keygen(1) from OpenSSH as follows:
ssh-keygen -t rsa -b 4096 -C TARGET-NICK -f ~/.ssh/identity.TARGET
where TARGET is a short name (identifier) for the “target” company/network/project that this key is intended for, and NICK is your “nickname” (e.g., your typical login name). Setting the comment in this way is both informative for us and not too revealing for someone malicious (specifically, it does not reveal what host you have generated and maybe still keep the corresponding private key on).
If you have a PGP/GnuPG keypair, you may sign your newly generated public key such that we can verify that it is really yours:
gpg -ba ~/.ssh/identity.TARGET.pub
This will create a “detached signature” - a separate file with just the signature.
Our preference is to use separate key pairs, each with its distinct passphrase on the private key, for different “targets”. For example, if you already use an SSH keypair and you start to work at Openwall, we ask you to generate a new keypair for use at Openwall only.
We ask that you pick a good passphrase for each of your SSH private keys. Unfortunately, it is possible to test candidate passphrases against an SSH private key at a rate much higher than that for decent Unix password hashes such as bcrypt. For this reason, the very minimum is an uncommon combination of three words (preferably misspelled), not something you would find in a piece of text, separated by weird punctuation or digits; 4+ words (also with additional weirdness) is much better.
Sometimes you will need to SSH into a server that cannot be reached directly, but can be reached via an intermediary server. We have a policy to avoid cross-server logins (which would allow for a possible compromise to propagate), so running the SSH client on the intermediary server would be inappropriate. Some guides on the Internet recommend the use of ssh-agent(1) on the intermediary server for this, but unfortunately it is similarly risky (it does save you from having to upload your private key, but other than that it does not achieve end-to-end encryption and it lets a possible compromise propagate).
Historically, the only approach allowed at Openwall is to use SSH over SSH-port-forwarding, which achieves end-to-end encryption and avoids the compromise propagation risk (well, as long as you have previously accepted and let your SSH client verify the ultimate target server's SSH host key). To use it, you may put host entries like the following into your ~/.ssh/config file:
Host intermediate
Hostname intermediate.target.tld
RSAAuthentication yes
IdentityFile ~/.ssh/identity.target-network
Host ultimate-target
HostKeyAlias ultimate-target
Hostname localhost
Port 9001
RSAAuthentication yes
IdentityFile ~/.ssh/identity.target-network
Then you'll run two commands, in separate pseudo-terminal windows:
ssh username@intermediate -vCL 9001:ultimate-target:22
ssh -vC username@ultimate-target
The HostKeyAlias directive ensures that the ultimate target's host key will be stored in ~/.ssh/known_hosts under that name rather than for “localhost”. Thus, this approach can be used for multiple “unreachable” servers without having their host keys clash in your ~/.ssh/known_hosts file.
Please note that the ultimate target's hostname given in the first SSH command must be spelled the way it will resolve on the intermediate server (or you may indeed specify an IP address for greater assurance).
With newer versions of OpenSSH and/or with nc (netcat, ncat) available on intermediate hosts, the ProxyJump or ProxyCommand directive may be used. ProxyJump requires OpenSSH 7.3+, and ProxyCommand requires either OpenSSH 5.4+ or nc on intermediate hosts.