SSH გასაღებები და გამაგრება: sshd_config, agent, jump host

გავრცელებულ შემთხვევას სამი ბრძანება ფარავს. ssh-keygen -t ed25519 -a 100 ქმნის გასაღებს. ssh-copy-id deploy@203.0.113.10 აყენებს მას. PasswordAuthentication no სერვერის კონფიგურაციაში კარს შენს უკან კეტავს. გააკეთე ეს სამი და შენი სერვერი ვეღარ დაიშლება brute force-ით, რაც მასზე თავდასხმის ყველაზე დიდ კატეგორიას აქრობს, რადგან private გასაღებს ვერავინ გამოიცნობს.

ყველაფერი ამის შემდეგ იმაზეა, რომ გასაღებებთან ცხოვრება სასიამოვნო გახდეს და არა უფრო ძლიერი: ერთი გასაღები, რომელიც დღეში ერთხელ იხსნება, ორმოცჯერ აკრეფილი passphrase-ის ნაცვლად, კონფიგურაციის ფაილი, რომელიც გრძელ ბრძანებას მოკლე სახელად აქცევს, jump host, რომელიც საჯარო მისამართის არმქონე მანქანებამდე გიყვანს, და sshd_config-ის რამდენიმე პარამეტრი, რომლის შეცვლაც ღირს, იმ ორმოცის საპირისპიროდ, რომლებიც ბლოგპოსტებს შორის ახსნის გარეშე გადაიწერება.

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

რომელი გასაღების ტიპი და რატომ ed25519#

ed25519 საჯარო გასაღები ერთი მოკლე ხაზია, private გასაღები დაახლოებით 400 ბაიტია და არჩევანი ზომაზე არ არსებობს, რადგან მას მრუდი აფიქსირებს. -b დროშა ed25519-ისთვის ჩუმად იგნორირდება, რაც ზოგჯერ RSA ინსტრუქციის მიმდევრებს ბნევს.

ერთი ვერსიის დეტალი დამაბნეველ ჩავარდნას ხსნის. OpenSSH 8.8-მა ნაგულისხმევად გამორთო ssh-rsa ხელმოწერის ალგორითმი, რომელიც SHA-1-ს იყენებს. ეს ხელმოწერის ალგორითმია და არა გასაღების ტიპი: RSA გასაღები თანამედროვე სერვერთან მაინც მუშაობს, სანამ ორივე მხარეს rsa-sha2-256 ან rsa-sha2-512-ის შეთანხმება შეუძლია. პრაქტიკაში ეს ნიშნავს, რომ ძალიან ძველი კლიენტი ან ძალიან ძველი RSA კონფიგურაცია განახლებულმა სერვერმა შეიძლება უცებ უარყოს, და შეცდომა ალგორითმის ნაცვლად გასაღებს ადანაშაულებს. თუ ამას შეხვდები, SHA-1-ის ხელახლა ჩართვის ნაცვლად შექმენი ed25519 გასაღები.

გასაღების სწორად შექმნა და დაყენება#

გასაღები შექმენი მანქანაზე, რომლის წინაც ზიხარ, და არასოდეს სერვერზე. private გასაღები, რომელიც სერვერზე იყო, private გასაღებია, რომელიც სხვის კომპიუტერზე იყო.

$ ssh-keygen -t ed25519 -a 100 -C "davit@laptop-2026"Generating public/private ed25519 key pair.Enter file in which to save the key (/home/davit/.ssh/id_ed25519):Enter passphrase (empty for no passphrase):

ამ ხაზის სამი ნაწილი გაგება ღირს და არა უბრალოდ გადაწერა.

• -a 100 ადგენს რაუნდების რაოდენობას, რომლითაც იმ გასაღებს იღებენ, რომელიც შენი private გასაღების ფაილს შიფრავს. ის მოპარულ გასაღების ფაილს brute-force-ისთვის უფრო ნელს ხდის და განბლოკვისას წამის ნაწილს გიჯდება.
• -C კომენტარია. ჩაწერე მასში ადამიანი და მანქანა. სამ წელიწადში გაზიარებულ სერვერზე authorized_keys კომენტარების სიაა და სხვა არაფერი, და „ამ ხუთი გასაღებიდან რომელი ეკუთვნის იმ ადამიანს, ვინც წავიდა" კითხვაა, რომელსაც შენ დაგისვამენ.
• მიეცი მას passphrase. გასაღები მის გარეშე პაროლების ფაილია, რომლის დაკოპირებაც და სამუდამოდ გამოყენებაც შეუძლია ნებისმიერს, ვისაც შენს ლეპტოპზე წაკითხვის წვდომა აქვს. agent, შემდეგ თავში, ნიშნავს, რომ მას დღეში ერთხელ აკრეფ.

