AuthorizedKeysFile sshd_config-ში: ტოკენები, ბილიკები და ტესტირება

AuthorizedKeysFile sshd-ს ეუბნება, სად მოძებნოს საჯარო გასაღებები, რომლებითაც მომხმარებელს სისტემაში შესვლის უფლება აქვს. თუ მას არასდროს დააყენებ, OpenSSH მომხმარებლის home საქაღალდეში ამოწმებს .ssh/authorized_keys და .ssh/authorized_keys2 ფაილებს, თუმცა ბევრი დისტრიბუცია ისეთ კონფიგურაციას აწვდის, რომელიც მხოლოდ პირველით შემოიფარგლება. მას სამი მიზეზით ცვლი: რომ გასაღებები მომხმარებლების ხელიდან root-ის საკუთრებაში მყოფ საქაღალდეში გადაიტანო, მაგალითად /etc/ssh/authorized_keys/%u, რომ გასაღებები home საქაღალდის მიმაგრებამდეც იკითხებოდეს, ან რომ ანგარიშების ერთ ჯგუფს Match ბლოკით გასაღებების სხვა წყარო მისცე.

პარამეტრი მოკლეა, მაგრამ შეცდომის შედეგი - არა. თუ მას იქ მიუთითებ, სადაც sshd არასაიმედოდ მიიჩნევს, ან დაგავიწყდება, რომ ის ნაგულისხმევს ანაცვლებს და არ ემატება, მანქანაზე გასაღებით შესვლა ერთბაშად შეწყდება - შენიც. ეს პოსტი განიხილავს, რას იღებს დირექტივა, როგორ ააგო გასაღებების ცენტრალური საქაღალდე, რომელიც StrictModes-ს გაივლის, როგორ ურთიერთქმედებს ის sshd_config.d-სა და Match-თან და როგორ დაამტკიცო, რომ ცვლილება მუშაობს, სანამ იმ სესიას დახურავ, რომელზეც დაყრდნობილი ხარ. გასაღებების გენერაცია, აგენტები და უსაფრთხოების გაძლიერების ზოგადი სია აღწერილია პოსტში SSH keys and sshd_config hardening; აქ მხოლოდ ეს ერთი დირექტივაა, სიღრმისეულად.

რას აკეთებს AuthorizedKeysFile და რა არის მისი ნაგულისხმევი მნიშვნელობა#

საჯარო გასაღებით ავთენტიფიკაციისას კლიენტი საჯარო გასაღებს გვთავაზობს, sshd კი ამ გასაღებს AuthorizedKeysFile-ში მითითებულ ფაილებში ეძებს, თანმიმდევრობით. იგებს პირველი ფაილი, რომელიც შესაბამის ხაზს შეიცავს, და ამ ხაზის დასაწყისში მდგარი პარამეტრები (restrict, from=, command= და სხვა) სესიაზე გავრცელდება. თუ ჩამოთვლილ ფაილებში გასაღები არ არის, ის უარყოფილია და კლიენტი შემდეგ გასაღებზე ან მეთოდზე გადადის.

OpenSSH-ის მიმდინარე ვერსიაში ჩაშენებული ნაგულისხმევი მნიშვნელობაა:

AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

რეალურად რას მიიღებ, დამოკიდებულია მოწოდებულ კონფიგურაციის ფაილზე:

authorized_keys2 SSH-ის პროტოკოლის 1-დან 2-ზე გადასვლის ნაშთია და ოც წელზე მეტია მოძველებულად ითვლება. მასში გასაღებებს არავინ უნდა დებდეს, და სწორედ ამიტომ ღირს მისი გამორიცხვა: ფაილი, რომელსაც არავინ უყურებს, კარგი ადგილია იმისთვის, ვინც მცირე ხნით shell-ზე მოხვდა და გასაღები დატოვა. მნიშვნელობის პირდაპირ .ssh/authorized_keys-ზე დაყენება Debian-სა და Ubuntu-ზე მცირე და უსაფრთხო გაუმჯობესებაა.

