로그인 비밀번호와 다르게 sudo 비밀번호 설정


29

권한이있는 사용자로서 sudo로그인시 사용한 암호와 다른 암호를 설정하려고합니다 .

나는 약간의 연구를했지만 대답을 찾지 못했습니다. sudo그런 종류의 구성을 지원 합니까 ?

비밀번호를 잊어 버리면 모든 것을 잃게됩니다. 누군가가 root동일한 비밀번호 로 로그인하여 자신을 홍보 할 수 있습니다.

sudoroot호출 된 사용자 비밀번호 ( rootpw) 대신 비밀번호 를 요청하는 옵션이 있지만 root비밀번호 공유 는 옵션이 아닙니다 sudo. 이것이 바로 우리가 설정 한 이유 입니다.

나는 config 2FA과거에 해냈 지만 훌륭하게 작동했지만 자동화 목적을 무효화했습니다. 예를 들어 expect스크립트 를 사용하여 수십 대의 서버에서 권한있는 명령을 실행하려는 경우 추가를 2FA통해이를 수행 할 수 없습니다.

내가 찾은 가장 가까운 솔루션은 SSH 개인 키 및 설정 sudo암호 문구 만 (로그인) 비밀번호 와 다른 키로 허용하는 것 입니다. 비상 상황에서는 해당 키가없는 PC로 로그인 할 수 없기 때문에 여전히 편안하지 않습니다.


1
왜 이것이 정확히 필요합니까? 어쩌면 문제가 다른 곳일 수도 있습니다. 권한있는 계정으로 시스템에 로그인하기 위해 이중 인증을받은 다음 'NOPASSWD'를 사용하여 sudo가 비밀번호를 요구하지 않는 것이 더 나을까요? 그런 다음 네트워크가 다운되었을 때 로그인 할 수 있도록 강력한 암호를 가진 별도의 비상 로컬 계정이 있어야합니다 (ssh 액세스 없음).
jirib

답변:


30

사용자 비밀번호와 달리 루트 비밀번호를 요청하려는 경우 입력 할 수있는 옵션이 있습니다 /etc/sudoers. rootpw특히 루트 암호를 요구하게됩니다. 이 runaspwtargetpw뿐만 아니라; 자세한 내용은 sudoers (5) 맨 페이지를 참조하십시오.

그 외에 sudo는 PAM을 통해 다른 모든 것과 마찬가지로 인증을 수행합니다. PAM은 응용 프로그램 별 구성을 지원합니다. Sudo의 설정은 (적어도 내 데비안 시스템에서) /etc/pam.d/sudo다음과 같습니다.

$ cat sudo 
#%PAM-1.0

@include common-auth
@include common-account
@include common-session-noninteractive

즉, 기본적으로 시스템의 다른 모든 것과 마찬가지로 인증됩니다. 해당 @include common-auth행을 변경하고 PAM (및 sudo)이 대체 암호 소스를 사용하도록 할 수 있습니다. common-auth의 주석 처리되지 않은 행은 다음과 같습니다 (기본적으로 LDAP를 사용하는 경우 달라집니다).

auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

pam_userdb.so대신 , 예를 들어 pam_unix.soBerkeley DB 데이터베이스에 대체 비밀번호를 저장할 수 있습니다.

디렉토리 /var/local/sudopass, owner / group root:shadow, mode를 만들었습니다 2750. 그 안에, db5.1_loadDebian Wheezy에서 사용하는 Berkeley DB 버전 인 암호 데이터베이스 파일을 만들었습니다 .

# umask 0027
# db5.1_load -h / var / local / sudopass -t 해시 -T passwd.db
앤서니
WMAEFvCFEFplI
^D

해당 mkpasswd -m des비밀번호는 비밀번호 "password"를 사용하여 로 생성되었습니다 . 매우 안전합니다! 불행히도 pam_userdb는 고대 crypt(3)해싱 보다 더 나은 것을 지원하지 않는 것 같습니다 .

이제 행을 편집 /etc/pam.d/sudo하고 제거 @include common-auth하고 대신 다음을 수행하십시오.

auth    [success=1 default=ignore]      pam_userdb.so crypt=crypt db=/var/local/sudopass/passwd
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

