วิธีที่สอดคล้องและปลอดภัยกับบัญชีที่ไม่มีรหัสผ่านด้วย SSH


13

ฉันต้องยอมรับว่าฉันชอบเซิร์ฟเวอร์ที่ไม่มีรหัสผ่านในบางกรณี เซิร์ฟเวอร์ทั่วไปมีความเสี่ยงต่อทุกคนที่มีสิทธิ์เข้าถึงแบบฟิสิคัล ดังนั้นในบางกรณีก็เป็นจริงเพื่อล็อคร่างกายและตั้งแต่นั้นมาไว้วางใจใด ๆการเข้าถึงทางกายภาพ

แนวคิดพื้นฐาน

ในทางทฤษฎีแล้วเมื่อฉันไปถึงเซิร์ฟเวอร์นั้นฉันควรจะสามารถบริหารงานโดยไม่ต้องใช้รหัสผ่านเพียงแค่พิมพ์rootเป็นชื่อล็อกอินและฉันไม่ควรขอรหัสผ่าน เช่นเดียวกันอาจนำไปใช้กับบัญชีผู้ใช้ แต่ไม่มีใครสามารถเข้าถึงได้จริง ดังนั้นจึงไม่จำเป็นต้องใช้รหัสผ่านระบบสำหรับการเข้าถึงภายใน (เป็นครั้งคราว)

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

# user=...
# 
# useradd -m "$user"
# sudo -i -u "$user"

$ keyurl=...
$
$ mkdir -p .ssh
$ curl -o .ssh/authorized_keys "$keyurl"

บทสรุปคือในทางทฤษฎีเราจะไม่ต้องใช้รหัสผ่านระบบใด ๆสำหรับกรณีการใช้งานเช่นนั้น ดังนั้นคำถามคือเราจะกำหนดค่าระบบและบัญชีผู้ใช้อย่างไรเพื่อให้เกิดขึ้นอย่างสอดคล้องและปลอดภัย

รายละเอียดการเข้าถึงท้องถิ่น

เราจะมั่นใจได้อย่างไรว่าบัญชีรูทสามารถเข้าถึงได้แบบโลคัลโดยไม่มีรหัสผ่าน? ฉันไม่คิดว่าเราสามารถใช้งานได้passwd -dเพราะจะทำให้การเข้าถึงรูทมากเกินไปและผู้ใช้ที่ไม่มีสิทธิสามารถเปลี่ยนเป็นรูทได้ฟรีซึ่งเป็นสิ่งที่ผิด เราไม่สามารถใช้passwd -lเนื่องจากป้องกันไม่ให้เราเข้าสู่ระบบ

โปรดทราบว่าการเข้าถึงเฉพาะที่เกี่ยวกับการเข้าถึงโดยใช้คีย์บอร์ดท้องถิ่น ดังนั้นโซลูชันที่ถูกต้องจะต้องไม่อนุญาตให้สลับผู้ใช้ (ไม่ว่าจะใช้suหรือsudo)

รายละเอียดการเข้าถึงระยะไกล

จนกระทั่งเมื่อไม่นานมานี้โซลูชันดังกล่าวจะใช้งานได้ แต่ตอนนี้ SSH เริ่มตรวจสอบบัญชีผู้ใช้ที่ถูกล็อค เราอาจไม่สามารถใช้passwd -dด้วยเหตุผลเดียวกัน เราไม่สามารถใช้passwd -uเพราะมันบ่นว่ามันจะนำไปสู่สิ่งที่passwd -dทำ

มีวิธีแก้ปัญหาด้วยรหัสผ่านจำลองสำหรับส่วนนี้

user=...

echo -ne "$user:`pwgen 16`\n" | chpasswd

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

หมายเหตุสุดท้าย

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

คำตอบที่ได้รับการยอมรับและได้รับรางวัลอาจจะหรืออาจไม่อธิบายการกำหนดค่าโดยละเอียดของเครื่องมือแต่ละอย่าง แต่ต้องมีประเด็นสำคัญเพื่อให้บรรลุเป้าหมายที่ระบุไว้ ทราบว่านี้อาจจะไม่สามารถแก้ไขได้ผ่านการใช้งานทั่วไปของเครื่องมือเช่นpasswd, ssh, su, sudoและชอบ

แนวคิดเพิ่มเติมหลังจากอ่านคำตอบแรก

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


ใช้การกำหนดค่า PAM ที่กำหนดเองสำหรับการเข้าถึงในพื้นที่โดยไม่มีรหัสผ่านและทำเช่นเดียวกันสำหรับการเข้าสู่ระบบ sudo และ SSH
0xC0000022L

