编注：本文入选「自力更生」征文活动。本次征文选题灵活，只要围绕「自托管」展开即可，软件推荐、经验分享、技术科普、观点评论均可投稿，6 月 23 日前发布投稿文章即可。入围作品均可获得稿酬、Zearbur 订阅、少数派 PRIME 会员等奖励。了解详情

前言

在互联网设施日益发达的今天，绝大多数互联网服务对我们来说都触手可及，云存储服务、流媒体服务，等等等等。但是随着时间的推移，我们似乎陷入了一个怪圈：

在一项服务开放初期，这些服务背后的商业公司们，往往会花大力气改善用户体验，从而吸引更多的用户，而更多的用户，就意味着赚更多的钱；而当用户量接近饱和，已经有了相当大一部分高粘性用户时，这些商业公司基本就不在乎用户体验了。为什么？因为它们的根本目标并不是用户，而是赚钱，当所有人都不得不用你的东西，可以躺着赚钱时，为什么还要在乎用户体验呢？

这么看来，科幻设定中「高科技，低生活」的赛博朋克世界似乎已经离我们不远了。而在这样的世界中，学会如何自力更生，通过自建服务，守护自己的一片互联网净土，似乎变得越来越重要了，在这篇文章中，我会介绍一下我个人在使用的自建服务，以及相关的配置思路。

安全配置

如果需要将自己的自建服务暴露到公网，安全性是尤为需要关心的，如果服务器被黑，轻则引入恶意程序，重则泄露重要数据，造成重大财产损失，所以在介绍自建服务之前，我要先介绍一下我个人针对大多数 Linux 发行版推荐的安全性设置。

定期更新系统

对于需要长期运行的服务器，很多人大概配置好自己所需的服务后就基本不管了，甚至可能几个月乃至几年都不更新，这其实是一种很危险的行为。

服务器用途的发行版，比如 RHEL 和 Debian，在一个大版本周期内虽然基本不会有功能性更新，但是会定期推送安全性更新从而修复已知的安全漏洞，另外对于一些较严重的突发性漏洞，比如前段时间的 xz 后门事件和更早的 log4j 漏洞，发行版的维护者也会第一时间推送修复补丁。而如果不进行更新，放任这些漏洞不管，就很有可能导致服务器被黑。

所以即使服务器稳定运行没出差错，也要记得定期登录查看一下，并检查一下有无更新可用，如果发现网上爆出了某个软件包出现了严重的安全漏洞，更要紧急检查一下自己的服务器是否有问题。

防火墙配置

对于暴露在公网的服务器，防火墙配置是尤为重要的，没有防火墙的服务器，就犹如没上锁的保险箱，小偷来去自如。

我个人比较习惯使用 ufw 作为防火墙软件，ufw 全称是「Uncomplicated Firewall」，即并不复杂的防火墙，其实际的使用方法也很简单，ufw 存在于几乎所有 Linux 发行版的官方软件仓库中，直接用系统包管理器就可以安装，安装后需要进行一些基本设置：

# 以下命令需要以 root 权限运行
sudo systemctl enable ufw   # 让 ufw 服务开机自启
sudo ufw default deny       # 默认阻止所有端口的出站流量
sudo ufw allow ports        # 放行必要端口，ports 改为需要的端口
sudo ufw enable             # 启用 ufw

ufw 默认支持 ipv4 和 ipv6，如果你的服务器没有 ipv6 地址，可以选择禁用 ipv6 支持，编辑 /etc/default/ufw，找到 IPV6=yes 这一行，改成 IPV6=no，然后重启 ufw 服务即可。

也可以选择禁用 icmp 流量，这样其他 ip 就没办法 ping 通服务器，编辑 /etc/ufw/before.rules 文件，找到以下内容，把 ACCEPT 改成 DROP：

# ok icmp codes
...
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

如果要用到 ipv6，记得要一并修改 /etc/ufw/before6.rules 文件。修改完后重启 ufw 服务即可。

