☰

공개 키 SSH 인증을 위해 계정을 잠금 해제하지만 비밀번호 인증은 해제하는 방법은 무엇입니까?

tag-icon • tag-icon ssh password
공개 키 SSH 인증을 위해 계정을 잠금 해제하지만 비밀번호 인증은 해제하는 방법은 무엇입니까?

계정이 잠겨 있기 때문에 ssh에서 로그인을 허용하지 않습니다. SSH를 통한 공개 키 인증을 위해 서버에서 사용자의 잠금을 해제하고 싶지만 비밀번호 로그인은 활성화하지 않으려고 합니다.

나는 시도했다:

# passwd -u username
passwd: unlocking the password would result in a passwordless account.
You should set a password with usermod -p to unlock the password of this account.

로그 항목 확인:

Mar 28 00:00:00 vm11111 sshd[11111]: User username not allowed because account is locked
Mar 28 00:00:00 vm11111 sshd[11111]: input_userauth_request: invalid user username [preauth]

답변1

무엇을 하든 계정을 passwd -u비밀번호 필드가 비어 있는 상태로 두지 마십시오. 이렇게 하면 비밀번호를 입력하지 않고도 로그인할 수 있습니다(이 작업을 거부하는 SSH는 제외).

계정을 비밀번호 없이 잠금 해제되도록 변경합니다. 비밀번호 데이터베이스의 비밀번호 해시가 문자열의 해시가 아닌 경우 해당 계정에는 비밀번호가 없습니다. 전통적으로 *이는 또는 같은 단일 문자 문자열을 사용하여 수행됩니다.!

잠긴 계정은 비밀번호 필드에 특수 토큰을 사용하므로 문자열이 어떤 문자열의 해시도 되지 않습니다. 이 플래그는 시스템에 따라 다릅니다. Linux에서 이 passwd명령은 시작 부분에 를 추가하여 잠긴 비밀번호를 표시합니다 !. OpenSSH는 필드가 로 시작하면 계정을 잠긴 것으로 처리합니다 !. 다른 Unix 변형은 유사하지만 동일하지는 않은 메커니즘을 사용하는 경향이 있으므로 비밀번호 데이터베이스가 이기종 네트워크에서 공유되는 경우 주의하십시오.

Linux에서는 SSH 액세스를 허용하면서 비밀번호 기반 계정 액세스를 비활성화할 수 있습니다(다른 인증 방법, 일반적으로 키 쌍 사용).

usermod -p '*' username

사용자는 유효한 비밀번호를 입력해야 하므로 계정을 비밀번호로 다시 변경할 수 없습니다.

원하는 경우 계정에 비밀번호가 있는지 여부에 관계없이 비밀번호 인증을 거부하도록 SSH를 구성할 수 있습니다. 계정이 잠긴 것으로 간주하지 않도록 SSH를 준비해야 합니다. 예를 들어 Linux에서는 !비밀번호 필드를 제거해야 합니다(그러나 필드를 비워 두지 말고 *위와 같이 설정하세요). SSH에 대한 비밀번호 인증을 비활성화하려면 또는 (시스템의 위치에 관계없이) 지시어를 PasswordAuthentication추가 하세요. 특정 사용자에게만 지시어를 제공하려면 블록을 사용하세요 . 블록이 있어야 합니다./etc/sshd_config/etc/ssh/sshd_configMatchMatch

…
Match User username
    PasswordAuthentication no

답변2

@Skaperen의 조언에 따라 계정을 잠금 해제하고 사용자에게 복잡한 비밀번호를 제공하세요.

편집 /etc/ssh/sshd_config하고 다음 사항을 확인하세요.

PasswordAuthentication no

#행에 주석( 처음 부분) 이 없는지 확인 하고 파일을 저장하십시오. 마지막으로 sshd서비스를 다시 시작하십시오.

이 작업을 수행하기 전에 공개 키 인증이 제대로 작동하는지 확인하세요.

한 명(또는 소규모 그룹)의 사용자에 대해서만 이 작업을 수행해야 하는 경우 PasswordAuthentication활성화된 상태로 두고 대신 사용하세요 Match User.

Match User miro, alice, bob
    PasswordAuthentication no

Match다음 명령이나 EOF까지 유효하므로 파일 맨 아래에 배치합니다 .

또한 사용하거나 Match Group <group name>부정 할 수도 있습니다.Match User !bloggs

설명에서 언급했듯이 구성의 주요 부분에서 비밀번호 인증이 비활성화되도록 되돌리고 Match다음 명령문을 사용하여 일부 사용자에 대해 활성화할 수도 있습니다.

PasswordAuthentication no
.
.
.
Match <lame user>
    PasswordAuthentication yes

답변3

비밀번호를 활성화하거나 설정할 필요가 없으며 이미 강력한 키를 사용하고 있는 경우에는 비밀번호를 설정해서는 안 됩니다. 기존 세션(sudo passwd -l 사용자 이름)에서 계정을 다시 잠그고 SSH 구성을 수정하세요.

이는 기본 SSH 데몬 설정 중 하나(/etc/ssh/sshd_config)를 편집했기 때문에 발생할 수 있습니다.

/etc/ssh/sshd_config에서 이 설정을 변경하고 SSH를 다시 ​​시작합니다.

UsePAM yes

SSH에서 PAM을 활성화하면 비밀번호를 삭제하더라도 로그인이 가능합니다. 무엇을 하든지 빈 비밀번호나 이와 유사한 것을 설정하지 마십시오. 비밀번호 필드를 잠근다고 해서 반드시 전체 계정이 잠기는 것은 아닙니다.

SSH 데몬 구성 시 빠른 팁: SSH 구성을 변경할 때마다 다른 세션을 다른 창에서 열어두고 실수로 액세스가 손상된 경우 이전 세션을 사용하여 문제를 해결하세요.

(면책조항: 저는 Userify에서 일합니다.)

답변4

CentOS 7에서 이 문제가 발생했습니다. 저는 일반 Debian 기반 Linux 사용자이므로 물 밖으로 나온 물고기와 같습니다. 일부 서버에서는 작동하지만 단 하나의 서버에서는 작동하지 않는 것으로 나타났습니다. audit.log는 유용한 정보를 제공하지 않으며 secure.log는 유용한 정보를 제공하지 않습니다. 내가 찾은 유일한 실제 차이점은 유효한 파일과 잘못된 파일 및 디렉터리 간의 보안 컨텍스트 차이였습니다. 보안 확보

sudo ls -laZ <user-home>/.ssh

디렉토리(sshd_config에는 많은 기본값이 있다고 가정합니다).

ssh_home_t일부 및 속성이 표시되어야 합니다 user_home_t. 그렇지 않은 경우 이 chcon명령을 사용하여 누락된 속성을 추가하세요.

예를 들어

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

제 경우에는 사용자가 비표준적인 방식으로 생성된 것이 아닌가 의심됩니다. 그의 집은 디렉토리입니다 /var/lib.

추가 정보:https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

관련 정보