
UNIX 사용자가 SSH를 통해 서버에 접속하고 공개 키 로그인만 허용하려는 경우 이 목록에 추가해야 할 다른 항목이 있습니까?
- 서버의 파일을
pubkey login
허용 합니다 .sshd_config
- 다음과 같은 기본 비밀번호에 대한 고려 사항"!"또는"*"
답변1
어떤 SSH 서버를 요청하는지, 어떤 Unix 시스템 세트가 무엇인지 알려주는 것이 좋을 것입니다.
!
또는 ( 해당 항목을 읽는 데 사용 ) *
에서 볼 때 비밀번호가 아닙니다 ./etc/passwd
/etc/shadow
getent
계정에 비밀번호가 있는지 여부, 잠겨 있는지 여부를 나타내는 표시입니다.
이는 PAM의 구성 및 버전과 배포판에 따라 중요한 차이점입니다.당신이 리눅스를 사용한다면. 잠겨 있으면 로그인이 허용될 가능성이 적지만, 반면에 이전 시스템에서는 기본적으로 작동할 수도 있습니다(적어도 제 경험상 그렇습니다).
(수퍼유저로서) passwd -l <name>
계정을 잠 !
그거나( ) passwd -d <name>
계정에서 비밀번호를 삭제할 *
수 있으며( ) 두 가지를 결합하여 기존 비밀번호가 제거되도록 할 수도 있습니다 passwd -dl <name>
.
당신은 말하지 않지만 OpenSSH의 관련 지시문 /etc/ssh/sshd_config
(경로는 다를 수 있음)을 가정하면 다음과 같습니다.
HostKey ...
서버에는 호스트 키나 RSA2 또는 DSA가 있어야 합니다(더 현대적인 구현에는 두 개의 타원 곡선 구현도 추가됩니다). RSA1은 모든 일반적인 SSH 서버 구현에서 오랫동안 버려졌습니다.
그 다음에:
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
또한 SSH( )를 통한 로그인을 설정 /etc/sudoers
하고 완전히 허용하지 않도록 항상 권장합니다 . 그러나 디스크가 가득 차서 권한이 없는 구성원이 디스크에 쓸 수 없지만 예약된 공간으로 인해 쓸 수 있는 경우 이러한 보다 안전한 설정에는 사소한 단점이 있을 수 있습니다 . 그래서 YMMV.root
PermitRootLogin no
sudo
root
두 가지 추가 조언
SSH 액세스를 제한하도록 그룹 할당
그룹 ssh-users
(또는 원하는 이름)을 만들고 에 해당 지시어를 설정합니다 sshd_config
. root
위 정보를 바탕으로 선택한 정책에 따라 해당 그룹의 구성원인지 아닌지 확인하세요 .
AllowGroups ssh-users
사용자를 제한할 그룹 할당오직SFTP 액세스
sshd_config
다음 에서는 사용자가 탈출할 수 없도록 /home
하고 특정 기능을 비활성화하는지 확인합니다.
Match group sftponly
ChrootDirectory /home
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
PasswordAuthentication no
결론
그렇습니다. Linux에서는 PAM을 고려 사항으로 추가해야 합니다.
또한 에이전트 전달을 허용할지 아니면 사용자에게 맡길지 여부도 결정됩니다.
마지막으로 포트 또는 X11 연결 전달을 허용할지 여부도 중요합니다. 특히 포트는 사용자가 서버를 프록시로 사용할 수 있으므로 바람직하지 않을 수 있습니다.
지시문 Match
을 사용하면 사용자가 연결되는 위치를 기준으로 사용자를 제한할 수도 있습니다(방화벽이나 TCP 래퍼도 이를 수행할 수 있음).
사용자가 키를 관리할 수 있도록 하시겠습니까, 아니면 이를 추상화하여 사용자가 직접 액세스할 수 authorized_keys
없도록 하시겠습니까?
확실히 더 많은 측면이 있지만 대부분은 더 세밀한 세부 수준에 있으며 앞서 언급한 사항의 변형입니다.
답변2
비밀번호 복잡성에 대한 정책을 고려하여 사용자가 원하는 것이 무엇이든 가능합니다. 유일한 액세스가 SSH를 통한 PasswordAuthentication
것이고no
sshd_config
, 비밀번호가 무엇인지는 중요하지 않습니다. 또한shadow
암호화된 비밀번호이므로 !
및 값은 *
그렇지 않습니다.비밀번호- 그러나 유효한 암호화 값이 아닌 문자열이므로 비밀번호 기반 로그인이 불가능합니다.
답변3
OpenSSH가 포함된 RHEL/CentOS와 유사한 것을 실행한다고 가정하면, 비밀번호 없이 전환할 때 일반적으로 수행하는 작업은 다음과 같습니다.
- 공개 키 인증만 허용하도록 sshd_config 구성(
PubkeyAuthentication yes, PasswordAuthentication no, ChallengeResponseAuthentication no, UsePAM no
) - 모든 기존 사용자가 유효하지 않은 비밀번호를 갖도록 설정(
chpasswd -e 'pubkey!!' <username>
) - 모든 기존 사용자의 비밀번호 만료 제거(
chage -M -1 <username>
) - sudo를 사용하는 경우 모든 사용자 사양이 NOPASSWD로 표시되어 있는지 확인하세요(예:
%wheel ALL=(ALL) NOPASSWD: ALL
) - 사용자 생성 프로세스가 이러한 요구 사항을 유지하는지 확인하십시오(예
useradd -p 'pubkey!!' -K MAX_PASS_DAYS=-1 <username>
: )
비밀번호 액세스를 잠그기 전에 공개키를 통해 성공적으로 인증할 수 있는지 이중으로 확인하세요. /home 파티션이 네트워크 마운트(또는 항상 사용 가능하지 않을 수 있는 다른 것)에 있지 않은지 확인하십시오. 공개 키에 접근할 수 없기 때문에 서버에 대한 액세스 권한을 잃는 것보다 더 나쁜 것은 거의 없습니다. 시스템이 헤드리스인 경우 비상 시 직접 콘솔에 빠르게 액세스할 수 있는 방법(KVM, 가상 콘솔, 크래시 카트 등)이 있는지 확인하십시오.
즉, 전체 sudo 액세스 권한이 있는 모든 사람의 계정에 비밀번호를 설정하고 sudo 사용자에게 비밀번호를 요구하도록 구성하는 것을 고려하겠습니다. 다른 모든 것이 위와 같이 구성된 경우에도 이 비밀번호를 사용하여 서버에 로그인할 수는 없지만 명령 프롬프트에 앉아서 "나쁜 일(tm)"을 하는 사람에 대해 약간의 추가 보호 기능을 제공합니다. .
답변4
rcommand
Linux가 아닌 UNIX(HP UX) 시스템인 경우 sshd 계정 아래의 pam.conf에 추가해야 합니다 .
sshd account sufficient /usr/lib/security/libpam_ldap.1 rcommand
그렇지 않으면 시스템에 SSH로 접속하려고 할 때 비밀번호 프롬프트가 표시되지 않습니다.