以下是一些 ufw 的基本用法。

放行或阻止特定端口：

sudo ufw allow 80       # 放行 80 端口
sudo ufw deny 443       # 阻止 443 端口
sudo ufw limit 22       # 放行 22 端口，但限制连接数

其中 limit 命令会限制端口的连接数，如果一个 ip 在过去 30 秒内有超过 6 次连接就会被拒绝，比较适合用于 ssh 端口

查看当前创建的规则：

# sudo ufw status

Status: active
To                         Action      From
--                         ------      ----
80                         ALLOW       Anywhere
443                        DENY        Anywhere
22                         LIMIT       Anywhere

或者查看规则的同时显示序号：

# sudo ufw status numbered

Status: active
     To                         Action      From
     --                         ------      ----
[ 1] 80                         ALLOW       Anywhere
[ 2] 443                        DENY        Anywhere
[ 3] 22                         LIMIT       Anywhere

删除已经添加的规则：

sudo ufw delete deny 443    # 按规则名删除
sudo ufw delete 2           # 或者按序号删除，这里就是删除上面的 deny 443 规则

不过需要注意的是，在使用 ufw 的同时使用 Docker，ufw 可能会无法管理 Docker 开放出来的端口，导致安全问题，为了解决这个问题，需要进行一些额外配置，具体可以参考 这个 Github 项目，同时这个项目还提供了一键配置脚本，直接运行即可。

关于更多 ufw 的高级用法，可以查看 ArchWiki 或 Ubuntu 相关文档。

用户与权限

无论是在服务器还是个人电脑上运行的 Linux 系统，使用 root 用户裸奔都是十分不好的行为，推荐的做法是创建一个有 sudo 权限的普通用户，平时以普通用户登陆，需要用 root 权限时用 sudo 进行提权。关于如何创建新用户并赋予 sudo 权限，各大主流发行版都不太相同，具体可以查看对应发行版的文档。

另外还比较推荐禁用 root 账户，运行 sudo passwd -l root 便可禁用 root 账户，之后即使输入了正确的 root 密码也无法登入账户。若是有特殊情况需要登陆 root 账户的话，运行 sudo passwd -u root 便可解锁。

SSH 安全配置

注：本节内容假定读者除了远程服务器外，本地还有一个运行着 Linux 的 PC，也可以是 WSL 或虚拟机，其中的命令行操作需要频繁切换服务器和本地 Linux PC，为了防止混淆，我会在每个代码块前进行标注。

SSH 服务默认使用 22 端口，并且允许密码登陆，这是一个非常大的安全隐患，比较推荐的 SSH 登陆方式是使用五位数以上的不常用端口，禁用 root 用户登陆，并使用密钥登陆。

首先禁用 root 账户登录，先确认用普通账户可以正常登陆 SSH，然后编辑 /etc/ssh/sshd_config 文件，里面大部分选项都是注释掉的，我们要做的就是找到对应的配置项删掉井号注释并修改，找到 PermitRootLogin 一行，改为 PermitRootLogin no ，重启 sshd 服务即可。

之后修改 SSH 服务端口，同样编辑 /etc/ssh/sshd_config 文件，找到 PORT 22 一行，如果有井号注释就删掉井号，把端口号改成其他端口号。为了防止 SSH 登陆不上，我个人比较推荐先不要改 PORT 22，而是在后面另起一行添加自己想要的端口，比如 PORT 27032，SSH 服务是支持同时开多个端口的，重启 sshd 服务，记得添加对应的防火墙规则，然后尝试用新添加的端口登陆 SSH，确认能正常登陆后，再把前面的 22 端口删掉。

最后是使用密钥登陆，这一部分比较复杂，首先需要创建 ssh 密钥对，如果已经有了可以跳过这一步。

在本地电脑的 Linux PC 上（在服务器上也应该可行，但需要把公钥和私钥拷贝回本地电脑），需要安装 openssh，应该几乎所有发行版都是预装了的，之后运行：

