概要 本节介绍如何在公共环境中和/或在众多 Cosmos SDK 公有区块链之一的主网上，安全地运行一个节点。
在生产环境中运行节点、全节点或验证者时，务必安全地配置服务器。本指南假设底层操作系统为 Ubuntu。保护服务器和节点的方法有很多种。此处描述的步骤仅供参考。

​
服务器设置

​
用户

创建服务器时，大多数情况下默认用户是 root。该用户在服务器上具有较高权限。运行节点时，建议不要使用 root 用户运行节点。
  1. 创建一个新用户
sudo adduser change_me
  1. 我们希望允许该用户执行 sudo 任务
sudo usermod -aG sudo change_me
现在登录服务器时，就可以使用非 root 用户。

​
Go

  1. 安装应用推荐的 Go 版本。
过去，验证者在使用不同 Go 版本时曾遇到问题。建议整个验证者集合都使用应用推荐的 Go 版本。

​
防火墙

节点不应将所有端口都暴露给公网；这会让你很容易遭受 DDoS 攻击。其次，CometBFT 也建议，绝不要暴露运行节点所不需要的端口。 配置防火墙时，运行 Cosmos SDK 节点有少量端口可以开放，包括 CometBFT JSON-RPC、Prometheus、p2p、远程签名器，以及 Cosmos SDK 的 gRPC 和 REST。如果该节点并不对外提供用于提交交易或查询的端点，那么最多只需要三个端点。 大多数服务器即使不是全部，也都预装了 ufw。本教程将使用 ufw。
  1. 重置 UFW，禁止所有入站连接并允许出站连接
sudo ufw default deny incoming
sudo ufw default allow outgoing
  1. 确保 22 端口（SSH）保持开放。
sudo ufw allow ssh
或 
sudo ufw allow 22
以上两条命令作用相同。
  1. 开放 26656 端口（CometBFT p2p 端口）。如果节点修改了 p2p 端口，则这里必须使用修改后的端口。
sudo ufw allow 26656/tcp
  1. 开放 26660 端口（CometBFT 的 Prometheus 端口）。该端口同时也是应用的监控端口。
sudo ufw allow 26660/tcp
  1. 如果正在配置的节点需要暴露 CometBFT 的 JSON-RPC 以及 Cosmos SDK 的 gRPC 和 REST，请执行此步骤。（可选）
CometBFT JSON-RPC
sudo ufw allow 26657/tcp
Cosmos SDK gRPC
sudo ufw allow 9090/tcp
Cosmos SDK REST
sudo ufw allow 1317/tcp
  1. 最后，启用 ufw
sudo ufw enable

​
签名

如果正在启动的节点是验证者，验证者可以通过多种方式对区块进行签名。

​
文件

基于文件的签名是最简单、也是默认的方式。该方式通过存储初始化时生成的共识密钥来对区块签名。它的安全性完全取决于你的服务器配置，因为一旦服务器被攻破，密钥也会随之泄露。该密钥文件位于初始化时生成的 config/priv_val_key.json。 还需要注意第二个文件；该文件位于数据目录 data/priv_val_state.json。此文件用于保护你的节点避免双重签名。它会记录共识密钥上一次签名的高度、轮次以及最新签名。如果节点崩溃后需要恢复，必须保留此文件，以确保不会使用该共识密钥再次签署一个此前已经签过的区块。

​
远程签名器

远程签名器是独立于运行中节点的第二台服务器，它使用共识密钥对区块签名。这意味着共识密钥并不存放在节点本机上。这样可以提升安全性，因为连接到远程签名器的全节点可以被替换，而不会漏签区块。 目前最常用的两个远程签名器是 Iqlusion 的 tmkms 和 Strangelove 的 horcrux。
TMKMS
依赖项
  1. 更新服务器依赖并安装所需的额外软件。
sudo apt update -y && sudo apt install build-essential curl jq -y
  1. 安装 Rust：
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
  1. 安装 Libusb：
sudo apt install libusb-1.0-0-dev
设置
安装 tmkms 有两种方式：从源码安装或使用 cargo install。以下示例将介绍如何下载或从源码构建，并使用 softsign。Softsign 表示软件签名；如果你愿意，也可以使用 yubihsm 作为签名密钥。
  1. 构建：
从源码： 
cd $HOME
git clone https://github.com/iqlusioninc/tmkms.git
cd $HOME/tmkms
cargo install tmkms --features=softsign
tmkms init config
tmkms softsign keygen ./config/secrets/secret_connection_key
或 使用 Cargo 安装： 
cargo install tmkms --features=softsign
tmkms init config
tmkms softsign keygen ./config/secrets/secret_connection_key
要让 tmkms 配合 yubikey 使用，请在安装二进制文件时加上 --features=yubihsm。
  1. 将验证者密钥从全节点迁移到新的 tmkms 实例。
