컴퓨터를 시작해야 하는데 비밀번호가 가짜인 것 같습니다. 또한 쓰기 위해 드라이브를 마운트할 수 없고, 밉스 프로세서이기 때문에 이를 실행하기 위해 다른 머신에 마운트할 수도 없습니다.
어쨌든, 그들의 passwd 파일에는 사용자 이름 뒤에 별표가 있는 다음과 같은 일부 사용자가 있습니다. 이것은 빈 비밀번호 등을 의미합니까?
root:8sh9JBUR0VYeQ:0:0:Super-User,,,,,,,:/:/bin/ksh
sysadm:*:0:0:System V Administration:/usr/admin:/bin/sh
diag:*:0:996:Hardware Diagnostics:/usr/diags:/bin/csh
daemon:*:1:1:daemons:/:/dev/null
bin:*:2:2:System Tools Owner:/bin:/dev/null
uucp:*:3:5:UUCP Owner:/usr/lib/uucp:/bin/csh
sys:*:4:0:System Activity Owner:/var/adm:/bin/sh
adm:*:5:3:Accounting Files Owner:/var/adm:/bin/sh
lp:VvHUV8idZH1uM:9:9:Print Spooler Owner:/var/spool/lp:/bin/sh
nuucp::10:10:Remote UUCP User:/var/spool/uucppublic:/usr/lib/uucp/uucico
auditor:*:11:0:Audit Activity Owner:/auditor:/bin/sh
dbadmin:*:12:0:Security Database Owner:/dbadmin:/bin/sh
rfindd:*:66:1:Rfind Daemon and Fsdump:/var/rfindd:/bin/sh
답변1
당신은 확인해야개인 비밀번호:
암호화 비밀번호가 별표(*)로 설정된 경우 사용자는 login(1)을 사용하여 로그인할 수 없지만 rlogin(1)을 사용하여 로그인하고 기존 프로세스를 실행하고 rsh(를 통해 새 프로세스를 시작할 수 있습니다. 1), cron(8) , at(1) 또는 메일 필터 등 단순히 쉘 필드를 변경하여 계정을 잠그려고 시도하면 동일한 결과가 생성되며 su(1) 사용도 허용됩니다.
일반적으로 비밀번호 필드의 계정에는 *
비밀번호가 없습니다(예: 로그인 비활성화). 이는 비밀번호가 없는 계정과 다릅니다. 이는 비밀번호 필드가 비어 있음을 의미하며 이는 거의 항상 나쁜 습관입니다.
답변2
비밀번호가 있는 계정은 두 번째 필드에 base64 횡설수설이 많이 포함된 계정입니다.
root:8sh9JBUR0VYeQ:0:0:Super-User,,,,,,,:/:/bin/ksh
lp:VvHUV8idZH1uM:9:9:Print Spooler Owner:/var/spool/lp:/bin/sh
이 컴퓨터는 전통적인 DES 기반crypt(3)
비밀번호 해시. 이 해시는 현대 표준에 따르면 상당히 취약합니다. 다른 방법으로 루트 로그인을 얻을 수 없는 경우 무차별 대입을 사용하여 비밀번호를 복구할 수 있습니다.존 더 리퍼또는 유사한 소프트웨어. 또한 기술적으로 이는 base64가 아니라 오래되고 유사한 인코딩이지만 걱정할 필요는 없습니다.
:*:
다른 답변에서 언급된 것과 다른 답변의 차이점은 :!:
너무 새롭고 귀하의 질문과 관련이 없습니다. 이전 UNIX 시스템에서는 비밀번호 필드에 세 가지 다른 항목만 나타날 수 있었습니다.
alice::1001:1001:Alice Can Log In Without A Password:/home/alice:/bin/ksh
bob:WSy1W41d4D1Gw:1002:1002:Bob Must Supply A Password:/home/bob:/bin/ksh
carol:ANYTHING ELSE:1003:1003:Carol Cannot Log In At All:/home/carol:/bin/ksh
비밀번호 필드가 비어 있으면 비밀번호 없이 로그인할 수 있습니다.
이 필드의 내용이 crypt
유효한 비밀번호 해시인 경우 해당 비밀번호를 사용하여 로그인할 수 있습니다.
그렇지 않으면 이 사용자로 로그인할 수 없습니다. *
단지 전통적인 사용법입니다. 시각적으로 유효한 비밀번호 해시가 아닙니다. passwd
프로그램을 작성한 사람이 선택 했을 수도 있습니다 .
(로그인할 수 없는 비밀번호 파일에 사용자 ID가 있다는 점은 해당 사용자가 여전히 파일을 소유할 수 있고 cron
작업을 가질 수 있으며 데몬을 사용하여 setuid
해당 ID를 가정할 수 있다는 것입니다. 실제로 가장 좋은 방법은 다음을 실행하는 것입니다. 모든 데몬( root
해당 사용자 ID로 반드시 실행될 필요는 없음)을 통해 어느 정도 확신을 가질 수 있습니다.오직데몬은 이 ID로 실행됩니다. )
(셸 필드의 계정이 /dev/null
잠겨 있어 해당 사용자 root
로 프로그램을 실행할 수 없습니다.su
또한정기적으로 로그인하세요. 요즘에는 이 목적으로 보거나 사용할 가능성이 더 높습니다 /bin/false
. /sbin/nologin
나는 후자가 이 시스템에 존재하지 않고 전자가 쉘 스크립트라고 생각합니다. )
(Bob의 비밀번호는 "bobpassw"이며 이전 알고리즘을 사용하여 암호화되었지만 최신 Linux 상자에서는 동일한 비밀번호와 솔트를 사용하여 컴퓨터가 생성한 비밀번호가 아닐 수도 있습니다. 이전 알고리즘이 나쁘다고 간주되는 이유 중 하나는 다음과 같습니다. 비밀번호를 어렵게 만듭니다. 최대 제한은 8자입니다.
(저는 이 시스템이 DES 기반 비밀번호 해싱을 사용하기 때문에 정말 오래되었다는 것을 알고 있습니다.아니요섀도우 파일을 사용하세요. 루트의 쉘은 /bin/ksh
더 새롭고 인체공학적인 것이 아니기 때문입니다. )
답변3
즉, 직접 로그인할 수 없습니다. 서비스를 실행하거나 rlogin에 사용되는 사용자입니다. 확인하다https://en.wikipedia.org/wiki/Passwd#Password_file
답변4
실제 질문에 대해서는 taliezin의 답변을 참조하세요. (그리고 해당 답변을 수락하세요.)
다른 질문과 관련하여: 디스크에서 문자열 8sh9JBUR0VYeQ를 검색하여 어떤 디스크 블록에 있는지 알아보세요. 그런 다음 해당 디스크 블록을 파일에 추가하고 string()을 알려진 비밀번호 해시(이전 암호화 해시 - 동일한 길이)로 바꾸고 디스크 블록을 이전 위치에 다시 씁니다. 아마도 전체 백업 전에 디스크에 수행된 작업일 것입니다. . 이 방법은 파일 크기를 변경하지 않으므로 파일 시스템 메타데이터를 업데이트할 필요가 없습니다.