# 本地 Linux PC
ssh-keygen -t rsa

会以 rsa 算法生成一个新的 ssh 密钥对，会提示让输入密码，切记输入的密码之后不要忘记或泄露，也可以直接回车设置空密码，之后会在当前用户家目录的 .ssh 目录下生成两个文件，id_rsa 是私钥文件，要自己保存好，千万不能泄露，id_rsa.pub 是公钥文件，是需要复制到服务器上的。

为了更进一步的安全，也可以选择更改 .ssh 文件夹的访问权限：

# 本地 Linux PC
chmod 700 ~/.ssh                # 仅当前用户可读写
chmod 600 ~/.ssh/id_rsa         # 仅当前用户可读写
chmod 644 ~/.ssh/id_rsa.pub     # 当前用户可读写，其他用户可读

之后需要将公钥复制到服务器上，有两种方法，自动和手动。

自动方法是在本地电脑的 Linux 终端 中，运行

# 本地 Linux PC
ssh-copy-id -p port username@ip

其中 port 改为 SSH 开放的端口，username 改为服务器用户名，ip 改为服务器 ip 地址，之后根据提示输入服务器用户的密码，便可以自动将公钥复制到服务器上了。

手动方法是用文本编辑器打开 id_rsa.pub 文件，复制其中的内容，登陆到服务器，在服务器当前用户家目录下的 .ssh 文件夹中新建一个 authorized_keys 文本文件，之后将公钥文件中的内容粘贴到其中。

为了安全起见也可以修改一下对应文件的权限：

# 远程服务器
chmod 600 ~/.ssh/authorized_keys

之后尝试登录服务器，在本地电脑的 Linux 终端中，直接运行

# 本地 Linux PC
ssh -p port username@ip

或是在 putty 这类 ssh 客户端中指定刚刚创建的 id_rsa 私钥。如果创建密钥对时设置了密码，则需要输入密钥对的密码，注意是密钥对的密码，不是服务器用户的密码；若是没有设置密码，则会直接登陆到服务器。

在确认可以正常使用密钥登陆服务器后，可以选择禁用服务器的密码登陆，编辑 /etc/ssh/sshd_config，修改配置项 PasswordAuthentication no，之后重启 sshd 服务。

自建服务介绍

关于如何部署

目前我的大部分自建服务都是运行在一个位于香港的云服务器上，小部分是运行在我本地局域网内的 PC 上。

至于使用何种方式部署服务，一开始我是比较抗拒使用容器化的方式来进行部署的，主要有以下两个原因：

docker cli 命令太过于冗长，在创建一个新容器时，往往需要输入又臭又长的参数来指定容器的行为，如果哪里出了差错，就要停止并删除容器，将那长长的命令再重新输入一遍，就仿佛奇幻文学作品中的法师在施法前都要进行冗长的吟唱一样；

消耗更多存储空间与服务器资源，一个现成的容器镜像需要打包程序本体和程序所有需要的依赖库，虽然一处编译处处运行的思路确实方便了部署，但如果多个容器有相同的依赖项，那就会占用多份的空间。另外容器化运行相较于原生运行难免会效率更低，更有可能会占用更多的 CPU 与内存资源。这对于可用资源本来就比较紧张的云服务器来说是个比较大的痛点。

但直接运行原生程序的话也存在着很多问题：

运行原生程序需要解决依赖问题，遇到依赖冲突那就是心肺骤停；

对于常用于服务器的发行版，比如 Debian，其官方的软件仓库版本较老，要安装较新版本的程序，需要添加第三方源或或进行手动安装，往往就会导致配置文件散落在系统各个角落，且后期程序版本更新较麻烦；

很多项目只提供了使用 docker 部署的方法，使用其他方式部署不被支持。