დააყენე ის ssh-copy-id-ით, რომელიც უფლებებსა და დამატებას სწორად ამუშავებს:

$ ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

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

როცა გასაღები უარყოფილია და მიზეზს ვერ ხედავ, ჰკითხე ჯერ კლიენტს და შემდეგ სერვერს:

$ ssh -v deploy@203.0.113.10          # which keys were offered, what was accepted$ journalctl -u ssh -n 50             # on the server, with LogLevel VERBOSE

დაახლოებით ათიდან ცხრა შემთხვევაში პასუხი პირველ გამოტანაშია: გასაღები, რომელსაც ელოდი, არასოდეს შემოგთავაზებიათ, რადგან agent-ში სხვა იყო, ან IdentityFile სხვაგან მიუთითებდა.

agent, რომ passphrase ერთხელ აკრიფო#

ssh-agent მეხსიერებაში ინახავს განშიფრულ private გასაღებებს და მოთხოვნისას challenge-ებს აწერს ხელს, ამიტომ passphrase-ს სესიაზე ერთხელ შეიყვან და არა კავშირზე ერთხელ.

$ eval "$(ssh-agent -s)"$ ssh-add ~/.ssh/id_ed25519$ ssh-add -l256 SHA256:5xM8n... davit@laptop-2026 (ED25519)

დესკტოპების უმეტესობა agent-ს შენთვის უშვებს. macOS-ზე ssh-add --apple-use-keychain passphrase-ს keychain-ში ინახავს. Windows-ზე OpenSSH Authentication Agent სერვისია, რომელიც ავტომატური გაშვებაზე უნდა დაყენდეს, სანამ ssh-add იმუშავებს. პაროლების მენეჯერებსა და gpg-agent-საც შეუძლიათ agent-ის როლი, რაც მოსახერხებელია და არცერთ ქვემოთ მოცემულ წესს არ ცვლის.

~/.ssh/config-ში ორი პარამეტრი მას ავტომატურს ხდის:

Host *    AddKeysToAgent yes    IdentitiesOnly yes    ServerAliveInterval 30    ServerAliveCountMax 3

IdentitiesOnly yes მნიშვნელოვანია და ნამდვილ ჩავარდნას ასწორებს. მის გარეშე კლიენტი agent-ში მყოფ ყველა გასაღებს რიგრიგობით სთავაზობს და თითოეული შეთავაზება ავთენტიფიკაციის მცდელობად ითვლება. ხუთი ჩატვირთული გასაღებისა და MaxAuthTries 3-ზე დაყენებული სერვერის დროს გაგთიშავენ შეტყობინებით „Too many authentication failures", მიუხედავად იმისა, რომ სწორი გასაღები გაქვს. IdentitiesOnly კლიენტს ეუბნება, შესთავაზოს მხოლოდ ის გასაღები, რომელიც ამ ჰოსტისთვისაა დასახელებული.

Agent forwarding გაფრთხილებას იმსახურებს. ssh -A შენს agent socket-ს დისტანციურ მანქანაზე ხსნის, და ნებისმიერს, ვისაც იქ root აქვს, შეუძლია მისი გამოყენება, რომ შენს სახელით გაიაროს ავთენტიფიკაცია ყველგან, რასაც შენი გასაღებები აღებს. ჩვევად ნუ გაიხდი და არასოდეს გამოიყენო მანქანისკენ, რომელსაც არ ადმინისტრირებ. მეორე მანქანამდე მისასვლელი სწორი ინსტრუმენტია ProxyJump, რომელიც ავთენტიფიკაციას შენს ლეპტოპზე ტოვებს.

კონფიგურაციის ფაილი, რომელიც ყველაზე მეტ დროს ზოგავს#

~/.ssh/config გრძელ ბრძანებას სიტყვად აქცევს და აქ ცხოვრობს კარგი ჩვევები.

Host vds    HostName 203.0.113.10    User deploy    IdentityFile ~/.ssh/id_ed25519Host db    HostName 10.0.0.20    User deploy    ProxyJump vdsHost *    AddKeysToAgent yes    IdentitiesOnly yes    ControlMaster auto    ControlPath ~/.ssh/cm-%r@%h:%p    ControlPersist 10m

