จะปลดล็อคบัญชีสำหรับการให้สิทธิ์กุญแจสาธารณะ แต่ไม่ได้รับอนุญาตให้ใช้รหัสผ่านได้อย่างไร


32

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]

คุณควร (IMHO) ทำสิ่งนี้กับผู้ใช้ทั้งหมด ... การกำหนดค่าอย่างง่าย ๆ เมื่อทำเพื่อ sshd ทั้งหมด
Skaperen

passwd -uเป็นความคิดที่ไม่ดี ดูคำตอบโดย Giles bellow
ปีเตอร์เจนกินส์

คำตอบ:


15

ปลดล็อกบัญชีและให้รหัสผ่านที่ซับซ้อนแก่ผู้ใช้ตามที่ @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

ผมประทับใจ Miro ต้องการที่จะปิดการใช้งานรหัสผ่านเพียงหนึ่งในการใช้งาน แต่ดูความคิดเห็นก่อนหน้าของฉัน
Skaperen

@Skaperen - คุณพูดถูก ฉันเปลี่ยนคำตอบเล็กน้อย
garethTheRed

Matchไวยากรณ์นั้นดูดี แต่ฉันจะลองทำมันย้อนกลับ เปิดใช้งานการเข้าสู่ระบบด้วยรหัสผ่านสำหรับผู้ใช้ (ไม่กี่คน)
kravemir

@Miro - เป็นความคิดที่ดีฉันได้เพิ่มคำตอบของฉันสำหรับการอ้างอิงในอนาคต
garethTheRed

37

ไม่ว่าคุณจะทำอะไรอย่าปล่อยให้บัญชีอยู่ในสถานะที่ปล่อยทิ้งไว้โดยpasswd -uใช้ช่องว่างของรหัสผ่าน: อนุญาตการเข้าสู่ระบบโดยไม่ต้องป้อนรหัสผ่าน (ยกเว้นผ่าน SSH เพราะ SSH ปฏิเสธว่า)

เปลี่ยนบัญชีให้ไม่มีรหัสผ่าน แต่ถูกปลดล็อค บัญชีไม่มีรหัสผ่านหากการแฮรหัสผ่านในฐานข้อมูลรหัสผ่านไม่ใช่การแฮชของสตริงใด ๆ ตามเนื้อผ้าสตริงหนึ่งอักขระเช่น*หรือ!ใช้สำหรับการที่

บัญชีที่ล็อคไว้ยังใช้ตัวทำเครื่องหมายพิเศษในช่องรหัสผ่านที่ทำให้สตริงไม่เป็นแฮชของสตริงใด ๆ เครื่องหมายขึ้นอยู่กับระบบ บน Linux, passwdเครื่องหมายคำสั่งล็อครหัสผ่านโดยการวาง!ที่จุดเริ่มต้นและ OpenSSH !ถือว่าบัญชีเป็นล็อคถ้าสนามเริ่มต้นด้วย ตัวแปร Unix อื่น ๆ มีแนวโน้มที่จะใช้กลไกที่คล้ายกัน แต่ไม่เหมือนกันดังนั้นโปรดระวังถ้าฐานข้อมูลรหัสผ่านของคุณถูกแชร์ในเครือข่ายที่ต่างกัน

บน Linux คุณสามารถปิดใช้งานการเข้าถึงโดยใช้รหัสผ่านของบัญชีในขณะที่อนุญาตการเข้าถึง SSH (ด้วยวิธีการรับรองความถูกต้องอื่น ๆ โดยทั่วไปจะเป็นคู่ที่สำคัญ) ด้วย

usermod -p '*' username

ผู้ใช้จะไม่สามารถเปลี่ยนบัญชีกลับเป็นรหัสผ่านได้เนื่องจากต้องให้พวกเขาป้อนรหัสผ่านที่ถูกต้อง