კიდევ ორი მნიშვნელობა დასაშვებია. none ფაილზე დაფუძნებულ გასაღებებს მთლიანად გამორთავს, რაც აზრიანია მხოლოდ მაშინ, როცა გასაღებები AuthorizedKeysCommand-იდან მოდის (ქვემოთ განვიხილავთ) ან ავთენტიფიკაცია სერტიფიკატით ხდება. და რადგან დირექტივა Match-ის შიგნითაც შეიძლება გამოჩნდეს, მნიშვნელობა მომხმარებლის, ჯგუფის ან წყარო მისამართის მიხედვით შეიძლება განსხვავდებოდეს.

გასაღებების ფაილის შიგთავსის ცვლილება შემდეგი შესვლისას ძალაში შედის reload-ის გარეშე, რადგან sshd ფაილს ავთენტიფიკაციის მომენტში კითხულობს. თვით AuthorizedKeysFile დირექტივის ცვლილებისთვის კი sshd-ს კონფიგურაციის თავიდან ჩატვირთვა სჭირდება.

ბილიკები და ტოკენები %h, %u, %U და %%#

ტოკენების გაშლის შემდეგ თითოეული მნიშვნელობა აღიქმება ან აბსოლუტურ ბილიკად, ან მომხმარებლის home საქაღალდესთან შედარებით ბილიკად. სწორედ ამიტომ მუშაობს მარტივი .ssh/authorized_keys: მის წინ home საქაღალდე იგულისხმება.

%U-ს OpenSSH-ის მიმდინარე გამოშვებები იღებს; ძველები მხოლოდ %h-ს, %u-სა და %%-ს იცნობს, ამიტომ დაყრდნობამდე მანქანაზე man sshd_config შეამოწმე. home საქაღალდე იკითხება პაროლების ბაზიდან (/etc/passwd ან LDAP NSS-ის გავლით), და არა $HOME-დან, ამიტომ მომხმარებელი მას გარემოს ცვლადით ვერ გადაამისამართებს.

რამდენიმე ეკვივალენტური და არაეკვივალენტური ფორმა, რადგან განსხვავებები ხშირად ცდუნებს ადამიანებს:

# These two are the same fileAuthorizedKeysFile .ssh/authorized_keysAuthorizedKeysFile %h/.ssh/authorized_keys# Absolute, one file per user, outside the home directoryAuthorizedKeysFile /etc/ssh/authorized_keys/%u# Not what it looks like: relative to the home directory, so /home/alice/etc/keysAuthorizedKeysFile etc/keys

ტილდა ამ დირექტივაში ტოკენი არ არის. როცა home საქაღალდე იგულისხმება, %h დაწერე. და %u უცვლელად გამოიყენება, ამიტომ მომხმარებლის სახელი, რომელშიც არის სიმბოლოები, რომლებიც შენს ფაილურ სისტემას არ მოსწონს (იშვიათია, მაგრამ LDAP და Active Directory ანგარიშებს ზოგჯერ დომენის სუფიქსი აქვს), ფაილის სახელის ნაწილი გახდება. გაშლილი ბილიკი ქვემოთ აღწერილ debug გამოტანაში ნახე და ვარაუდს ნუ დაეყრდნობი.

რამდენიმე ფაილის ჩამოთვლა#

რამდენიმე ბილიკი ერთ ხაზზე იწერება, ჰარებით გამოყოფილი. ისინი თანმიმდევრობით იძებნება და პირველი დამთხვევა იგებს.

AuthorizedKeysFile /etc/ssh/authorized_keys/%u .ssh/authorized_keys

ასე გამოიყურება მიგრაცია. ცენტრალურად მართული გასაღებები - შენ, კონფიგურაციის მართვის სისტემა ან provisioning სკრიპტი რომ მართავს - /etc/ssh-ში ინახება, და თითოეული მომხმარებლის საკუთარი ფაილი კვლავ მუშაობს, სანამ ხალხს გადაიყვან. არარსებული ფაილი შეცდომა არ არის: sshd ამას debug დონეზე აღნიშნავს და შემდეგს ცდის. ამიტომ პარამეტრი ფლოტზე შეგიძლია გაავრცელო, სანამ ყველა მომხმარებელს ცენტრალური ფაილი ექნება.

