CentOS 8 上搭建SFTP服务

安装

在CentOS 8上搭建SFTP服务,可以通过OpenSSH来实现。以下是具体步骤:

1. 安装OpenSSH服务器

在CentOS 8中,通常已经安装了OpenSSH服务器。如果没有,可以通过以下命令安装:

bash 复制代码
sudo dnf install -y openssh-server

2. 启动并启用OpenSSH服务

确保OpenSSH服务正常运行,并设置为开机启动:

bash 复制代码
sudo systemctl start sshd
sudo systemctl enable sshd

可以通过以下命令检查服务状态:

bash 复制代码
sudo systemctl status sshd

3. 配置SFTP用户

为SFTP创建一个独立的用户,并指定一个目录作为用户的SFTP根目录。

创建用户组和目录

可以为SFTP用户创建一个专门的用户组和目录。例如创建一个/sftp目录,并为所有SFTP用户设置该目录为根目录:

bash 复制代码
sudo mkdir -p /sftp
sudo groupadd sftpusers
创建SFTP用户

创建一个新用户,将其主目录指定为/sftp/[username],并将用户添加到SFTP用户组中。例如:

bash 复制代码
sudo useradd -m -d /sftp/[username] -s /sbin/nologin -G sftpusers [username]

[username]替换为实际用户名。

为用户设置密码:

bash 复制代码
sudo passwd [username]
设置权限

设置/sftp目录的权限,使其只能被root用户访问,并创建用户文件夹上传数据:

bash 复制代码
sudo chown root:root /sftp
sudo chmod 755 /sftp
sudo mkdir /sftp/[username]/uploads
sudo chown [username]:sftpusers /sftp/[username]/uploads

4. 配置OpenSSH以限制SFTP访问

编辑SSH配置文件 /etc/ssh/sshd_config

bash 复制代码
sudo vim /etc/ssh/sshd_config

在文件中添加以下内容以启用SFTP的chroot环境:

bash 复制代码
# 指定SFTP子系统
Subsystem sftp internal-sftp

# 配置SFTP用户组
Match Group sftpusers
    ChrootDirectory /sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no
  • ChrootDirectory /sftp/%u:将用户限制在/sftp/[username]目录中。
  • ForceCommand internal-sftp:强制用户使用SFTP而不是SSH shell。

5. 重启SSH服务

修改配置文件后,重启SSH服务以应用更改:

bash 复制代码
sudo systemctl restart sshd

6. 测试SFTP连接

可以使用SFTP客户端(如sftp命令或WinSCP、FileZilla等)进行连接:

bash 复制代码
sftp [username]@[server_ip]

连接后,你应该只能访问指定的目录,无法浏览服务器上的其他文件。

注意事项

  • 确保目录权限设置正确。/sftp目录必须由root拥有,且权限为755
  • 用户上传文件的目录,如uploads,需要将权限授予具体的SFTP用户,以确保其可以上传文件。

这样,你就成功在CentOS 8上配置了一个SFTP服务!

排查报错

重启ssh报错了:Job for sshd.service failed because the control process exited with error code. See "systemctl status sshd.service" and "journalctl -xe" for details.

sshd.service重启失败的原因可能是SSH配置文件中的语法错误、不正确的权限设置,或其他配置问题。可以按照以下步骤排查问题:

1. 检查sshd的状态

运行以下命令查看sshd服务的状态,获取具体的错误信息:

bash 复制代码
sudo systemctl status sshd.service

状态信息会显示服务失败的原因或提示进一步排查的方向。

2. 查看日志

使用以下命令查看journalctl日志中的详细信息,找到可能导致服务启动失败的具体原因:

bash 复制代码
sudo journalctl -xe

日志中通常会有更详细的错误信息,比如文件权限问题、配置参数错误等。

3. 检查SSH配置文件

SSH服务启动失败的常见原因是配置文件 /etc/ssh/sshd_config 中的错误。可以使用以下命令来检查该文件是否有语法问题:

bash 复制代码
sudo sshd -t
  • 如果输出为空,说明配置文件语法无误。
  • 如果有错误信息,SSH服务会指出出错的行数和错误类型。根据提示返回的行号修正配置文件。

4. 常见错误排查

以下是一些可能导致sshd启动失败的常见原因及解决方法:

  • 配置文件语法错误 :检查/etc/ssh/sshd_config文件中的配置参数,确保格式正确。例如,参数和值之间需要空格。
  • 权限问题 :确保/etc/ssh/目录和sshd_config文件的权限正确。通常建议权限设置如下:
bash 复制代码
sudo chmod 644 /etc/ssh/sshd_config
sudo chmod 700 /etc/ssh
  • 端口被占用 :如果修改了SSH监听的端口(如Port 22),请确认该端口没有被其他进程占用。可以用以下命令查看端口占用情况:
