SQLite无服务端进程，不支持网络连接或SSH端口转发；必须通过SSH远程执行sqlite3命令，依赖I/O重定向与文件系统权限（含SELinux）及WAL模式兼容性。
sqlite 是本地文件数据库，不支持网络连接，所谓“通过 ssh 连接 sqlite”本质上是远程执行本地命令——你连的不是 sqlite 本身，而是跳板机上的 sqlite3 命令行工具。这点不厘清，后续所有配置都会走偏。
为什么不能像 PostgreSQL 那样直接 ssh -L 转发 SQLite 端口
因为 SQLite 没有服务端进程（daemon），不监听任何端口，sqlite3 是纯客户端 CLI 工具，只读写本地文件。试图用 ssh -L 1234:/path/to/db.sqlite 会失败——SSH 端口转发需要后端服务接收 TCP 连接，而 SQLite 根本不提供这个能力。
常见错误现象：
- 执行
ssh -L 3306:/home/user/app.db user@jump后，本地sqlite3 localhost:3306报错：unable to open database file - 误以为配置
sshd_config的AllowTcpForwarding yes就能“启用 SQLite 远程访问”，结果毫无作用
真正可行的 SSH + SQLite 工作流
必须分两层：SSH 建立安全通道 → 在远程 shell 中运行 sqlite3 → 通过 stdin/stdout 交互或脚本驱动。关键在 I/O 重定向和 shell 权限控制。
实操建议：
- 用
ssh user@jump 'sqlite3 /var/db/app.sqlite'直接进入交互式 shell；注意路径必须是跳板机上真实可读的绝对路径 - 执行查询脚本：将 SQL 写入本地文件
query.sql，然后cat query.sql | ssh user@jump 'sqlite3 /var/db/app.sqlite' - 导出数据到本地：
ssh user@jump 'sqlite3 -csv /var/db/app.sqlite "SELECT * FROM logs;"'，配合> logs.csv重定向 - 禁止用户 shell 访问敏感目录：在跳板机上用
rbash或限制HOME和PATH，避免绕过数据库路径白名单
跳板机上 SQLite 文件权限与 SELinux/ACL 冲突
即使 SSH 登录成功，sqlite3 仍可能报 unable to open database file 或 disk I/O error——大概率是文件系统级权限拦住了，而非 SSH 配置问题。
检查重点：
- 确认数据库文件属主为运行 SSH 的用户，或该用户在对应组中，且目录有
x权限（SQLite 需要 traverse 权限才能进入目录） - SELinux 启用时，
ls -Z /var/db/app.sqlite应显示system_u:object_r:svirt_sandbox_file_t:s0类似上下文；若为unconfined_u，需用chcon -t svirt_sandbox_file_t /var/db/app.sqlite - 不要用
chmod 777暴力解决——SQLite WAL 模式下还会生成-wal和-shm临时文件，权限不一致会导致锁死
最易被忽略的一点：SQLite 的 PRAGMA journal_mode = WAL 在 NFS 或某些容器挂载卷上不可靠，通过 SSH 远程操作时若出现随机 database is locked，先关 WAL 或确认文件系统支持 POSIX fcntl 锁。这和 SSH 配置无关，但问题现象完全一样。