რიგს მნიშვნელობა ერთ სიტუაციაში აქვს. თუ ერთი და იგივე გასაღები ორივე ფაილშია და პარამეტრები განსხვავებულია, წყვეტს პირველი ფაილის ხაზი. ცენტრალურ ფაილში from=-ით შეზღუდულ გასაღებს მომხმარებლის საკუთარ ფაილში არსებული შეუზღუდავი ასლი არ შეარბილებს, რადგან ძებნა პირველ დამთხვევაზე წყდება - მაგრამ საპირისპიროც მართალია, ამიტომ ფაილი, რომელსაც შენ აკონტროლებ, პირველ ადგილზე დააყენე.

დირექტივის მთავარი შედეგია ის, რომ ის ნაგულისხმევს ანაცვლებს. თუ მხოლოდ AuthorizedKeysFile /etc/ssh/authorized_keys/%u-ს დააყენებ, მანქანაზე ყველა ~/.ssh/authorized_keys შემდეგი reload-იდან უგულებელყოფილია. თუ შენი გასაღები მხოლოდ home საქაღალდეშია, თავი ახლახან გარეთ გამოიკეტე. ცვლილების დროს ორივე ბილიკის ჩამოთვლა ყველაზე იაფი დაზღვევაა.

ცენტრალური, root-ის საკუთრებაში მყოფი გასაღებების საქაღალდე#

AuthorizedKeysFile-ის შეცვლის მთავარი მიზეზი კონტროლია. ნაგულისხმევით ნებისმიერ მომხმარებელს საკუთარ ფაილში გასაღებების დამატება შეუძლია, ანუ ყველას, ვინც ოდესმე ამ მომხმარებლის სახელით shell-ზე იყო, შეუძლია სამუდამო უკანა კარი დატოვოს, და ყოველ აუდიტზე home საქაღალდეებში მიმოფანტული ფაილების წაკითხვა გიწევს. root-ის საკუთრებაში მყოფი საქაღალდე კითხვას "ვის შეუძლია ვინ იყოს" ერთ ადგილას ამყოფებს, სადაც ის მხოლოდ root-ით ან შენი კონფიგურაციის მართვით იცვლება.

ის ორ პრაქტიკულ პრობლემასაც წყვეტს: ქსელურ საცავზე მყოფი home საქაღალდეები, რომლებიც შესვლის შემდეგ მიმაგრდება, და დაშიფრული home საქაღალდეები, რომლებიც არ იკითხება, სანამ მომხმარებელი პაროლით არ ავთენტიფიცირდება. /home-ს გარეთ მყოფი გასაღებების ფაილი ავთენტიფიკაციის მომენტში ყოველთვის იკითხება.

სტრუქტურა:

$ sudo mkdir -p /etc/ssh/authorized_keys$ sudo chown root:root /etc/ssh/authorized_keys$ sudo chmod 755 /etc/ssh/authorized_keys$ sudo cp /home/alice/.ssh/authorized_keys /etc/ssh/authorized_keys/alice$ sudo chown root:root /etc/ssh/authorized_keys/alice$ sudo chmod 644 /etc/ssh/authorized_keys/alice

644 ის ნაწილია, რომელშიც ადამიანები ცდებიან, და ის ინტუიციის საწინააღმდეგოა. sshd გასაღებების ფაილებს სამიზნე მომხმარებლის უფლებებით კითხულობს და არა root-ით. ფაილი, რომელიც root:root 600-ია, alice-სთვის წაუკითხავია და, შესაბამისად, sshd-ისთვისაც, როცა ის მის გასაღებს ამოწმებს, ამიტომ შესვლა ვერ ხერხდება. საჯარო გასაღებები საჯაროა; ფაილის ყველასთვის წაკითხვადობა არაფერს ამხელს, რისი გამოყენებაც თავდამსხმელს შეუძლია. რაც არ უნდა მოხდეს, ისაა, რომ მომხმარებელმა ან სხვამ ფაილში ჩაწერა შეძლოს.

საკუთრების ორი მისაღები მოდელია:

• root:root, რეჟიმი 644. მომხმარებელს თავისი გასაღებების წაკითხვა შეუძლია, მაგრამ შეცვლა - არა. ცენტრალური საქაღალდის აზრი სწორედ ესაა.
• მომხმარებლის საკუთრებაში, რეჟიმი 600 ან 644, root-ის საკუთრებაში მყოფ საქაღალდეში. მომხმარებელს საკუთარი ფაილის რედაქტირება შეუძლია, მაგრამ სხვებისთვის ფაილების შექმნა ან წაშლა - არა. შუალედური გზაა და უკან აბრუნებს თითქმის ყველაფერს, რისი წართმევაც გინდოდა.

გვერდითი ეფექტი, რომლის შესახებაც კოლეგებს უნდა აცნობო: ssh-copy-id მეორე მხარეს ~/.ssh/authorized_keys-ში წერს და შენი პარამეტრის შესახებ არაფერი იცის. ის წარმატებას გვატყობინებს, და თუ home ფაილი სიაში აღარ არის, მის მიერ დაყენებულ გასაღებს არავინ კითხულობს.

StrictModes და უფლებების შემოწმება#

StrictModes ნაგულისხმევად yes-ია და ასეც უნდა დარჩეს. ჩართულ მდგომარეობაში sshd გასაღებების ფაილის ნდობამდე ამოწმებს თვით ფაილს და ყველა საქაღალდეს მისკენ მიმავალ ბილიკზე. წესები მოკლედ:

თუ რამეს შემოწმება ვერ გაივლის, გასაღები უარყოფილია და კლიენტი მხოლოდ "Permission denied (publickey)"-ს ხედავს. რეალური მიზეზი სერვერის ლოგშია, ნაგულისხმევ დონეზე:

Authentication refused: bad ownership or modes for directory /home/alice

ეს შეტყობინება "ჩემი გასაღები აღარ მუშაობს" პრობლემის ყველაზე გავრცელებული მიზეზია, და ის, როგორც წესი, SSH-თან არაფერ კავშირში მყოფმა რამემ გამოიწვია: deploy სკრიპტმა, რომელმაც home საქაღალდეზე chmod -R 775 გაუშვა, საკონტროლო პანელის მიერ შექმნილმა ჯგუფისთვის ჩაწერადმა /home/alice-მა ან ცენტრალურმა საქაღალდემ, რომელიც არა-root ანგარიშმა შექმნა. გამოსწორება უფლებების გასწორებაა და არასდროს StrictModes no. შემოწმების გამორთვა ნიშნავს, რომ მომხმარებელს, რომლის home საქაღალდე ჯგუფისთვისაა ჩაწერადი, გასაღებებს ამ ჯგუფის ყველა წევრი ჩაუდებს.

ცენტრალური საქაღალდისთვის შემოწმებული ბილიკია /etc, /etc/ssh, /etc/ssh/authorized_keys და ფაილი. ჩვეულებრივ სისტემაზე პირველი ორი უკვე root:root 755-ია. პრობლემები ჩნდება, როცა საქაღალდე ნაკლებად მოწესრიგებულ ადგილასაა - /srv-ის ქვეშ, უცნაური უფლებებით მიმაგრებულ volume-ზე ან share-ზე, სადაც საკუთრება გადაისახება. Game server file permissions and ownership განმარტავს, როგორ წაიკითხო ls -l-ის გამოტანა, თუ რეჟიმები შენთვის თავისთავად გასაგები არ არის.

RHEL-ის ოჯახის სისტემებზე, სადაც SELinux enforcing რეჟიმშია, მეორე ბარიერიც არსებობს. home საქაღალდეში მყოფ გასაღებებს ssh_home_t ლეიბლი სჭირდება, რომელსაც ასლის ან აღდგენის შემდეგ restorecon -Rv ~/.ssh აგვარებს. /etc/ssh-ის ქვეშ მყოფი ფაილები ჩვეულებრივ ისეთ ლეიბლს იღებს, რომელსაც sshd კითხულობს. თუ სხვა ადგილს აირჩევ, სიმპტომი იგივეა: უარყოფილი შესვლა ფაილების სუფთა რეჟიმებით; შეამოწმე ausearch -m avc -ts recent და საქაღალდეს ლეიბლი semanage fcontext-ით მიანიჭე, SELinux-ის გამორთვის ნაცვლად.