bash 复制代码
sudo lsof -i :<port-number>

如端口被占用,可以选择修改端口号,或停止占用端口的服务。

5. 重启sshd服务

修改配置文件后,重新加载配置并尝试重启SSH服务:

bash 复制代码
sudo systemctl daemon-reload
sudo systemctl restart sshd

6. 测试

如果重启成功,可以通过以下命令检查SSH服务是否在运行:

bash 复制代码
sudo systemctl status sshd

如果服务成功启动,active (running)表示SSH服务正在正常运行。

通过以上步骤,你应该能找到并解决sshd服务启动失败的问题。如果问题依旧存在,可以提供具体的日志信息,我们可以进一步排查。

常见报错

系统中已经有了子系统的配置

例如:Subsystem sftp /usr/libexec/openssh/sftp-server

在配置SFTP时,Subsystem sftp /usr/libexec/openssh/sftp-server 是指定SFTP服务的默认配置路径。在某些Linux系统中(例如CentOS),该路径用于定义SFTP服务的执行文件,默认会加载SFTP功能。如果在配置SFTP时遇到问题,可以进行以下检查和调整:

1. 确认sshd_config配置

确保在/etc/ssh/sshd_config文件中只有一个Subsystem sftp配置项。如果存在多个配置项,可能会导致冲突。通常只需保留以下内容:

plain 复制代码
Subsystem sftp /usr/libexec/openssh/sftp-server

2. 配置SFTP用户权限(可选)

如果需要将用户限制在特定目录中,可以使用以下方式指定SFTP用户组和访问限制:

plain 复制代码
Match Group sftpusers
    ChrootDirectory /sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

其中:

  • ChrootDirectory /sftp/%u:将用户限制在主目录/sftp/[username]中。
  • ForceCommand internal-sftp:强制用户使用SFTP服务,而不是SSH shell。

3. 检查并重启SSH服务

保存配置后,检查配置文件的语法并重启SSH服务:

bash 复制代码
sudo sshd -t  # 检查语法是否正确
sudo systemctl restart sshd

如果配置没有语法错误且服务成功重启,SFTP功能应该可以正常工作。

4. 测试SFTP连接

通过客户端(例如sftp命令)连接服务器,验证SFTP是否可用:

bash 复制代码
sftp [username]@[server_ip]

这套配置应该能保证SFTP服务可用且具有一定的安全性。如有更多需求,可以继续根据用户组和权限配置进行精细化管理。

免密登陆失败

如果你的 sshd_config 中有以下配置:

bash 复制代码
PasswordAuthentication yes
ChallengeResponseAuthentication yes

这两个配置会允许密码认证和挑战响应认证(通常用于二次身份验证)。但是,PasswordAuthentication yes 可能与公钥认证冲突,因为 SSH 可能优先考虑密码认证或挑战响应认证,而忽略公钥认证。

解决方案:

  1. 禁用密码认证
    为了强制使用公钥认证,你可以禁用密码认证。更改 sshd_config 中的 PasswordAuthentication 设置为 no,然后重启 SSH 服务。

编辑 sshd_config

bash 复制代码
sudo vi /etc/ssh/sshd_config

将以下行:

bash 复制代码
PasswordAuthentication yes
ChallengeResponseAuthentication yes

修改为:

bash 复制代码
PasswordAuthentication no
ChallengeResponseAuthentication no

这样就会禁用密码和挑战响应认证,强制使用公钥认证。

  1. 重启 SSH 服务
    更改配置后,重启 SSH 服务以应用更改:
bash 复制代码
sudo systemctl restart sshd

检查其他配置项:

  • **确保 **PubkeyAuthentication** 为 ****yes**:确认在 sshd_config 中启用了公钥认证。
bash 复制代码
PubkeyAuthentication yes
  • 确保 **AuthorizedKeysFile** 设置正确 :通常它应该是 .ssh/authorized_keys
bash 复制代码
AuthorizedKeysFile     .ssh/authorized_keys

测试公钥认证:

在客户端(比如 FileZilla 或命令行)尝试重新连接:

bash 复制代码
ssh -i ~/.ssh/id_rsa sftp0@[server_ip]

如果连接成功,说明公钥认证已经生效。

总结:

通过禁用密码认证和挑战响应认证,可以确保服务器只使用公钥认证,这会提高 SFTP 安全性并避免认证冲突。

client_loop: send disconnect: Broken pipe

client_loop: send disconnect: Broken pipe 错误通常发生在 SSH 会话中,表示连接已经被意外关闭。这可能是由于多个原因引起的,下面是一些常见的原因以及相应的解决方法:

1. 网络连接问题

  • 这是最常见的原因之一,尤其是在网络不稳定的情况下,连接可能会断开。
  • 解决方法: 确保网络连接稳定。你可以尝试通过其他网络(例如有线连接或不同的 Wi-Fi 网络)来确认是否是网络问题。

2. SSH 客户端超时

  • 如果 SSH 客户端等待时间过长没有活动,连接可能会被自动断开。你可以通过增加客户端的保持活动设置来避免此问题。
  • 解决方法: 编辑客户端配置文件 ~/.ssh/config,添加以下行来启用保持活动功能:
bash 复制代码
Host *
  ServerAliveInterval 60
  ServerAliveCountMax 3

这个设置会每 60 秒向服务器发送一个空闲包,如果服务器在 3 次尝试内没有响应,则断开连接。

3. SSH 服务器端超时

  • 如果服务器端有设置连接超时,且客户端在该时间内没有任何活动,服务器会断开连接。
  • 解决方法: 编辑 SSH 服务器端配置文件 /etc/ssh/sshd_config,确保没有过短的超时设置:
bash 复制代码
ClientAliveInterval 60
ClientAliveCountMax 3

这会让服务器每 60 秒向客户端发送一个信号。如果服务器在 3 次尝试内没有收到响应,就断开连接。

修改后,重启 SSH 服务:

bash 复制代码
sudo systemctl restart sshd

4. 防火墙或网络设备问题

  • 一些防火墙或路由器可能会关闭长时间未活动的连接。
  • 解决方法: 检查防火墙设置(包括本地和远程的防火墙)是否有类似的连接超时设置。如果使用的是企业级防火墙或路由器,检查是否存在自动断开长时间闲置连接的规则。

5. 错误的 SSH 配置

  • 如果 SSH 配置不正确,特别是公钥认证部分出现问题,也可能导致连接被强制关闭。
  • 解决方法: 确保 SSH 配置文件没有错误。你可以通过以下命令检查 sshd 服务的状态,查看是否有任何错误信息:
bash 复制代码
sudo systemctl status sshd

如果出现错误,查看日志并修复配置。

6. 不正确的权限设置

  • 如果 .ssh/authorized_keys 文件或其父目录的权限设置不正确,可能导致认证失败并最终断开连接。
  • 解决方法: 确保 .ssh 目录和 authorized_keys 文件的权限是正确的。执行以下命令:
bash 复制代码
sudo chmod 700 /home/sftp0/.ssh
sudo chmod 600 /home/sftp0/.ssh/authorized_keys
sudo chown -R sftp0:sftp0 /home/sftp0/.ssh

7. 检查服务器端日志

  • 服务器端日志可能会提供更多关于连接断开的详细信息,特别是 SSH 服务的日志。
  • 解决方法: 查看 /var/log/auth.log/var/log/secure 文件,了解更多信息:
bash 复制代码
sudo tail -f /var/log/auth.log

或者:

bash 复制代码
sudo tail -f /var/log/secure

这样你可以查看 SSH 服务是否由于某些错误或限制关闭了连接。

8. SSH 版本不兼容

  • 如果客户端和服务器使用的 SSH 协议版本或加密算法不兼容,可能会导致连接问题。
  • 解决方法: 确保客户端和服务器使用的 SSH 版本是兼容的,并且支持相同的加密算法。

总结

client_loop: send disconnect: Broken pipe 错误通常是因为 SSH 连接超时、网络问题或服务器端配置不当引起的。通过调整 SSH 客户端和服务器的超时设置、检查防火墙规则和权限设置,通常可以解决这个问题。如果问题仍然存在,查看日志可以帮助进一步诊断。

fatal: bad ownership or modes for chroot directory "/sftp/sftp0"

报错信息 fatal: bad ownership or modes for chroot directory "/sftp/sftp0" 表示 SSH 守护进程在尝试使用 chroot 环境时,发现指定的目录 /sftp/sftp0 的权限或所有者设置不符合安全要求。为了防止潜在的安全问题,SSH 要求 chroot 目录必须具有特定的权限。

解决方案

1. 确保 **chroot** 目录的所有者和权限正确

SSH 在使用 chroot 时要求指定的目录必须由 root 用户拥有,并且该目录的权限设置不能太宽松。确保 /sftp/sftp0 目录的所有者是 root,且该目录的权限是 755。执行以下命令:

bash 复制代码
sudo chown root:root /sftp/sftp0
sudo chmod 755 /sftp/sftp0
2. 检查子目录权限

如果 sftp0 用户应该在该目录下有自己的子目录(比如 uploads 或其他),确保这些子目录的权限是适当的。具体来说,子目录可以由 sftp0 用户拥有,但不能直接为 sftp0 用户的父目录设置过宽松的权限。

假设你在 /sftp/sftp0 下创建了子目录:

bash 复制代码
sudo mkdir /sftp/sftp0/uploads
sudo chown sftp0:sftpusers /sftp/sftp0/uploads
sudo chmod 755 /sftp/sftp0/uploads
3. 确保没有额外的 **chroot** 子目录权限问题

如果你启用了 ChrootDirectory 配置项,必须确保父目录的权限符合 SSH 的要求:

  • ChrootDirectory 指定的目录(即 /sftp/sftp0)必须属于 root,并且不能有写权限给普通用户。
  • 用户应该在 chroot 目录内有自己的子目录(如 uploads)来进行操作,且该子目录可以赋予用户写权限。
4. 检查 SSH 配置

确保 SSH 配置文件 /etc/ssh/sshd_config 中的 ChrootDirectory 配置项没有问题。以下是正确配置的示例:

bash 复制代码
# 限制 sftp0 用户只能访问 /sftp/sftp0 目录
Match User sftp0
    ChrootDirectory /sftp/sftp0
    ForceCommand internal-sftp
    AllowTcpForwarding no
5. 重新启动 SSH 服务

在做出上述更改后,重新启动 SSH 服务使配置生效:

bash 复制代码
sudo systemctl restart sshd

总结

bad ownership or modes for chroot directory 错误通常是由于 SSH 对于 chroot 目录的权限要求不满足。你需要确保 chroot 目录的所有者是 root,并且权限设置为 755,且子目录的权限适合用户操作。通过以上操作,应该可以解决问题。

如果看到返回:This service allows sftp connections only.

说明登录已经成功了,该用sftp协议即可,例如: FileZillasftp 命令行工具

Q&A

Subsystem配置变了,ForceCommand配置是不是也要一起改变?

例如:ForceCommand /usr/libexec/openssh/sftp-server

是的,如果你改变了 SFTP 子系统的路径(例如,更改了 sftp-server 的位置),你可能需要更新 sshd_config 中的 ForceCommand 配置项。

1. **Subsystem**** 与 **ForceCommand** 的关系**

  • **Subsystem**:指定 SFTP 服务的可执行文件。在默认情况下,Subsystem sftp /usr/libexec/openssh/sftp-server 用于指定 SFTP 服务的路径。
  • **ForceCommand**:强制用户登录时只执行特定的命令,如果你设置了 ForceCommand internal-sftp,那么用户只能通过 SFTP 访问,不会有交互式 Shell。它确保了当用户连接 SSH 时,不会启动普通的 shell,而是启动 SFTP 会话。

2. 更新配置

如果你改变了 sftp-server 的路径,确实需要相应地更新 ForceCommandSubsystem 配置项。如果你将 sftp-server 移到了新的路径,例如 /usr/local/bin/sftp-server,你需要修改如下:

plain 复制代码
Subsystem sftp /usr/local/bin/sftp-server
ForceCommand /usr/local/bin/sftp-server

3. 配置建议

通常情况下,**ForceCommand internal-sftp** 会是更常见的配置,它将强制用户使用内置的 SFTP 服务,而不需要指定路径。这样,如果你没有特殊需求,不必再指定外部的 sftp-server 路径。例如:

bash 复制代码
Subsystem sftp /usr/libexec/openssh/sftp-server
ForceCommand internal-sftp

这意味着,无论 /usr/libexec/openssh/sftp-server 的位置在哪里,用户都会被强制使用 internal-sftp 模式连接 SSH,从而避免普通 shell 会话的启动,确保用户只能进行 SFTP 操作。

相关推荐
mafucan10 分钟前
VulnHub-Acid(1/100)
linux·安全·渗透测试·靶场·刷题·vulnhub
vvw&18 分钟前
如何在 Ubuntu 22.04 上安装 Nagios 服务器教程
linux·运维·服务器·数据库·ubuntu·nosql
weixin_4539650040 分钟前
【3】安装cyclictest和iperf
linux·运维·服务器
网络工程师鸡哥1 小时前
什么是VLAN?
运维·网络·经验分享·华为
鹧鸪云光伏与储能软件开发1 小时前
微电网运维:保障能源“小宇宙”稳定运行
运维·能源
leisigoyle1 小时前
【连续3届JPCS出版,EI稳定检索!】第四届能源利用与自动化国际学术会议(ICEUA 2025)
运维·自动化·能源
Toormi1 小时前
Linux查看网络带宽和使用情况
linux·运维·服务器
qq_40999093?1 小时前
云计算基础,虚拟化原理
linux·服务器·云计算
问道飞鱼1 小时前
【Linux知识】Linux防火墙介绍
linux·运维·网络·iptables·firewall
初学者丶一起加油1 小时前
C语言基础:指针(常量指针和指针常量)
java·linux·c语言·开发语言·算法·ubuntu·visualstudio