不过现在我逐渐接受了容器化部署的方式。主要是因为我了解到了 docker-compose，相比于 docker cli 需要输入长串命令，docker-compose 将容器的配置保存在 docker-compose.yml 文件中，一个个 docker-compose.yml 文件便抽象为了一个个服务，在 docker-compose.yml 文件所在的目录运行 docker compose up -d（如果是 v1 版本的 docker-compose，需要运行 docker-compose up -d ）便可直接启动容器，省去了重复输入长串命令的麻烦。而且 docker-compose 还支持将多个容器的配置写入一个 YAML 文件，使多个容器作为一个服务运行，这样多个容器就会在同一个虚拟网络下，容器间只需使用容器名当作互联网主机名便可相互通讯。关于占用更多资源的问题，我特意对比过，相比于直接在宿主机上原生运行，容器化运行时额外占用的内存与 CPU 资源可以忽略不计，甚至有些镜像因为专门为容器环境优化过，内存占用反而更少。存储空间问题，至少目前我的服务器存储空间还很够用，等不够用了再说吧🤣。

自建服务选择

借着写这次文章的机会，我顺便把我大部分自建服务的配置都整理了一下，放在了 github 上，感兴趣的朋友可以抄下作业。

其中有些服务所需的配置较为复杂，由于文章篇幅原因不能详细介绍，更多的教程与配置还是建议查看项目的官方文档。

Web 服务器

如果需要将自建的服务开放到公网，或是搭建自己的博客网站，一个 Web 服务器软件是必不可少的，为了安全起见还需要配置好 SSL 证书。我选择使用的 Web 服务器是 Caddy，为什么选择它而不是其他老牌的软件如 NGNIX 和 Apache，主要有以下几点原因：

支持自动申请以及续签 SSL 证书，想要使用 HTTPS 加密网页传输，就需要申请 SSL 证书，获取 SSL 证书最简单的途径是 Let's Encrypt 的免费证书，但从 Lets's Encrypt 申请到的证书一次性最长时效只有三个月，虽然可以无限续签，但每次要手动续签还是挺麻烦的，而 Caddy 不但支持自动申请 SSL 证书，而且还可以在证书到期前自动续签证书，免去了手动申请并续签的麻烦，所要做的就只有把自己的邮箱填到配置文件里就好；

配置文件相对简单易懂，我个人其实并不精通 Web 服务的搭建，其他的工具如 NGNIX 和 Apache 的配置对我来说都有点复杂，而 Caddy 支持多种配置文件格式，最简单易懂的配置文件格式就是 Caddyfile，能够相对简单地配置反向代理与静态站点，对我来说已经够用了。

部署方面，我使用了 Docker Hub 上的官方镜像，配置文件在这里。

DNS 服务

AdGuardHome 是知名去广告软件 AdGuard 团队开发的一个开源项目，主要功能是以 DNS 过滤的方式来去广告。不过它吸引我的并不是去广告功能，而是 DNS 协议支持，它是我已知的目前支持 DNS 协议最全，配置最简单的 DNS 服务器。

在上游 DNS 协议支持方面，除了常规的 53 端口非加密 DNS 协议，它还支持绝大多数主流加密 DNS 协议，比如 DNS-over-TLS 和 DNSCrypt，甚至包括目前非常新的 DNS-over-QUIC 和 HTTP3 的 DNS-over-HTTPS，除此之外它还可以支持作为 DoT、DoH 或 DoQ 服务器来提供加密 DNS 服务。

我目前的主要用法是对 dnsmasq-china-list 中的国内域名进行分流，国内域名使用国内速度较快的公共 DNS 服务器作为上游加快解析，其他域名使用国外公共加密 DNS 服务器作为上游确保返回正确的查询结果，同时配置好 DoH 和 DoT 服务器，防止本地运营商对查询结果进行污染。

在部署方面这是我为数不多还没有迁移到容器化部署的服务了，目前我是从 Github Releases 下载安装包并手动安装的，不过好在安装过程不复杂，后续更新也只需在网页端操作就行，具体的安装与配置可以参考官方的 wiki。

密码管理器