คำตอบ:


5

ข้อกำหนดที่ฉันจะนำเสนอโซลูชั่นตามหัวข้อย่อย:

  1. การล็อกอินคอนโซลรูทที่ไม่มีรหัสผ่าน
  2. การล็อกอินรีโมตรูทแบบไม่มีรหัสผ่านจากผู้ใช้ที่ได้รับอนุญาตล่วงหน้า
  3. การลงชื่อเข้าใช้จากระยะไกลแบบไม่มีรหัสผ่านสำหรับบัญชีที่ระบุจากผู้ใช้ที่ได้รับอนุญาตล่วงหน้า
  4. การลงชื่อเข้าใช้จากระยะไกลแบบไม่มีรหัสผ่านสำหรับบัญชีใด ๆ จากผู้ใช้ที่ได้รับอนุญาตล่วงหน้า

ตัวอย่างต่อไปนี้มาจาก Debian เนื่องจากเป็นสิ่งที่ฉันได้มาที่นี่เพื่อทดสอบ อย่างไรก็ตามฉันไม่เห็นเหตุผลใด ๆ ว่าทำไมหลักการไม่สามารถนำไปใช้กับการแจกแจงใด ๆ

การล็อกอินคอนโซลรูทที่ไม่มีรหัสผ่าน

ฉันคิดว่าวิธีที่ฉันจะเข้าใกล้สิ่งนี้คือการใช้ประโยชน์จาก PAM และ/etc/securettyไฟล์กำหนดค่า

จำเป็นต้องมีการตั้งค่ารหัสผ่านรูท "ปลอดภัยอย่างเพียงพอ" ก่อน สิ่งนี้ไม่จำเป็นสำหรับการเข้าสู่ระบบคอนโซล แต่มีอยู่เพื่อทำให้ความพยายามในการแคร็กกำลังเกิดขึ้นจริง บัญชีนั้นเป็นบัญชีรูทปกติที่สมบูรณ์แบบ

ใน/etc/pam.d/loginฉันมีชุดบรรทัดมาตรฐานต่อไปนี้สำหรับการตรวจสอบ (ผู้ที่เริ่มต้นด้วยคำหลักauth):

auth       optional   pam_faildelay.so  delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth       requisite  pam_nologin.so

@include common-auth
auth       optional   pam_group.so

common-authไฟล์ include ที่อ้างถึงมีบรรทัดที่เกี่ยวข้องดังต่อไปนี้:

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

common-authไฟล์สั่ง PAM ที่จะข้ามกฎหนึ่ง (ปฏิเสธ) ถ้าเป็น "ยูนิกซ์เข้าสู่ระบบ" ประสบความสำเร็จ /etc/shadowซึ่งโดยปกติหมายถึงการแข่งขันใน

auth ... pam_securetty.soบรรทัดมีการกำหนดค่าเพื่อป้องกันไม่ให้เข้าสู่ระบบรากยกเว้นบนอุปกรณ์ TTY /etc/securettyที่ระบุไว้ใน (ไฟล์นี้มีอุปกรณ์คอนโซลทั้งหมดอยู่แล้ว)

โดยการปรับเปลี่ยนนี้authบรรทัดเล็กน้อยมันเป็นไปได้ที่จะกำหนดกฎที่อนุญาตให้เข้าสู่ระบบรากที่ไม่มีรหัสผ่านจากอุปกรณ์ tty /etc/securettyที่ระบุไว้ใน success=okความต้องการของพารามิเตอร์ที่จะได้รับการแก้ไขเพื่อให้okถูกแทนที่ด้วยจำนวนของauthสายที่จะถูกข้ามไปในกรณีที่มีการแข่งขันที่ประสบความสำเร็จ ในสถานการณ์ที่แสดงที่นี่ตัวเลขนั้นคือ3ซึ่งกระโดดลงไปที่auth ... pam_permit.soบรรทัด:

auth [success=3 new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so

การล็อกอินรีโมตรูทแบบไม่มีรหัสผ่านจากผู้ใช้ที่ได้รับอนุญาตล่วงหน้า

นี่คือการรวมคีย์ ssh ที่ตรงไปตรงมาสำหรับผู้ใช้ที่ได้รับอนุญาตที่ถูกเพิ่มเข้าไปในauthorized_keysไฟล์รูท

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

นี่คือการรวมคีย์ ssh ที่ตรงไปตรงมาสำหรับผู้ใช้ที่ได้รับอนุญาตที่ถูกเพิ่มลงใน.ssh/authorized_keysไฟล์ของผู้ใช้ที่เหมาะสมและสอดคล้องกัน (โดยทั่วไปผู้ใช้ chris ระยะไกลต้องการลงชื่อเข้าใช้แบบไม่ต้องใช้รหัสผ่านกับสถานการณ์ผู้ใช้ในพื้นที่ Chris )

โปรดทราบว่าบัญชีสามารถอยู่ในสถานะล็อคเริ่มต้นหลังจากการสร้าง (เช่นมีเพียง!ในฟิลด์รหัสผ่านสำหรับ/etc/shadow) แต่อนุญาตให้เข้าสู่ระบบตามคีย์ SSH สิ่งนี้ต้องการรูทเพื่อวางคีย์ใน.ssh/authorized_keysไฟล์ของผู้ใช้ใหม่ สิ่งที่ไม่ชัดเจนคือวิธีนี้ใช้ได้เฉพาะเมื่อUsePAM Yesตั้งค่า/etc/ssh/sshd_configแล้ว PAM สร้างความแตกต่าง!ในฐานะ "บัญชีถูกล็อคด้วยรหัสผ่าน แต่อาจอนุญาตวิธีการเข้าถึงอื่น ๆ " และ!..."บัญชีถูกล็อกระยะเวลา" (หากUsePAM Noตั้งไว้ OpenSSH จะพิจารณาว่ามีการ!เริ่มต้นฟิลด์รหัสผ่านเพื่อแสดงบัญชีที่ถูกล็อค)

การลงชื่อเข้าใช้จากระยะไกลแบบไม่มีรหัสผ่านสำหรับบัญชีใด ๆ จากผู้ใช้ที่ได้รับอนุญาตล่วงหน้า

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

ฉันไม่สามารถทดสอบภาพจำลองนี้ แต่ผมเชื่อว่านี้สามารถทำได้ด้วย OpenSSH 5.9 หรือใหม่กว่าซึ่งอนุญาตให้หลายไฟล์ที่จะกำหนดไว้ในauthorized_keys แก้ไขไฟล์การกำหนดค่าที่จะรวมไฟล์ที่สองเรียกว่า/etc/ssh/sshd_config /etc/ssh/authorized_keysเพิ่มกุญแจสาธารณะของผู้ใช้ที่ได้รับอนุญาตที่คุณเลือกลงในไฟล์นี้เพื่อให้มั่นใจว่าสิทธิ์นั้นเป็นของรูทและมีสิทธิ์เข้าถึงเพื่อเขียนโดยรูท (0644)


ฉันจะต้องตรวจสอบ # 1 อย่างรอบคอบและทดสอบอีกครั้ง มันดูน่าสนใจมากถึงแม้ว่ามันจะยังต้องมีการกำหนดค่ารหัสผ่าน (รัดกุม) # 3 ไม่สมบูรณ์เนื่องจากทุกวันนี้ผู้ใช้ที่สร้างขึ้นใหม่จะถูกล็อคโดยค่าเริ่มต้นและจากการเข้าสู่ระบบ SSH ฉันไม่ได้ขอจุดที่ 4 แต่มันดูน่าสนใจมากและฉันอาจใช้วิธีดังกล่าวจริง ๆ แล้ว
Pavel Šimerda

ต้องใช้รหัสผ่านที่รัดกุมสำหรับรูท แต่ไม่เคยใช้ ฉันคิดว่าคุณรู้วิธีใช้ # 3; แจ้งให้เราทราบหากคุณต้องการรายละเอียดเพิ่มเติม บนระบบ (เดเบียน) เป็นไปได้ที่จะเข้าสู่บัญชีใหม่ที่ยังไม่ได้กำหนดรหัสผ่านโดยที่.ssh/authorized_keysไฟล์นั้นมีรหัสสาธารณะที่เกี่ยวข้อง สิ่งนี้ช่วยได้ไหม?
roaima

ฉันคิดว่าฉันต้องการวิธีที่ดีและเป็นมาตรฐานในการกู้คืนพฤติกรรมที่คุณเห็นใน Debian นั่นคือบัญชีที่สร้างขึ้นใหม่จะถูกล็อคสำหรับการตรวจสอบรหัสผ่านเท่านั้นและไม่ใช่สำหรับรหัสสาธารณะ
Pavel Šimerda

สำหรับบัญชีผู้ใช้ทดสอบที่ฉันสร้างขึ้นเพื่อยืนยันคำสั่ง SSH ในความคิดเห็นก่อนหน้าของฉันฉันเห็นเพียงครั้งเดียวในฟิลด์รหัสผ่านใน! /etc/shadowตามหน้า man นี่เป็นการระบุบัญชีที่ถูกต้องซึ่งไม่มีรหัสผ่านที่ตรงกัน
roaima

1
นั่นเป็นเรื่องที่น่าสนใจที่ไม่ชัดเจนอย่างน้อยจริงๆขอบคุณ
Pavel Šimerda

1

ดูเหมือนว่าคุณต้องการบัญชีผู้ใช้จริง (ไม่ใช่รูท) ที่มีคีย์ ssh และNOPASSWDการเข้าถึงอย่างเต็มรูปแบบผ่านทางsudo(ซึ่งมีให้โดยปริยายใน Linux distros ส่วนใหญ่ในทุกวันนี้และยังติดตั้งเองเล็กน้อย) คุณสามารถมีรหัสผ่านว่างเปล่าสำหรับแต่ละบัญชีผู้ใช้ (ซึ่งจะไม่ทำงานจากระยะไกล) จากนั้นผู้ใช้จะทำงานsudo -sหรือผู้ใช้~/.bash_profileเพียงแค่มีคำสั่งนั้น

sudo

เพิ่มผู้ใช้แต่ละคนลงในsudoกลุ่ม UNIX (เช่นusermod -a -G sudo USERNAMEแม้ว่าระบบเก่าจะมีวิธีที่ใช้งานง่ายกว่าในการทำสิ่งนี้กรณีที่แย่ที่สุดคือคุณแก้ไข/etc/groupsได้โดยตรง)

ใน/etc/sudoersหรือ/etc/sudoers.d/localคุณต้องการบรรทัดเช่นนี้:

%sudo    ALL=(ALL:ALL) NOPASSWD: ALL

หากคุณต้องการเข้าถึงรูทอัตโนมัติให้เพิ่มส่วนนี้ในโปรไฟล์ผู้ใช้ สำหรับbashที่จะเป็น~/.bash_profile:

sudo -s

วิธีนี้จะช่วยให้คุณเห็นว่าใครเข้าสู่ระบบ (ลองwhoหรือlast) และจะออกจาก/var/log/auth.logระบบ

เข้าสู่ระบบด้วยรหัสผ่าน

ในระบบเก่ามากคุณจะทำได้เพียงการแก้ไข/etc/passwd(หรือบนระบบเก่าเล็กน้อย/etc/shadow) และลบกัญชาดังนั้นเช่นกลายเป็นเพียงbob:$1$salt$hash:12345:0:99999:7::: bob::12345:0:99999:7:::นี่คือทั้งหมดที่คุณต้องการ ระบบสมัยใหม่ไม่ชอบสิ่งนี้ มีวิธีอื่นที่น่าจะทำได้ แต่วิธีที่ฉันเพิ่งตรวจสอบมีดังนี้(ที่มา: สิ่งของสุ่มของ Leo ) :

เปิด/etc/shadowและสังเกตบัญชีด้วยข้อมูลจริง สิ่งนี้จะรวมสามองค์ประกอบที่คั่นด้วยเครื่องหมายดอลลาร์ ( $) สิ่งเหล่านี้แสดงให้เห็นถึงกลไกการบดแล้วเกลือและกัญชา สังเกตเกลือจากนั้นเรียกใช้สิ่งนี้:

openssl passwd -1 -salt SALT

(นี่ใช้ MD5 เป็นกลไกการแฮชมันเป็นรหัสผ่านที่ว่างเปล่าดังนั้นคุณไม่ควรกังวล) เมื่อได้รับแจ้งให้ใส่รหัสผ่านให้กด Enter บันทึกสตริงนั้นรวมถึงจุดต่อท้ายและวางหลังเครื่องหมายโคลอนแรกบนบรรทัดของผู้ใช้ใน/etc/shadow(ซึ่งควรแทนที่เนื้อหาที่มีอยู่ก่อนระหว่างโคลอนแรกและโคลอนที่สอง) (โปรดอย่าใช้SALTเป็นเกลือของคุณอย่างแท้จริง!)

SSH

คุณsshกำหนดค่าภูตอาศัยอยู่ทั้งในหรือ/etc/sshd_config /etc/ssh/sshd_configเพื่อความปลอดภัยที่เหมาะสมฉันแนะนำให้รวมบรรทัดเหล่านี้:

PermitRootLogin no
PermitEmptyPasswords no

ดูการเขียนSecure Secure Shellสำหรับมาตรการความปลอดภัยเพิ่มเติมที่คุณสามารถเพิ่มลงในการกำหนดค่า ssh ของคุณเพื่อให้ดีขึ้นต่อผู้โจมตีที่ซับซ้อน

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

ผู้ใช้แต่ละคนสำหรับแต่ละระบบไคลเอนต์ควรสร้างคู่คีย์ ssh เช่น

ssh-keygen -t rsa -b 4096 -f $HOME/.ssh/id_rsa -o -a 100 -C "Bob Roberts on his laptop"

นี้ผลิตคีย์ส่วนตัวและคีย์สาธารณะที่$HOME/.ssh/id_rsa $HOME/.ssh/id_rsa.pubให้ผู้ใช้นั้นส่งกุญแจสาธารณะให้พวกเขาและส่งต่อให้กับเซิร์ฟเวอร์นี้$HOME/.ssh/authorized_keys(โปรดทราบว่าผู้ใช้แต่ละคน$HOME/.sshต้องเป็นโหมด 700 เช่นmkdir -p ~user/.ssh && chmod 700 ~user/.ssh)

ผู้ใช้ที่ไม่ต้องการคีย์ ssh สามารถเดินไปยังระบบทางกายภาพได้ ที่นั่นรหัสผ่านว่างเปล่าของพวกเขาจะเข้าสู่ระบบในจุดที่พวกเขาสามารถพิมพ์passwdจากเปลือกและตั้งรหัสผ่านจึงช่วยให้พวกเขาเข้าถึงระยะไกล

(จริง ๆ แล้วฉันใช้เทคนิคนี้เพื่อให้ผู้คนสามารถเข้าถึงกลุ่มของระบบต่าง ๆ เมื่อฉันเรียกใช้แผนก IT มันบังคับให้ผู้ใช้ใช้คีย์ ssh และฉันไม่ต้องให้รหัสผ่านพวกเขาตอนแรก~/.bash_profileมีสองบรรทัดที่ด้านล่าง: passwdจากนั้นmv ~/.bash_profile.real ~/.bash_profileจึงตั้งรหัสผ่านใหม่เมื่อเข้าสู่ระบบครั้งแรก)

ความเสี่ยง

คุณให้ความไว้วางใจอย่างเต็มที่กับผู้ใช้ของคุณ ไม่มีสิ่งใดที่จะหยุดผู้ใช้ไม่ให้ยุ่งกับ~/.ssh/authorized_keysไฟล์ของผู้ใช้คนอื่นและทำให้การเปลี่ยนความสามารถในการเพิกถอนและการเข้าถึงการตรวจสอบของคุณเป็นสิ่งที่หลีกเลี่ยงไม่ได้หากคุณให้สิทธิ์การเข้าถึงรูทแบบเต็ม

ข้อสรุป

ตอนนี้ผู้ใช้แต่ละคนเป็นสมาชิกของกลุ่มsudoและมีสิทธิ์เข้าถึงรหัสผ่านแบบเต็มไปยังรูทเชลล์ ผู้ใช้เหล่านี้ไม่มีรหัสผ่านสำหรับบัญชีของพวกเขาและสามารถเข้าสู่ระบบจากระยะไกลโดยใช้คีย์ ssh

หากคุณสูญเสียพนักงานคนหนึ่งของคุณคุณสามารถลบบัญชีของเขา / เธอ หากแล็ปท็อปของพนักงานของคุณถูกขโมยคุณสามารถลบคีย์ ssh ของแล็ปท็อปนั้นออกจากauthorized_keysไฟล์ของผู้ใช้นั้นได้ หากคุณมีการละเมิดความปลอดภัยคุณมีบันทึกแสดงว่าใครเข้าสู่ระบบ


ส่วนเกี่ยวกับsudoคิดถึงคำถามเนื่องจากเป็นเรื่องเกี่ยวกับการเข้าสู่ระบบใหม่เท่านั้นไม่ใช่การสลับผู้ใช้ แก้ไขคำถามเพื่อให้ชัดเจนยิ่งขึ้น ส่วนเกี่ยวกับการเข้าสู่ระบบแบบไม่ใช้รหัสผ่านจะแสดงพฤติกรรมที่ผิดพลาดเช่นเดียวpasswd -dกับคำถามทำให้suสามารถสลับไปใช้งานได้โดยไม่ต้องใช้รหัสผ่าน ส่วนความเสี่ยงอธิบายสองสิ่ง (ล้อเล่นกับข้อมูลของผู้ใช้รายอื่นและการเข้าถึงรูท) ซึ่งการลบเป็นจุดสำคัญของคำถาม ดังนั้นในขณะที่แต่ละส่วนมีการเขียนอย่างดีนี่คือไม่ตอบคำถาม
Pavel Šimerda

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