Recommendations.

Some recommendations on security of the host, general operation, and key security.

Operation

Do not run two validator clients with the same validator keys imported at the same time
You'd get yourself slashed, and no-one wants that. Protecting you from this is a work in progress. Choose one client, and one client only, and run that.

Host Security

The bare metal installation guide by /u/SomerEsat has excellent notes on Linux host security. Running ntpd is highly recommended, time matters to validators. Note the ports you will need to open in ufw depend on the client you choose.

Firewalling

execution client: 30303 tcp/udp, forwarded to your server
consensus client: 9000 tcp/udp, forwarded to your server
grafana/web UI: 443 tcp, forwarded to your server, assuming you are using the reverse proxy.

The grafana port is insecure http:// if no reverse proxy is in use, and should then only be access locally. An SSH tunnel is also a great option if you do not want to use the reverse proxy.

Before depositing

You likely want to wait to deposit your ETH until you can see in the logs that the execution client (e.g. geth) is synchronized and the consensus client is fully synchronized. This takes hours on testnet and could take days on mainnet.

If you deposit before your client stack is fully synchronized and running, you risk getting penalized for being offline. The offline penalty during the first 5 months of mainnet will be roughly 0.13% of your deposit per week.

Wallet and key security

The security of the wallet mnemonic you create is critical. If it is compromised, you will lose your balance. Please make sure you understand Ethereum staking before you use this project.

When you create the deposit and keystore files, write down your wallet mnemonic and choose a cryptographically strong password for your keystores. Something long and not used anywhere else, ideally randomized by a generator.

The directory .eth/validator_keys will contain the deposit_data-TIMESTAMP.json and keystore-m_ID.json files created by staking-deposit-cli.

Use deposit_data-TIMESTAMP.json for your initial deposit. After that, it can be disposed of.

Use keystore-m_ID.json files to import your validator secret keys into the validator client instance of the client you are running. These files need to be secured when you are done with the initial import.

Validator Key Security

The keystore-m_ID.json files have to be stored securely outside of this server. Offline is best, on media that cannot be remotely compromised. Keep the password(s) for these files secure as well, for example in a local (not cloud-connected) password vault on a PC that is not on the network, or at the very least not used for online access.

Once you have the keystore files secure and they've been imported to the validator client container on your server, you should delete them from the .eth directory.

These files will be needed in case you need to restore your validator(s).

Caution
An attacker with access to these files could slash your validator(s) or threaten to slash your validator(s).

For more on validator key security, read this article: https://www.attestant.io/posts/protecting-validator-keys/

Withdrawal Key Security

Critical
When you ran staking-deposit-cli, a 24-word mnemonic was created. This mnemonic is used for Ethereum validator exits and withdrawals. It must be securely kept offline. Without this mnemonic, unless you set a withdrawal address via --execution_address, there is no way to withdraw your funds.

Precise methods are beyond this README, but consider something as simple as a sheet of paper kept in a fireproof envelope in a safe, or one of the steel mnemonic safeguards that are available.

Test your mnemonic before you deposit, so you know that you will be able to withdraw funds in future.

An attacker with access to your mnemonic can drain your funds, if no withdrawal address was set during key generation. If one was set, they can't get the validator funds, but can cause a "slashing", a penalty of around 1.1 ETH and forced exit of the validator.

For more on withdrawal key security, read this article: https://www.attestant.io/posts/protecting-withdrawal-keys/

Testing your mnemonic can be as simple as typing it into deposit-cli with existing-mnemonic, then comparing the public key(s) of the resulting keystore-m signing key files to the public keys you know your validator(s) to have. The safest way to do this is offline, on a machine that will never be connected to Internet and will be wiped after use.