密码是网络数据安全中最容易被攻破的一环，所以如何安全妥善地保存各个平台的账号与密码显得尤为重要，这时就需要密码管理器了，Bitwarden 就是一个开源免费可自建的密码管理器服务，至于 Bitwarden 是什么以及怎么用，相信绝大部分人已经十分熟悉，少数派站内也有很多相关文章，我这里就不啰嗦了，下面主要讲一下我的部署思路。

Bitwarden 官方的服务端对服务器配置要求较高，且部署较麻烦，所以大部分人自建时都会选择使用第三方的 Vaultwarden 服务端，除了服务端本体，我还配置了自动备份 Vaultwarden 的数据，关于具体如何备份可以参考这里，我使用的是 bruceforce/vaultwarden-backup 这个镜像，不但可以设置自动备份，还可以设置使用 gpg 加密，提高了安全性，关于 gpg 加密的具体操作可以参考接下来的备份与加密部分。配置文件在这里。

搜索引擎

关于搜索引擎的选择我曾经纠结了很久，各个大厂的搜索引擎多多少少都有广告和隐私问题，而一些标榜隐私友好的引擎如 DuckDuckGo 和 Brave Search 在搜索结果方面又多多少少不尽人意。那有什么办法能够保证大厂引擎优秀的搜索结果的同时还能保护隐私呢，还真有，就是「自建」搜索引擎，与其说是「自建」，到更像是「代理」，最有名的项目应该就是 SearX 和 SearXNG 了，这类服务充当一个中间人的角色，从其他现成的搜索引擎中获取搜索结果返回给我们，同时确保隐私信息不被泄露。

SearX 和 SearXNG 功能很是强大，可以聚合几十个不同搜索引擎的结果，还可以根据自己的需要进行自定义，但功能强大带来的后果是配置过于复杂，运行起来也过于消耗资源。我尝试过部署，但都因为配置太复杂，内存占用太多，最后放弃。对我来说，Google 的搜索结果已经足够好，我只是不想把我搜索历史交给 Google，最后我发现了 Whoogle-Search 这个项目，它的功能和 SearX 差不多，但是要简单不少，它只能代理 Google 的搜索结果，正因如此，它配置起来更加简单，运行起来也更轻量。

它部署起来也很简单，直接抄官方的 docker-compose.yml 文件就行，它所有的配置都是通过环境变量完成的，具体的配置项可以看这里，我的配置在这里，主要是改了个我喜欢的 Gruvbox 主题配色。

RSS 服务

在这个 RSS 已经逐渐被大多数人遗忘的时代，越来越多的网站已经不支持 RSS 订阅，知名的 RSS 转换工具 RSSHub 在最近的一次重构后可用的路由似乎也少了很多。但对于互联网遗老们来说，RSS 仍然是不可或缺的一个工具，用以对抗大数据推送与信息茧房。

虽然市面上有一些现成的 RSS 服务在坚持运营，或者也可以直接使用 RSS 阅读器本地订阅，我个人还是比较倾向于自建服务，我选择使用 FreshRSS 来自建 RSS 服务。

FreshRSS 是一个开源免费可自建的 RSS 聚合服务端，兼容常用的 API，可以配合自己喜欢的阅读器来使用，还支持使用扩展进一步自定义使用体验。

在部署思路方面，我将 FreshRSS 与 RSSHub 配合使用，写入一个 docker-compose.yml，因为只有 FreshRSS 需要访问 RSSHub，所以 RSSHub 没有开放外部端口，在 FreshRSS 中需要订阅 RSSHub 路由时，只需使用 http://rsshub:1200 加对应路由便可直接订阅，唯一有点不方便的就是 RSSHub 路由没办法验证订阅源有效性了。配置文件在这里。

追剧自动化