sshd_config.d, Include და პირველი მნიშვნელობის უპირატესობა#

OpenSSH 8.2-იდან sshd_config-ს სხვა ფაილების Include-ით ჩართვა შეუძლია. Debian 12, Ubuntu 22.04 და უფრო ახალი, ასევე Fedora-სა და RHEL-ის ახალი გამოშვებები ისეთ მთავარ ფაილს აწვდის, რომლის დასაწყისის ხაზები /etc/ssh/sshd_config.d/*.conf-ს რთავს. ჩართული ფაილები ლექსიკოგრაფიული რიგით იკითხება, თითქოს Include-ის ხაზზე ჩაკვეთილიყოს.

ეს დააკავშირე sshd_config-ის ყველაზე მნიშვნელოვან წესთან: უმეტესი საკვანძო სიტყვისთვის გამოიყენება პირველად მიღებული მნიშვნელობა. /etc/ssh/sshd_config.d/10-local.conf-ში მყოფი პარამეტრი იგებს იმავე პარამეტრს მთავარ ფაილში ქვემოთ, და 10-local.conf იგებს 50-cloud-init.conf-ს, რადგან ის ადრე დალაგდება. როცა მთავარ ფაილს ცვლი და ცვლილებას ვერ ხედავ, თითქმის ყოველთვის ეს არის მიზეზი.

პრაქტიკული განლაგება:

# Central keys first, the user's own file as a fallback during migrationAuthorizedKeysFile /etc/ssh/authorized_keys/%u .ssh/authorized_keys

თითოეული საკითხი თავის პატარა, დანომრილ ფაილში გქონდეს. ერთის დაწერამდე ნახე, რა არის უკვე საქაღალდეში: cloud image-ები ხშირად ტოვებენ ფაილს, რომელიც ავთენტიფიკაციის პარამეტრებს ადგენს, და ეს ტესტირებამდე უნდა იცოდე. შემდეგ რიგის ხელით გარკვევის ნაცვლად ქვემოთ აღწერილ sshd -T-ს ენდე, რომ გითხრას, რამ გაიმარჯვა.

Match ბლოკები: სხვადასხვა გასაღები სხვადასხვა ანგარიშისთვის#

AuthorizedKeysFile იმ საკვანძო სიტყვებს შორისაა, რომლებიც Match ბლოკში დაშვებულია, ამიტომ გასაღებების წყარო მომხმარებლის, ჯგუფის, წყარო მისამართის ან ლოკალური პორტის მიხედვით შეიძლება განსხვავდებოდეს. Match ბლოკი გრძელდება შემდეგ Match-მდე ან იმ ფაილის დასასრულამდე, რომელშიცაა, ამიტომ ბლოკები ფაილის ბოლოს უნდა იყოს, ყველა გლობალური პარამეტრის შემდეგ. Match all ბლოკს აშკარად ასრულებს, თუ გლობალურ კონტექსტში დაბრუნება გჭირდება.

გავრცელებული შაბლონი: ჩვეულებრივი თანამშრომლები საკუთარ authorized_keys-ს ინარჩუნებენ, სერვისის ანგარიშები და მხოლოდ SFTP-ის მომხმარებლები კი გასაღებებს იღებენ, რომლებსაც მხოლოდ root ცვლის.

Match Group sftp-only    AuthorizedKeysFile /etc/ssh/authorized_keys/%u    ChrootDirectory /srv/sftp/%u    ForceCommand internal-sftp    AllowTcpForwarding noMatch User deploy,backup    AuthorizedKeysFile /etc/ssh/authorized_keys/%u

SFTP-ის შემთხვევა აჩვენებს, რატომ არის ეს წყვილი სასარგებლო. ავთენტიფიკაცია chroot-ის გამოყენებამდე ხდება, ამიტომ გასაღებების ფაილი სრულად იმ საქაღალდის გარეთაა, რომელსაც მომხმარებელი ხედავს. მას თავისი SFTP სესიის შიგნიდან საკუთარი გასაღებების წაკითხვა, შეცვლა ან დამატება არ შეუძლია, რასაც chroot-ის ქვეშ მყოფ home საქაღალდეში არსებული გასაღები დაუშვებდა.

გახსოვდეს, რომ Match-ის შიგნითაც პირველი მნიშვნელობის წესი იმ ბლოკზე მოქმედებს, რომელიც დაემთხვა. თუ ორივე Match ბლოკი ერთ მომხმარებელს ემთხვევა და ორივე AuthorizedKeysFile-ს ადგენს, უფრო ადრინდელი იგებს. შეამოწმე კონკრეტული მომხმარებელი და არა მხოლოდ ფაილი.

ტესტირება sshd -t და sshd -T-ით#

ორი ფლაგი, ორი დავალება. ორივეს root სჭირდება, რადგან sshd ტესტისთვისაც კი საკუთარი host გასაღებების წაკითხვას ცდილობს, და ორივე /usr/sbin/sshd-ზეა, რომელიც ჩვეულებრივი მომხმარებლის PATH-ში ყოველთვის არ არის.

sshd -t სინტაქსის შემოწმებაა. ის ყველა ფაილს არჩევს, ყოველ Include-ს ჩათვლით, და თუ კონფიგურაცია სწორია, უხმოდ სრულდება სტატუსით 0. არასწორად დაწერილი საკვანძო სიტყვა, საკვანძო სიტყვა, რომელიც Match-ში დაშვებული არ არის, ან წაუკითხავი host გასაღები შეცდომას და არანულოვან კოდს იძლევა. გაუშვი ყოველ reload-მდე, ყოველთვის.

sshd -T ბეჭდავს ეფექტურ კონფიგურაციას: ყველა საკვანძო სიტყვას, პატარა ასოებით, მას შემდეგ რაც ნაგულისხმევები, include-ები და პირველი მნიშვნელობის წესი გამოიყენება. ის ერთადერთი საიმედო პასუხია კითხვაზე "რას აპირებს sshd რეალურად". -C დაამატე, რომ Match ბლოკები კონკრეტული კავშირისთვის შეფასდეს:

$ sudo sshd -t && echo config okconfig ok$ sudo sshd -T | grep -i authorizedkeysfileauthorizedkeysfile /etc/ssh/authorized_keys/%u .ssh/authorized_keys$ sudo sshd -T -C user=deploy,host=laptop,addr=203.0.113.50 | grep -i authorizedkeysauthorizedkeysfile /etc/ssh/authorized_keys/%u

OpenSSH-ის ძველი ვერსიები -C-ში სამივეს - user, host და addr - ითხოვს; ახალი ვერსიები ქვეჯგუფსაც იღებს. სამივე მიუთითე და ყველგან იმუშავებს. გაითვალისწინე, რომ sshd -T ტოკენებს გაუშლელად აჩვენებს; გაშლა თითოეულ შესვლაზე ხდება.

რეალური შესვლის ახალ კონფიგურაციასთან საყურებლად, მომუშავე დემონის შეხების გარეშე, გაუშვი მეორე sshd debug რეჟიმში თავისუფალ პორტზე. ის ერთ კავშირს ემსახურება, ყველა გადაწყვეტილებას შენს ტერმინალში ბეჭდავს და სრულდება:

$ sudo /usr/sbin/sshd -d -p 2222$ ssh -p 2222 -i ~/.ssh/id_ed25519 alice@203.0.113.10   # from your own machine

debug გამოტანა ასახელებს თითოეულ გასაღებების ფაილს, რომელსაც ცდის, ამბობს, როცა რომელიმე აკლია, ზუსტად აჩვენებს უფლებების შეცდომას, და წარმატებისას ასახელებს ფაილსა და ხაზს, რომელიც დაემთხვა. ტესტისთვის firewall-ში პორტი 2222 გახსენი და მერე დახურე; ufw-ის გზამკვლევში ერთხაზიანი წესია. -f-ით მითითებული კონფიგურაცია ასევე შეიძლება ისევე გატესტდეს, სანამ ადგილზე გადაიტანება.

უსაფრთხო reload და აღდგენა#

რიგი, რომელიც არავის კეტავს გარეთ:

1. სერვერზე უკვე გახსნილი root shell შეინახე. არ დახურო, სანამ მე-5 ნაბიჯი არ დასრულდება.
2. შექმენი ცენტრალური ფაილი, გადაიტანე მასში გასაღებები და დააყენე საკუთრება და რეჟიმები ზემოთ აღწერილი სახით.
3. დირექტივა sshd_config.d-ში საკუთარ ფაილში ჩაწერე და ძველი მდებარეობაც ჩამოთვალე.
4. გაუშვი sudo sshd -t, შემდეგ sudo sshd -T -C-ით ერთი დაზარალებული მომხმარებლისთვის მაინც.
5. გააკეთე reload, შემდეგ მეორე ტერმინალიდან გახსენი ახალი კავშირი ყოველი სახის დაზარალებული ანგარიშით.

$ sudo sshd -t && sudo systemctl reload ssh     # Debian, Ubuntu$ sudo sshd -t && sudo systemctl reload sshd    # RHEL, Rocky, Alma, Fedora

reload აგზავნის SIGHUP-ს; მოსმენადი დემონი კონფიგურაციას თავიდან კითხულობს და არსებული სესიები შეუწუხებლად გრძელდება. თანამედროვე systemd unit-ებზე restart-იც კი არ წყვეტს უკვე დამყარებულ სესიებს, მაგრამ reload უფრო ფრთხილი ჩვევაა. && მნიშვნელოვანია: თუ სინტაქსის შემოწმება ჩავარდა, არაფერი იტვირთება.

როცა რამე ცუდად მიდის, ღია სესია არის გამოსავალი: დააბრუნე ფაილი, sshd -t, reload. მის გარეშე შენი პროვაიდერის კონსოლი ან rescue რეჟიმი დაგჭირდება, და სწორედ ამიტომ გირჩევს პირველი საათი ახალ VDS-ზე მის პოვნას, სანამ საჭირო გახდება. უკან დაბრუნების შემდეგ მიზეზები თითქმის ყოველთვის journalctl -u ssh-შია (ან -u sshd): უფლებების უარყოფა, ფაილი არასწორ ბილიკზე, ან ძველი მდებარეობა, რომელიც სიიდან უხმაუროდ ამოვარდა.

ფაილების მიღმა: AuthorizedKeysCommand#

როცა გასაღებების სია დირექტორიის სერვისში, ბაზაში ან ფლოტის ხელსაწყოში ინახება, ყოველ მანქანაზე ფაილების ჩაწერა არასწორი ფორმაა. AuthorizedKeysCommand უშვებს პროგრამას, რომელიც ავტორიზებულ გასაღებებს სტანდარტულ გამოტანაზე ბეჭდავს, ფაილის იმავე ფორმატში, და AuthorizedKeysCommandUser ასახელებს არაპრივილეგირებულ ანგარიშს, რომლითაც ის გაიშვება. ბრძანებაც და ფაილებიც გამოიყენება, ამიტომ ლოკალურ break-glass გასაღებს ფაილში შეგიძლია ინახავდე, ყოველდღიური გასაღებები კი ბრძანებიდან მოდიოდეს. პროგრამა და მისი საქაღალდე root-ის საკუთრებაში უნდა იყოს და სხვას ჩაწერა არ უნდა შეეძლოს, იგივე პრინციპი, რაც ცენტრალური საქაღალდისთვის. ასე აწვდის SSSD გასაღებებს LDAP-იდან ან FreeIPA-დან.

რამდენიმე ადამიანზე და მანქანაზე მეტისთვის SSH სერტიფიკატები (TrustedUserCAKeys) თითოეული სერვერის გასაღებების სიას სრულად აცილებს, როგორც უსაფრთხოების გაძლიერების პოსტი აღწერს. AuthorizedKeysFile რჩება სწორ ხელსაწყოდ პატარა ფლოტისთვის, ერთი VDS-ისთვის ან break-glass გასაღებისთვის, რომელიც უნდა მუშაობდეს, როცა ყველა ჭკვიანური რამ მოშლილია. და LogLevel VERBOSE ჩართული გქონდეს, რომ ყოველი შესვლა გამოყენებული გასაღების თითის ანაბეჭდს ინახავდეს - ლოგები, რომლებიც შესანახია ამ ხაზების შენახვას განიხილავს.

RE:NODE-ზე ეს მხოლოდ VDS-ის საკითხია. თამაშის, აპლიკაციისა და ვებ სერვერებს SSH დემონი არ აქვთ, რომელიც შენ უნდა გააწყო: ფაილებზე წვდომა SFTP-ით ხდება, თითოეული სერვერისთვის გაცემული მონაცემებით, და კონსოლი პანელშია, როგორც SFTP და ფაილების მენეჯერი აღწერს. VDS root-ს და მთელ sshd_config-ს გაძლევს, ზემოთ ჩამოთვლილი ყველა პარამეტრის ჩათვლით, და მათი გატესტვის პასუხისმგებლობასაც.

FAQ#

გასაღების authorized_keys-ში დამატების შემდეგ sshd-ის restart მჭირდება?

არა. ფაილი ყოველ ავთენტიფიკაციაზე იკითხება, ამიტომ ახალი ხაზი შემდეგ კავშირზე მუშაობს. reload მხოლოდ მაშინ გჭირდება, როცა თვით AuthorizedKeysFile-ს ან კონფიგურაციის სხვა დირექტივას ცვლი.

რატომ მუშაობს ჩემი ცენტრალური გასაღებების ფაილი root-ისთვის, მაგრამ სხვა მომხმარებლებისთვის - არა?

თითქმის ყოველთვის იმიტომ, რომ ფაილი 600-ია და root-ის საკუთრებაშია. sshd მას შემსვლელი მომხმარებლის უფლებებით ხსნის, ამიტომ ამ მომხმარებელს წაკითხვა უნდა შეეძლოს. გახადე 644 და root-ის საკუთრებაში დატოვე; მომხმარებელს თავისი საჯარო გასაღებების წაკითხვა შეუძლია, მაგრამ შეცვლა - არა.

შეუძლია თუ არა მომხმარებელს კვლავ საკუთარი გასაღებების დამატება, როცა /etc/ssh/authorized_keys/%u-ზე გადავალ?

მხოლოდ მაშინ, თუ .ssh/authorized_keys ჯერ კიდევ სიაშია. როცა ცენტრალური ბილიკი ერთადერთი ჩანაწერია, მომხმარებელს home საქაღალდეში ნებისმიერი რამის ჩაწერა შეუძლია და sshd მას არასდროს წაიკითხავს. სწორედ ეს არის დაგეგმილი შედეგი, ამიტომ ხალხს წინასწარ უთხარი.

უნდა დავაყენო თუ არა StrictModes no, როცა გასაღები უარყოფილია?

არა. უარყოფა რეალურ პრობლემაზე მიუთითებს: home საქაღალდე, .ssh საქაღალდე ან გასაღებების ფაილი, რომელშიც მომხმარებლის გარდა სხვას შეუძლია ჩაწერა. გაასწორე ლოგში დასახელებული საკუთრება ან რეჟიმი და გასაღები იმუშავებს, ხოლო შემოწმება კვლავ გიცავს.

გავლენას ახდენს თუ არა AuthorizedKeysFile SFTP-ით შესვლაზე?

დიახ. SFTP SSH-ზე მუშაობს და იმავე გზით ავთენტიფიცირდება, ამიტომ იგივე ფაილები იძებნება. Match ბლოკისა და ChrootDirectory-ს შემთხვევაში chroot-ის გარეთ მყოფი გასაღებები ჩვეულებრივი მოწყობაა, რადგან ავთენტიფიკაცია მომხმარებლის შეზღუდვამდე ხდება.

ღირს თუ არა authorized_keys2-ის ნაგულისხმევიდან ამოღება?

ეს ერთი ხაზის ცვლილებაა, ყველა თანამედროვე სისტემაზე ნაკლის გარეშე. ფაილს არაფერი კანონიერი არ უნდა იყენებდეს, და იქ დამალული გასაღები აუდიტზე ადვილად გამოგრჩება. AuthorizedKeysFile .ssh/authorized_keys პირდაპირ დააყენე და sshd -T-ით დაადასტურე.