scp [email protected]:~/.simd/config/priv_validator_key.json ~/tmkms/config/secrets
  1. 将验证者密钥导入 tmkms。
tmkms softsign import $HOME/tmkms/config/secrets/priv_validator_key.json $HOME/tmkms/config/secrets/priv_validator_key
此时，需要从验证者节点和 tmkms 节点中删除 priv_validator_key.json。由于该密钥已经导入 tmkms（见上文），节点上不再需要保留它。可以将该密钥安全地离线保存。
  1. 修改 tmkms.toml。
vim $HOME/tmkms/config/tmkms.toml
下面的示例展示了一个可用于 soft signing 的配置。示例中使用了 IP 123.456.12.345、端口 26659 和 chain_id test-chain-waSDSe。这些项目都必须根据 tmkms 的实际使用场景和网络进行修改。 
# CometBFT KMS configuration file

## Chain Configuration

[[chain]]
id = "osmosis-1"
key_format = { type = "bech32", account_key_prefix = "cosmospub", consensus_key_prefix = "cosmosvalconspub" }
state_file = "/root/tmkms/config/state/priv_validator_state.json"

## Signing Provider Configuration

### Software-based Signer Configuration

[[providers.softsign]]
chain_ids = ["test-chain-waSDSe"]
key_type = "consensus"
path = "/root/tmkms/config/secrets/priv_validator_key"

## Validator Configuration

[[validator]]
chain_id = "test-chain-waSDSe"
addr = "tcp://123.456.12.345:26659"
secret_key = "/root/tmkms/config/secrets/secret_connection_key"
protocol_version = "v0.34"
reconnect = true
  1. 设置 tmkms 实例的地址。
vim $HOME/.simd/config/config.toml

priv_validator_laddr = "tcp://0.0.0.0:26659"
上面的地址设置为 0.0.0.0，但建议将其设置为 tmkms 服务器地址，以提高安全性。
建议注释掉或删除用于指定验证者密钥和验证者状态文件路径的配置行：
# Path to the JSON file containing the private key to use as a validator in the consensus protocol
# priv_validator_key_file = "config/priv_validator_key.json"

# Path to the JSON file containing the last sign state of a validator
# priv_validator_state_file = "data/priv_validator_state.json"
  1. 启动这两个进程。
tmkms start -c $HOME/tmkms/config/tmkms.toml

simd start
Synopsis This section describes how to securely run a node in a public setting and/or on a mainnet on one of the many Cosmos SDK public blockchains.
When operating a node, full node, or validator in production it is important to set your server up securely.This walkthrough assumes the underlying operating system is Ubuntu.There are many different ways to secure a server and your node. The steps described here are for informational purposes only.

​
Server Setup

​
User

When creating a server most times it is created as user root. This user has heightened privileges on the server. When operating a node, it is recommended to not run your node as the root user.
  1. Create a new user
sudo adduser change_me
  1. We want to allow this user to perform sudo tasks
sudo usermod -aG sudo change_me
Now when logging into the server, the non root user can be used.

​
Go

  1. Install the Go version recommended by the application.
In the past, validators have had issues when using different versions of Go. It is recommended that the whole validator set uses the version of Go that is recommended by the application.

​
Firewall

Nodes should not have all ports open to the public; this is a simple way to get DDoS’d. Secondly, it is recommended by CometBFT to never expose ports that are not required to operate a node. When setting up a firewall, there are a few ports that can be open when operating a Cosmos SDK node. These include the CometBFT JSON-RPC, Prometheus, p2p, remote signer, and Cosmos SDK gRPC and REST. If the node is being operated as a node that does not offer endpoints to be used for submission or querying, then a maximum of three endpoints are needed. Most, if not all servers come equipped with ufw. Ufw will be used in this tutorial.
  1. Reset UFW to disallow all incoming connections and allow outgoing
sudo ufw default deny incoming
sudo ufw default allow outgoing
  1. Let’s make sure that port 22 (SSH) stays open.
sudo ufw allow ssh
or 
sudo ufw allow 22
Both of the above commands are the same.
  1. Allow Port 26656 (cometbft p2p port). If the node has a modified p2p port then that port must be used here.
sudo ufw allow 26656/tcp
  1. Allow port 26660 (CometBFT Prometheus). This acts as the application’s monitoring port as well.
