This shows you the differences between two versions of the page.
|
internal:ssh [2012/04/26 02:22] magnum Corrected GPG signing and added ~/ to .ssh path |
internal:ssh [2023/08/03 20:56] (current) solar added "Status of this wiki page" |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== SSH (Secure Shell) usage policies, as well as tips & tricks ====== | ====== SSH (Secure Shell) usage policies, as well as tips & tricks ====== | ||
| + | |||
| + | ===== Status of this wiki page ===== | ||
| + | |||
| + | 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. | ||
| ===== How to generate key pairs for use with public key authentication ===== | ===== How to generate key pairs for use with public key authentication ===== | ||
| - | The current "Openwall standard" is to use SSH-2 2048-bit RSA keys. These may be generated with ssh-keygen(1) from OpenSSH as follows: | + | 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 2048 -C TARGET-NICK -f ~/.ssh/identity.TARGET | + | 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). | 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). | ||
| Line 14: | Line 18: | ||
| This will create a "detached signature" - a separate file with just the signature. | This will create a "detached signature" - a separate file with just the signature. | ||
| - | |||
| - | SSH protocol 1 (and thus SSH-1 keys) is also acceptable - especially for low bandwidth links (GPRS, dialup, etc.) or when paying for the data transferred. SSH protocol 1 has significantly lower traffic overhead. You will also want to enable data compression (with either protocol). | ||
| 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. | 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. | ||
| Line 25: | Line 27: | ||
| 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). | 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). | ||
| - | 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: | + | 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: |
| <code> | <code> | ||
| Line 50: | Line 52: | ||
| 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). | 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, [[https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts#Passing_Through_One_or_More_Gateways_Using_ProxyJump|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. | ||