หากคุณต้องการคุณสามารถกำหนดค่า SSH แทนปฏิเสธการรับรองความถูกต้องรหัสผ่านโดยไม่คำนึงว่าบัญชีนั้นมีรหัสผ่านหรือไม่ คุณยังจะต้องจัดการให้ SSH ไม่พิจารณาบัญชีที่จะถูกล็อคดังนั้นตัวอย่างเช่นบน Linux คุณจะต้องลบออก!จากช่องรหัสผ่าน (แต่อย่าทำให้ช่องว่าง - ตั้ง*เป็นตามที่อธิบายไว้ข้างต้น ) หากต้องการปิดใช้งานการรับรองความถูกต้องของรหัสผ่านสำหรับ SSH ให้เพิ่มPasswordAuthenticationคำสั่ง/etc/sshd_configหรือ/etc/ssh/sshd_config(แล้วแต่ว่ามันจะอยู่ในระบบของคุณ) ใช้Matchบล็อกเพื่อทำให้คำสั่งนั้นใช้กับผู้ใช้เฉพาะเท่านั้น Matchบล็อกจะต้องปรากฏขึ้น

…
Match User username
    PasswordAuthentication no

6
ขอบคุณ - usermod -p '*' usernameใช้เสน่ห์!
Homme Zwaagstra

1
opensshd ไม่อนุญาตให้ผู้ใช้ล็อค (เช่นกัญชารหัสผ่านที่มี!คำนำหน้า) เพื่อเข้าสู่ระบบด้วยวิธีการตรวจสอบอื่น ๆ ถ้าตั้งอยู่ในUsePAM yes sshd_configนี่อาจเป็นค่าเริ่มต้นที่มีการแจกแจงส่วนใหญ่ (เช่นกับ Fedora)
maxschlepzig

1
ฉันมีระบบฝังตัวที่ไม่มี PAM ดังนั้นความแตกต่างของ'*'vs. '!'จึงมีประโยชน์มาก
jpkotta

8

คุณไม่จำเป็นต้องเปิดใช้งานหรือตั้งรหัสผ่านและคุณไม่ควรใช้จริงๆถ้าคุณใช้คีย์ที่แข็งแกร่งอยู่แล้ว เพียงล็อคบัญชีของคุณอีกครั้ง (sudo passwd -l ชื่อผู้ใช้) จากเซสชันที่มีอยู่และแก้ไขการกำหนดค่า SSH ของคุณ

เหตุผลที่สิ่งนี้เกิดขึ้นอาจเป็นเพราะคุณได้แก้ไขการตั้งค่าเริ่มต้น SSH daemon (ใน / etc / ssh / sshd_config)

เปลี่ยนค่านี้ใน / etc / ssh / sshd_config และรีสตาร์ท SSH:

UsePAM yes

โดยทั่วไปแล้วถ้าคุณไม่มีเหตุผลที่ดีในการปิดการใช้งาน PAM ฉันขอแนะนำให้คุณเปิดใช้งาน การเปิดใช้งาน PAM ภายใน SSH จะช่วยให้คุณยังสามารถเข้าสู่ระบบได้แม้ว่าจะลบรหัสผ่านแล้วก็ตาม ไม่ว่าคุณจะทำอะไรอย่าตั้งค่ารหัสผ่านที่ว่างเปล่าหรือสิ่งที่คล้ายกัน ... การล็อคช่องรหัสผ่านไม่จำเป็นต้องล็อคบัญชีทั้งหมดของคุณ

เคล็ดลับด่วนเมื่อล้อเล่นกับ SSH: เปิดเซสชันอื่นไว้ (ในหน้าต่างอื่น) เมื่อใดก็ตามที่มีการเปลี่ยนแปลงการกำหนดค่า SSH ของคุณจากนั้นทดสอบว่าคุณยังสามารถเข้าสู่ระบบได้ หากคุณหยุดการเข้าถึงโดยไม่ตั้งใจให้ใช้เซสชันปัจจุบันของคุณเพื่อแก้ไข

(ข้อจำกัดความรับผิดชอบ: ฉันทำงานที่ Userify ซึ่งให้ซอฟต์แวร์การจัดการคีย์ SSH)


0

ฉันมีปัญหานี้ใน CentOS 7 ฉันเป็นผู้ใช้ 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/


โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.