我在之前的文章提到我买了一个 ROG Ally 掌机，并装上了 Linux 系统，目前我在使用的系统是 Bazzite，一个基于 Fedora Silverblue 的不可变系统。ROG Ally 有着十分不错的屏幕与音响，所以在游戏之余也挺适合用来追剧观影的，安装 Kodi 并加入到游戏模式后使用体验也很不错，甚至手柄支持都很完美。所以我需要一套服务来自动化我的追剧和观影流程，我选择使用 sonarr 与 Radarr 来自动化剧集与电影下载。

Sonarr 是一个自动化的剧集监控与下载服务，添加想要观看的剧集后便可自动按照指定的视频质量从互联网获取并下载剧集，而且还可以自动整理好媒体文件，并提供其他媒体播放器如 kodi 和 emby 可以读取的元数据，真正实现了一键追剧；Radarr 是 Sonarr 的一个 Fork，与 Sonarr 的主要区别是 Radarr 主要用于下载电影，其他功能大同小异。

由于 Bazzite 是不可变操作系统，其大部分系统根目录是不可修改的，所以无法直接部署服务，也无法安装 Docker。不过 Bazzite 预装了 Podman，也可以用于部署容器，Podman 在用法上兼容 Docker，甚至可以直接将 podman 命令 alias 成 docker 来使用，不过 Podman 也有一些自己独有的功能，比如 rootless 模式和 Quadlet，我的部署便是使用了 Quadlet。

Quadlet 允许使用 systemd 来管理 podman 容器，具体到本次的部署，只需将编辑好的 *.container 文件放入 /etc/container/systemd，之后运行 sudo systemctl daemon-reload 重新加载服务列表，便可将对应的容器作为 systemd 服务来管理，比如 sonarr 的配置文件是 sonarr-lsio.container，那它对应的 systemd 服务便是 sonarr-lsio.service。不过需要注意的是，这种方法生成的 systemd 服务无法 enable 或 disable，默认就是 enable 开机自启状态，如果不想它开机自启，就需要删掉对应配置文件最后两行 [Install] 部分。

我的配置文件在这里，Sonarr 和 Radarr 自身并没有下载功能，需要额外配置下载客户端，我这里使用了 Qbittorrent 作为下载客户端。Sonarr 和 Radarr 需要一些配置才可以正常使用，具体可参考官方文档，以及推荐看一下一个第三方的教程 TRaSH-Guides，对一些细节的配置有更详尽的介绍，特别是这篇硬链接教程，最好参照这篇教程来配置容器的文件系统映射。

Sonarr 和 Radarr 默认提供了一些下载站点作为下载源，但有时这些下载源不满足我们的要求，那这时就需要 Jackett 了，Jackett 支持上百个种子站点，其中包括很多较大的 PT 站，可以将其配置给 Sonarr 和 Radarr 使用。

因为有些站点存在人机验证，直接使用 Jackett 可能会无法连接，所以还需要结合 FlareSolverr 来使用，它的大概原理是运行一个 Chrome 客户端来模拟真实流量，从而「骗过」某些站点的人机验证。

可能是因为本地运营商的原因，我在本地的部署 Jackett 时，无论是否配置了 FlareSolverr，很多站点都无法连接，所以我最后选择把 Jackett 部署在了云服务器上，然后使用 Caddy 方向代理开放到公网。配置文件在这里，我将 Jackett 和 FlareSolverr 放在了一个 docker-compose.yml 里面，要使用 FlareSolverr，需要在 Jackett 设置里将 FlareSolverr API URL 设置为 http://flaresolverr:8191。关于如何在 Sonarr 和 Radarr 里面使用 Jackett，可以参考这里。

备份与加密

备份思路

为了防止数据丢失，同时方便日后迁移服务器时重新部署，数据备份是很重要的，对我来说真正需要定期备份只有 Vaultwarden 和 FreshRSS 的数据了，其他的只需偶尔手动备份一下即可。