sudo ufw allow 26660/tcp
  1. If the node which is being set up would like to expose CometBFT’s JSON-RPC and Cosmos SDK gRPC and REST, then follow this step. (Optional)
CometBFT JSON-RPC
sudo ufw allow 26657/tcp
Cosmos SDK gRPC
sudo ufw allow 9090/tcp
Cosmos SDK REST
sudo ufw allow 1317/tcp
  1. Lastly, enable ufw
sudo ufw enable

​
Signing

If the node that is being started is a validator there are multiple ways a validator could sign blocks.

​
File

File-based signing is the simplest and default approach. This approach works by storing the consensus key generated on initialization to sign blocks. This approach is only as safe as your server setup, as if the server is compromised, so is your key. This key is located in the config/priv_val_key.json directory generated on initialization. A second file exists that users must be aware of; the file is located in the data directory data/priv_val_state.json. This file protects your node from double signing. It keeps track of the consensus key’s last sign height, round, and latest signature. If the node crashes and needs to be recovered, this file must be kept in order to ensure that the consensus key will not be used for signing a block that was previously signed.

​
Remote Signer

A remote signer is a secondary server that is separate from the running node that signs blocks with the consensus key. This means that the consensus key does not live on the node itself. This increases security because your full node which is connected to the remote signer can be swapped without missing blocks. The two most used remote signers are tmkms from Iqlusion and horcrux from Strangelove.
TMKMS
Dependencies
  1. Update server dependencies and install extras needed.
sudo apt update -y && sudo apt install build-essential curl jq -y
  1. Install Rust:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
  1. Install Libusb:
sudo apt install libusb-1.0-0-dev
Setup
There are two ways to install tmkms, from source or cargo install. In the examples we will cover downloading or building from source and using softsign. Softsign stands for software signing, but you could use a yubihsm as your signing key if you wish.
  1. Build:
From source: 
cd $HOME
git clone https://github.com/iqlusioninc/tmkms.git
cd $HOME/tmkms
cargo install tmkms --features=softsign
tmkms init config
tmkms softsign keygen ./config/secrets/secret_connection_key
or Cargo install: 
cargo install tmkms --features=softsign
tmkms init config
tmkms softsign keygen ./config/secrets/secret_connection_key
To use tmkms with a yubikey install the binary with --features=yubihsm.
  1. Migrate the validator key from the full node to the new tmkms instance.
scp [email protected]:~/.simd/config/priv_validator_key.json ~/tmkms/config/secrets
  1. Import the validator key into tmkms.
tmkms softsign import $HOME/tmkms/config/secrets/priv_validator_key.json $HOME/tmkms/config/secrets/priv_validator_key
At this point, it is necessary to delete the priv_validator_key.json from the validator node and the tmkms node. Since the key has been imported into tmkms (above) it is no longer necessary on the nodes. The key can be safely stored offline.
  1. Modify the tmkms.toml.
vim $HOME/tmkms/config/tmkms.toml
This example shows a configuration that could be used for soft signing. The example has an IP of 123.456.12.345 with a port of 26659 and a chain_id of test-chain-waSDSe. These are items that must be modified for the use case of tmkms and the network. 
# CometBFT KMS configuration file

## Chain Configuration

[[chain]]
id = "osmosis-1"
key_format = { type = "bech32", account_key_prefix = "cosmospub", consensus_key_prefix = "cosmosvalconspub" }
state_file = "/root/tmkms/config/state/priv_validator_state.json"

## Signing Provider Configuration

### Software-based Signer Configuration

[[providers.softsign]]
chain_ids = ["test-chain-waSDSe"]
key_type = "consensus"
path = "/root/tmkms/config/secrets/priv_validator_key"

## Validator Configuration

[[validator]]
chain_id = "test-chain-waSDSe"
addr = "tcp://123.456.12.345:26659"
secret_key = "/root/tmkms/config/secrets/secret_connection_key"
protocol_version = "v0.34"
reconnect = true
  1. Set the address of the tmkms instance.
vim $HOME/.simd/config/config.toml

priv_validator_laddr = "tcp://0.0.0.0:26659"
The above address is set to 0.0.0.0, but it is recommended to set the tmkms server address to secure the startup.
It is recommended to comment or delete the lines that specify the path of the validator key and validator:
# Path to the JSON file containing the private key to use as a validator in the consensus protocol
# priv_validator_key_file = "config/priv_validator_key.json"

# Path to the JSON file containing the last sign state of a validator
# priv_validator_state_file = "data/priv_validator_state.json"
  1. Start the two processes.
tmkms start -c $HOME/tmkms/config/tmkms.toml

simd start