pam_userdb는 .db전달 된 데이터베이스에 확장을 추가 하므로 사용하지 않아야합니다 .db.

코멘트 에서 dannysauer 에 따르면 동일한 편집을해야 할 수도 있습니다./etc/pam.d/sudo-i

이제 sudo를하려면 password실제 로그인 비밀번호 대신 사용해야 합니다.

anthony @ sudotest : ~ $ sudo -K
anthony @ sudotest : ~ $ sudo echo -e '\ nit worked'
[sudo] Anthony의 비밀번호 : passwordRETURN

그것은 효과가 있었다

최신 버전의 sudo가 종종 "sudo -i"에 사용하는 "sudo-i"를 구성해야합니다 (공급 업체가 변경하지 않은 경우).
dannysauer 2013 년

PAM 구성 pls에 대해 자세히 설명해 주시겠습니까?
Shâu Shắc

@ ShâuShắc PAM 구성 변경을 포함하여 예제를 추가했습니다.
derobert

감사. 그러나 Redhat / centos 또는 소스에서 db51-utils를 찾을 수 없습니다. 데비안 변형에서만 사용할 수 있습니까?
Shâu Shắc

3
crypt(3)최신 버전의 glibc에서 " 고대 해싱"은 sha-512를 지원합니다. mkpasswd -m sha-512. pam_userdb.so는 이것들을 잘 처리 할 수 ​​있습니다.
앤드류 Domaszek

6

Redhat / Centos의 경우 다음 단계를 통해 요구 사항을 달성 할 수 있습니다.

사용자 정의 사용자를 작성하고 전달하십시오.

# db_load -t hash -T /usr/local/etc/passwd.db
user
pass
^d

다음과 같이 sudo pam.d 파일을 편집하십시오.

$ cat /etc/pam.d/sudo

auth            required        pam_userdb.so db=/usr/local/etc/passwd
account         required        pam_userdb.so db=/usr/local/etc/passwd
password        include         system-auth

session         optional        pam_keyinit.so revoke
session         required        pam_limits.so

여전히 구성 방법을 찾고 있으므로 특정 사용자 / 그룹만이 사용자 정의 방법으로 인증해야하고 다른 사용자는 여전히 일반 시스템 인증 방법으로 인증 할 수 있습니다. 누구든지 조언을 해 줄 수 있습니까?


PAM의 전체 동작 구문으로이 작업을 수행 할 수 있어야합니다. 예를 들어, [user_unknown=ignore,success=ok,default=bad]... 그러나 당신은 그것으로 플레이하고 PAM 문서를 읽어야합니다.
derobert

pam_succeed_if사용자가 그룹 목록 중 하나에 있으면 하나의 모듈을 건너 뛰거나 그렇지 않은 경우 두 개의 모듈을 건너 뛰는 방법 으로 도 수행 할 수 있습니다 .
dannysauer 2016 년

따라서 일반적인 내용은 다음과 같습니다. /// auth [success = ignore default = 1] danny : frank의 pam_succeed_if.so 사용자 /// auth enough danny_frank_module.so /// auth enough not_danny_frank.so
dannysauer

3

sudo가 그러한 설정을 지원하지 않는다고 생각합니다. sudo 비밀번호 프롬프트의 목적은 sudo 명령을 발행 한 사람이 로그인 한 사람과 동일한 사람이되도록하는 가장 쉬운 방법은 현재 로그인 한 사용자에게 자신을 다시 인증하도록 요청하는 것입니다.

즉, sudo 비밀번호 프롬프트의 목적은 권한 을 설정하는 것이 아니라 ID 를 설정하는 것입니다 . 확립 된 아이덴티티 및 sudo 구성에 기초하여, 해당 사용자에게 필요한 권한이 있는지 또는 액세스 권한이 있는지를 결정할 수있다.


3
Sudo는 루트 비밀번호, 특정 사용자 또는 대상 사용자의 비밀번호를 요청하려는 경우를 제외하고 PAM은 그렇지 않습니다. sudo는 PAM을 사용합니다.
derobert

1