对于 Vaultwarden 我前面提到了我使用这个项目来实现自动备份。而 FreshRSS，参考官方文档，其实也只需将数据文件夹打包即可。真正需考虑的是备份文件要放到哪里，参考数据安全的 「3、2、1」原则，即至少需要三份副本，两处存储媒介，以及一个异地备份，我打算将我的备份文件上传到公有云，我选择了使用坚果云，主要是因为它支持 WebDAV，可以使用 Rclone 来方便地进行同步，我需要备份的文件并不大，即使设置定时任务每天备份一次，免费版的上传流量也绰绰有余。

加密思路

但无论哪家的公有云，其安全性我都不太放心，更不用提 Vaultwarden 和 FreshRSS 的备份文件中包含敏感数据，我是不太放心就这样上传到公有云上的，所以在上传之前需要进行加密。

加密方式我选择使用 gpg 非对称加密，这种加密方式理论上只要私钥与私钥的密码没有泄露，第三方几乎不可能解密数据。

创建密钥对

要想使用 gpg 加密，首先需要创建一个密钥对，在本地电脑上需要安装 GnuPG 软件包，大多数 Linux 系统应该已经预装了，然后运行：

gpg --full-gen-key

之后会提示回答几项问题：

密钥类型，较新版本的 GnuPG 默认是 (9) ECC（签名和加密），但较旧版本的 GnuPG 默认是 (1) RSA 和 RSA，为了兼容性考虑，还是推荐选 RSA；

密钥长度，默认 3072 即可；

过期时间，按需选择，大部分情况可以选择一年，之后也可以在到期前延长时间，如果嫌麻烦，也可以直接选永不过期；

用户名和电子邮件，按需填写；

注释，可填可不填；

密钥口令，设置一个安全的密码，不能泄露或遗忘。

之后便可创建一个新的密钥对了，密钥对分为公钥和私钥，公钥可以随便分享给他人，私钥与私钥的密码则绝对不可以泄露。

之后导出公钥：

gpg --export --armor --output public-key.asc user-id

其中 user-id 需要改成之前创建的密钥对的用户名，公钥就会导出为名为 public-key.asc 的文件。关于更多密钥对管理相关文档，可以看这里。

加密文件

之后便是使用密钥加密文件，将公钥文件复制到需要加密文件的服务器上，然后导入公钥：

gpg --import public-key.asc

其中 public-key.asc 为之前导出的公钥文件。

然后加密文件：

gpg --recipient user-id --encrypt filename

其中 user-id 需要改成要发送的人的用户名，在这里也就是刚刚创建的密钥对的用户名，filename 需要改成你想要加密的文件路径，之后便会生成一个和文件同名但以 .gpg 结尾的文件，这就是加密后的文件，为了安全起见，可以将未加密的文件删除。

而 vaultwarden-backup 这个项目支持使用 gpg 公钥直接加密文件，只需在环境变量中指定 gpg 公钥内容即可，运行 base64 -w 0 public-key.asc 可将公钥文件转换为 base64 格式，复制 base64 内容，然后在容器中添加环境变量 ENCRYPTION_BASE64_GPG_KEY 并把值设定为刚刚复制的内容即可。

我写了一个简单的脚本，每天凌晨定时执行，将 FreshRSS 的数据备份并加密，再将 Vaultwarden 和 FreshRSS 的数据用 Rclone 上传到坚果云上。

解密文件

要想解密文件，需要将文件复制到拥有对应私钥的电脑上，运行：

gpg --output filename --decrypt filename.gpg

其中 filename 是解密后的文件名，filename.gpg 是解密前的文件名，之后会提示输入密钥对的密码，输入对应密码后便可顺利解密文件。

结尾

本篇文章主要分享了以下我的自建服务基本的思路，包括安全配置、部署思路、备份与加密等等，对于具体的部署服务没有过多介绍，感兴趣的朋友还是更推荐查阅相关项目的官方文档。

> 关注 少数派小红书，感受精彩数字生活 🍃

> 实用、好用的 正版软件，少数派为你呈现 🚀

© 本文著作权归作者所有，并授权少数派独家使用，未经少数派许可，不得转载使用。