ssh vds ახლა მუშაობს, ისევე როგორც scp file vds:/tmp/ და rsync -a ./site/ vds:/var/www/, რადგან ყველა ერთსა და იმავე ფაილს კითხულობს.

ProxyJump ნაწილია, რომლის დღესვე გამოყენებაც ღირს. ssh db კავშირს vds-ის გავლით ხსნის პირად მისამართზე მყოფ მანქანამდე, ავთენტიფიკაცია ყოველ ნახტომზე შენს ლეპტოპზე ხდება და შუალედურ ჰოსტზე არც გასაღები და არც agent socket არასოდეს ხვდება. ის ცვლის ყველა მიზეზს, რაც ადრე agent forwarding-ისთვის გქონდა.

ControlMaster ერთ TCP კავშირს იმავე ჰოსტთან შემდგომი სესიებისთვის ხელახლა იყენებს, ამიტომ მეორე და მესამე ssh vds მყისიერია და ხელახლა ავთენტიფიკაციას არ გადის. ეს ნელ ხაზზე ცხოვრების დიდი გაუმჯობესებაა და Windows-ის OpenSSH კლიენტი მას არ უჭერს მხარს. ControlPersist 10m გაზიარებულ კავშირს ბოლო სესიის დახურვიდან ათი წუთით ცოცხლად ინახავს.

ServerAliveInterval 30 სახლის როუტერს ან შუამავალ მოწყობილობას უშლის ხელს, უხმოდ გაწყვიტოს უქმი სესია, რაც გაყინული კავშირების უმეტესობის მიზეზია და არა დახურულის.

sshd-ის გამაგრება#