귀하의 우려는 귀하의 계정 비밀번호가 공개 될 수 있다는 것입니다. 해결책은 공개 할 수있는 방식으로 로그인 비밀번호를 사용하지 않는 것입니다. ssh를 사용하면 비밀번호가 유선으로 암호화되므로 괜찮습니다. 비밀번호 기밀성을 보호하지 않고 비밀번호 추측 공격을 방지하기 위해 ssh로 비밀번호 인증을 해제합니다. 다른 계정에 동일한 계정 비밀번호를 사용하는 경우 안전한 암호화 채널을 사용하여 비밀번호를 제공해야합니다. 키로거 등이 걱정되는 경우 신뢰할 수없는 시스템을 사용하여 로그인을 중지하십시오.

누군가가 당신의 ssh 암호를 얻을 수 있다면, 그들은 아마도 대체 sudo 암호를 얻을 수 있습니다. 따라서 더 많은 보안의 환상을 위해 일을 더 복잡하게 만드는 시간을 보내는 것보다 연결을보다 안전하게 만드는 데 시간을 투자하는 것이 좋습니다.


0

이것을 테스트하고 세부 사항을 해결할 수있는 시스템에 즉시 액세스 할 수는 없지만 아이디어가 있습니다.

  • (일반 로그인 계정이이라고 가정하십시오 shau.)
  • 두 번째 계정을 만드십시오 : shau2. (와 동일한 UID를 원하는지 확실하지 않습니다 shau.)
  • shau2NOPASSWD로 sudo 권한을 갖도록 구성하십시오 .
  • 수행 할 별명 또는 쉘 스크립트를 설정하십시오 su shau2 -c sudo "$@". shau2의 비밀번호를 요청해야 합니다. 올바르게 입력하면 (암호를 요구해서는 안 됨)으로 실행 sudo됩니다 shau2.
  • shau의 sudo 권한을 제거하십시오 .

불행히도 sudo 권한이있는 모든 사용자에 대해이 작업을 반복해야합니다.


0

답변 @ Shâu Shắc 에게 감사합니다 ! 이 솔루션은 LinuxMint 17.1 Cinnamon 32bit 에서도 작동합니다 ( 실행하기 위해 패키지 만 설치 했습니다 ).db-utildb_load

그러나 결과 passwd.db파일 과 혼동 됩니다. 나는 당신의 대답과 똑같이했습니다 (그러나 davidjones를 사용 하면 눈길을 사로 잡습니다) :

# db_load -t hash -T /usr/local/etc/passwd.db
david
jones
^d

그러나 입력 한 자격 증명은 해시 파일 내에 일반 텍스트로 저장됩니다.

# grep 'jones.*david'  /usr/local/etc/passwd.db
Binary file /usr/local/etc/passwd.db matches

mcedit 를 통해 davidjones 를 볼 수도 있습니다 .

여기에 이미지 설명을 입력하십시오

예,의 권한을 제한 할 수 있습니다 /usr/local/etc/passwd.db. 그러나 어쨌든 일반 텍스트로 저장된 사용자 이름과 비밀번호는 잘못되었습니다.


별도의 sudo 암호를 사용 하더라도 잠재적 인 보안 허점이 있습니다 (기본적으로 배포 설정). 따라서 su 에는 별도의 암호를 사용할 수 없습니다 (따라서 su로그인 암호를 사용하여 루트 세션을 시작할 수 있습니다). 또한 정책 키트 에서는 별도의 암호를 사용하지 않습니다 ( 암호를 사용하여 시냅틱 을 시작 synaptic-pkexec하고 암호를 로그인 한 다음 패키지를 삭제할 수 있습니다 ...). 구성 파일을 추가로 조정하면 이러한 문제를 해결할 수 있습니다.

일반적으로 안전한 개별 sudo 비밀번호는 사용자 정의 PAM 모듈 (아마도 이러한 모듈이 파일에서 읽은 비밀번호와 SHA-512 해시를 비교 함) 또는 SELinux 기능을 사용해야 만 달성 할 수 있습니다.

추신 : 죄송합니다. 코멘트입니다. 그러나 텍스트 형식으로 인해 답이됩니다. 이해 주셔서 감사합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.