ესენი სერვერზე მიდის. Debian-სა და Ubuntu-ზე გაითვალისწინე, რომ /etc/ssh/sshd_config იწყება Include /etc/ssh/sshd_config.d/*.conf-ით, და sshd საკვანძო სიტყვისთვის იყენებს პირველ მნიშვნელობას, რომელსაც მიიღებს, ამიტომ ფაილი ამ დირექტორიაში მთავარ კონფიგურაციას ჯობნის. სანამ რამეს დაწერ, შეამოწმე, რა არის უკვე იქ, როგორც აღწერილია პირველი საათი ახალ VDS-ზე პოსტში.

LogLevel VERBOSE არასაკმარისად არის შეფასებული. ის ყოველ შესვლაზე ჩაწერს, რომელმა გასაღებმა გაიარა ავთენტიფიკაცია, fingerprint-ით. ინციდენტის შემდეგ ეს ერთი ხაზი განსხვავებაა იმას შორის, გაიგო, ვისი credential იყო გამოყენებული, თუ გამოიცნო. ლოგები, რომლებიც ღირს შენახვად მის შენახვას ეხება, ხოლო რა უნდა გააკეთო, როცა შენი სერვერი გატეხეს - რისთვის დაგჭირდება.

Match ბლოკები პარამეტრებს ქვესიმრავლეზე იყენებს და ფაილის ბოლომდე ან შემდეგ Match-მდე გრძელდება, ამიტომ ბოლოს დადე:

PasswordAuthentication noPermitRootLogin noAllowGroups ssh-usersMatch Group sftp-only    ChrootDirectory /srv/sftp/%u    ForceCommand internal-sftp    AllowTcpForwarding no

ყოველთვის გადაამოწმე გადატვირთვამდე და ყოველთვის უკვე გაქონდეს სესიიდან:

$ sshd -t && systemctl restart ssh

რა არ ღირს გაკეთება: პორტის შეცვლა (სკანერი მას წამებში პოულობს, თუმცა შენს ლოგებს ჩააჩუმებს), ყველა შიფრის გამორთვა, რომელსაც თანამედროვე კლიენტი მაინც შეათანხმებდა, ან ორმოცხაზიანი sysctl ბლოკის ჩასმა, რომლის ახსნაც არ შეგიძლია. რა ღირს დამატება: fail2ban, თუ მანქანაზე რამე ჯერ კიდევ პაროლს იღებს, და firewall, რომელიც SSH-ს მხოლოდ იმ მისამართებიდან უშვებს, რომლებსაც იყენებ - ufw გზამკვლევს აქვს სინტაქსი.

იმის შეზღუდვა, რისი გაკეთებაც გასაღებს შეუძლია#

გასაღები არ უნდა იყოს ზოგადი დანიშნულების შესვლა. authorized_keys-ში ხაზის დასაწყისში მყოფი პარამეტრები მხოლოდ იმ გასაღებს ეხება, და სწორედ ასე იღებს backup დავალება ან deploy hook ზუსტად იმ წვდომას, რაც სჭირდება.

restrict,from="203.0.113.0/24" ssh-ed25519 AAAAC3Nza... davit@laptop-2026restrict,command="/usr/local/bin/backup-receive" ssh-ed25519 AAAAC3Nza... backup@nas

პარამეტრები, რომლებიც უნდა იცოდე:

• restrict (OpenSSH 7.2 და უფრო ახალი) ერთდროულად თიშავს ყველა არასავალდებულოს: port forwarding-ს, agent forwarding-ს, X11-ს, tty-ს და მომხმარებლის გარემოს ცვლადებს. დაიწყე მისგან და დააბრუნე მხოლოდ საჭირო, pty-ით ან port-forwarding-ით.
• from="..." ზღუდავს გასაღებს წყარო მისამართით ან დიაპაზონით. ფიქსირებული ოფისისთვის ან ცნობილი სერვერისთვის ეს ძლიერი, უფასო კონტროლია.
• command="..." აიძულებს ამ ბრძანებას იმის მიუხედავად, რასაც კლიენტი ითხოვდა. კლიენტის ორიგინალური მოთხოვნა სკრიპტისთვის SSH_ORIGINAL_COMMAND-შია ხელმისაწვდომი, ასე აიგება შეზღუდული rsync ან git წვდომა.
• expiry-time="20270101" (OpenSSH 8.2 და უფრო ახალი) გასაღებს თარიღის შემდეგ ამუშავებას უწყვეტს. გამოსადეგია კონტრაქტორისთვის.

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

ჰოსტის გასაღებები, known_hosts და სერვერისადმი ნდობა#

ავთენტიფიკაცია ორმხრივია. სერვერი საკუთარ ვინაობას host key-ით ამტკიცებს, შენი კლიენტი კი მას ~/.ssh/known_hosts-ში იმახსოვრებს. პირველი კავშირი trust on first use-ია: გაჩვენებენ fingerprint-ს და გთხოვენ მის მიღებას, და თითქმის ყველა ჩახედვის გარეშე წერს yes-ს, რაც მთელ სქემას დეკორატიულს ხდის.

გააკეთე ეს სწორად, თითო მანქანაზე ერთხელ. სერვერზე, პროვაიდერის კონსოლიდან:

$ ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub256 SHA256:5xM8nQ... root@web-01 (ED25519)

შეადარე ეს სტრიქონი იმას, რასაც შენი კლიენტი პირველ კავშირზე აჩვენებს. ეს ათ წამს გრძელდება და ერთადერთი მომენტია, როცა შემოწმება შესაძლებელია.

სისტემის თავიდან აგების შემდეგ host key იცვლება და მოსალოდნელი შეტევის შესახებ ხმამაღალ გაფრთხილებას იღებ. ჩვეულებრივ ეს კანონიერია, და გამოსწორება ძველი ჩანაწერის დავიწყებაა:

$ ssh-keygen -R 203.0.113.10

გააკეთე ეს მხოლოდ მაშინ, როცა იცი, რატომ შეიცვალა გასაღები. host key, რომელიც მანქანაზე შეიცვალა, რომელსაც შენ ხელი არ დაგიკარებია, ზუსტად ის მოვლენაა, რისთვისაც გაფრთხილება არსებობს. თანამედროვე OpenSSH host key-ებსაც თავისით ცვლის: UpdateHostKeys-ის ჩართვისას სერვერს, რომელიც ახალი host key ტიპს ამატებს, შეუძლია ის კლიენტებს გადასცეს, რომლებმაც უკვე გაიარეს ავთენტიფიკაცია, ამიტომ known_hosts გაფრთხილებების გარეშე ახალი რჩება.

ორფაქტორიანი, სერტიფიკატები და როდის ღირს#

არსებობს კიდევ ორი ფენა და პატარა კონფიგურაციების უმეტესობას ისინი არ სჭირდება.

ორფაქტორიანი გასაღებზე დამატებით. AuthenticationMethods publickey,keyboard-interactive მოითხოვს გასაღებს და შემდეგ მეორე ფაქტორს PAM-ის გავლით, ჩვეულებრივ TOTP კოდს. ის გაზიარებული production მანქანისთვის მართლა უფრო ძლიერია. ის ასევე არღვევს ავტომატურ დავალებებს, ამიტომ დააკავშირე Match ბლოკთან, რომელიც ავტომატიზაციის ანგარიშს გამონაკლისად ტოვებს, და დარწმუნდი, რომ გესმის, რა ხდება, როცა PAM მოდული არასწორად იქცევა, სანამ მასზე დაეყრდნობი.

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

$ ssh-keygen -s ca_key -I davit -n deploy -V +8w ~/.ssh/id_ed25519.pub

ერთი ადამიანისთვის ორი სერვერით ეს დანახარჯია სარგებლის გარეშე. დაახლოებით ხუთი ადამიანის ან ოცი მანქანის შემდეგ ის აშკარად სწორი პასუხი ხდება, და გადაკვეთის წერტილი ის ადგილია, სადაც authorized_keys-ის რედაქტირებების დავიწყება იწყება.

გამორიცხვა: რა გიშველის სინამდვილეში#

იმის მიხედვით, რამდენად მოისურვებ, რომ გქონოდა:

1. სესია, რომელიც ღია დატოვე. გააუქმე ცვლილება, გადატვირთე sshd, ამოისუნთქე.
2. `sshd -t` ყოველ გადატვირთვამდე. ის იჭერს შეცდომებს აკრეფაში, რაც გამორიცხვების უმეტესობაა.
3. შენი პროვაიდერის კონსოლი ან rescue რეჟიმი. VDS-ს სრული root წვდომით ეს აქვს; ის ნელია და მუშაობს. გაარკვიე, სად არის, სანამ დაგჭირდება და არა დროს.
4. მეორე გასაღები მეორე მანქანიდან, დაყენებული მაშინ, როცა ყველაფერი მუშაობდა. ტელეფონი SSH კლიენტით ითვლება.
5. მეორე ანგარიში `AllowUsers`-ში საკუთარი გასაღებით, რომელიც სხვა არაფრისთვის გამოიყენება.

მართული თამაშის, აპლიკაციის ან ვებ სერვერი სრულიად განსხვავებული სიტუაციაა: არ არსებობს SSH daemon, საიდანაც შეგიძლია გამოირიცხო თავი, ფაილებზე წვდომა SFTP-ითაა, თითოეული სერვერისთვის გაცემული credential-ებით, და კონსოლი პანელშია. ეს არის გაცვლა, რომელსაც VDS თუ თამაშის პანელი აღწერს - VDS გაძლევს ამ პოსტის ყველა პარამეტრს და პასუხისმგებლობას ყველაზე.

FAQ#

უნდა ჰქონდეს თუ არა ჩემს გასაღებს passphrase, თუ ამ ლეპტოპს მხოლოდ მე ვიყენებ?

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

შემიძლია თუ არა ერთი გასაღების გამოყენება რამდენიმე სერვერზე?

დიახ, ეს ნორმალურია და კარგი: private გასაღები შენს მანქანას არასოდეს ტოვებს, ხოლო საჯარო გასაღები განზრახ საჯაროა. გამოიყენე სხვადასხვა გასაღები თითო ადამიანზე და არა თითო სერვერზე. სერვერზე ცალკე გასაღებები გამოსადეგია მხოლოდ მაშინ, როცა ერთ მანქანაზე წვდომის გაუქმების შესაძლებლობა გინდა დანარჩენებზე შეხების გარეშე.

რა მოხდება, თუ private გასაღები დავკარგე?

წვდომას კარგავ და სხვა არაფერი რისკავს. შედი სხვა გზით - მეორე გასაღები, პროვაიდერის კონსოლი, კოლეგა წვდომით - და authorized_keys-ში დაამატე ახალი საჯარო გასაღები, შემდეგ წაშალე ძველი ხაზი. სწორედ ამიტომ ღირს წინასწარ break-glass გასაღების ან კონსოლის მოწყობა, რომლამდეც მისვლა იცი.

უსაფრთხოა თუ არა საჯარო გასაღების გაგზავნა ელფოსტით ან ჩასმა?

დიახ. საჯარო გასაღები გამოსაქვეყნებლადაა განკუთვნილი; ის authorized_keys-შია ყველა სერვერზე, რომელსაც იყენებ. რაც შენს მანქანას არასოდეს უნდა დატოვოს, არის ფაილი .pub გაფართოების გარეშე. თუ private გასაღები ოდესმე სადმე ჩაიდება, ჩათვალე გადამწვარად და შექმენი ახალი წყვილი.

გამორთავს თუ არა პაროლით ავთენტიფიკაციის გამორთვა ჩემს სხვა ხელსაწყოებს?

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

მჭირდება თუ არა კიდევ fail2ban მხოლოდ გასაღებებით?

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