SSH-კავშირის შეცდომები: იპოვეთ შეფერხების მიზეზი

ჩაწერეთ ერთი მცდელობის შედეგი და შეინარჩუნეთ წვდომა

მოქმედი SSH-სესია ღია დატოვეთ და იპოვეთ პროვაიდერის recovery console. კლიენტის ბრძანებები თქვენს Linux, macOS ან WSL ტერმინალში სრულდება. სერვერის ბრძანებები კი — არსებული წვდომით ან ავტორიზებული recovery console-ით. სერვერის ბრძანებები ლოკალურ ტერმინალში არ ჩასვათ.

203.0.113.10 დოკუმენტაციის მისამართია: შეცვალეთ რეალური მისამართით. ubuntu, პორტი 22 და გასაღების ბილიკიც თქვენს მომხმარებელს, პორტსა და private key-ს მოარგეთ. ჯერ გამოიტანეთ კლიენტის საბოლოო პარამეტრები, შემდეგ სცადეთ ერთი ახალი კავშირი.

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

შეამოწმეთ hostname, user, port, identityfile და proxy პარამეტრები. მეორე ბრძანება ამ მცდელობისთვის connection sharing-ს თიშავს. ჩაიწერეთ დრო და საბოლოო შეცდომა. ახალი host key გადაამოწმეთ ქვემოთ მოცემული იდენტობის წესით. Debug-ის გაზიარებამდე დაფარეთ მომხმარებლები, მისამართები და ბილიკები; private key არასოდეს გააზიაროთ.

აირჩიეთ შეცდომის შესაბამისი მიმართულება

პატარა ეკრანზე ყველა სვეტის სანახავად ცხრილი ჰორიზონტალურად გადაახვიეთ.

შეტყობინება ძიებას ავიწროებს, მაგრამ ერთ კონკრეტულ მიზეზს არ ამტკიცებს. თუ timeout-მდე debug-ში უკვე წერია Connection established, შეამოწმეთ SSH handshake და server logs; ყველა პაკეტის დაბლოკვა ავტომატურად არ ივარაუდოთ.

Timeout: შეამოწმეთ ქსელის სრული გზა

ssh -v-ის დანიშნულების მისამართი შეადარეთ პროვაიდერის პანელში მიმდინარე მისამართს. მოძველებულმა DNS-მა ან სხვა IPv6 მისამართმა მცდელობა შეიძლება სხვაგან გაგზავნოს. დაადგინეთ, საჭიროა public IP, VPN თუ jump host.

შეამოწმეთ გაშვებული ინსტანსი და საჯარო მარშრუტი. პროვაიდერის firewall-ში გადაამოწმეთ რეალური SSH პორტი და თქვენი მიმდინარე public source IP. სახლის IP შეიძლება შეიცვალოს, /32 წესი კი ძველი დარჩეს. კონსოლიდან guest firewall-იც შეამოწმეთ.

Oracle Cloud-ში მნიშვნელოვანია security lists, NSGs, routing და guest firewall. შეინარჩუნეთ იმიჯის საწყისი წესები; UFW-ის დაყენება ან iptables-ის გასუფთავება დიაგნოსტიკის ნაბიჯი არ არის. ქსელი აღწერილია Oracle Ubuntu-ის ინსტრუქციაში. მხოლოდ წარუმატებელი ping SSH-ის მიუწვდომლობას არ ამტკიცებს.

Refused: შეამოწმეთ, უსმენს თუ არა SSH საჭირო პორტს

კავშირის უარყოფა არ ადასტურებს, რომ სწორ VPS-ს დაუკავშირდით. ჯერ მისამართი, იდენტობა და პორტი გადაამოწმეთ. შემდეგ არსებული წვდომით ან recovery console-ით სერვერზე გაუშვით მხოლოდ მდგომარეობის წამკითხველი ბრძანებები.

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

მოძებნეთ listener საჭირო პორტსა და მისამართზე; logs შეადარეთ თქვენი მცდელობის დროს. Ubuntu-ს შეუძლია socket activation გამოიყენოს: არააქტიური ssh.service თავისთავად არ ნიშნავს, რომ SSH გამორთულია, თუ ssh.socket უსმენს.

sshd -t ამოწმებს configuration-სა და host keys-ს daemon-ის გაშვების გარეშე. ჩუმი წარმატება ქსელიდან მიღწევადობას არ ამტკიცებს. შეცდომისას reload-მდე კონკრეტული ფაილი ან პარამეტრი გამოიკვლიეთ; ბრმად restart არ გაუშვათ.

Public key უარყოფილია: შეამოწმეთ მომხმარებელი და გასაღები

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

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

IdentityFile-ის სხვა პარამეტრები შეიძლება კვლავ მოქმედებდეს; შეამოწმეთ ssh -G. თუ private key ვერ იკითხება ან მისი უფლებები ზედმეტად ფართოა, ჯერ ლოკალურ ფაილზე წვდომა მოაწესრიგეთ.

სერვერზე შეამოწმეთ კონკრეტული მომხმარებელი და authorized public keys. მაგალითში home არის /home/ubuntu; შეცვალეთ getent-ის მიერ დაბრუნებული რეალური ბილიკით.

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

შეადარეთ authorized და offered ანაბეჭდები. Journal-ში მოძებნეთ ownership, permissions და account-policy შეცდომები. არასტანდარტული გზისას შეამოწმეთ AuthorizedKeysFile, included snippets და Match წესები. პროვაიდერის key service-იც შეიძლება სხვა მექანიზმს იყენებდეს. შეინარჩუნეთ არსებული გასაღებები; მიზეზის დასამალად StrictModes არ გამორთოთ და password login არ ჩართოთ.

Host key შეიცვალა: ჯერ იდენტობა დაადასტურეთ

Rebuild-მა ან IP-ის სხვა ინსტანსისთვის მინიჭებამ შეიძლება host key შეცვალოს. მოულოდნელი ცვლილება არასწორ endpoint-ს ან კავშირის ჩაჭრასაც შეიძლება ნიშნავდეს. ავტორიზებულ პანელში გადაამოწმეთ instance ID და დაგეგმილი rebuild.

სანდო guest console-ით შეამოწმეთ კლიენტის მიერ ნაჩვენები ალგორითმის public host key. Ed25519-ის მაგალითი:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

მისი SHA256 ანაბეჭდი კლიენტის გაფრთხილებას შეადარეთ. ეს სერვერის გასაღებია და არა თქვენი login key ან OCI console gateway-ის გასაღები. დადასტურებული ცვლილებისას შეიძლება ამ სერვერის შენახული ჩანაწერის განახლება დაგჭირდეთ: ჯერ ფაილის ასლი შეინახეთ და სხვა ჩანაწერები დატოვეთ. მთელ known_hosts-ს ნუ წაშლით და შემოწმებას ნუ გამორთავთ. აუხსნელი იდენტობის შემთხვევაში კავშირი შეაჩერეთ და მიზეზი გამოიკვლიეთ.

ცვლილება ახალი სესიით გადაამოწმეთ

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

გაიმეორეთ საწყისი მცდელობა connection sharing-ის გარეშე. ახალი login უნდა მივიდეს სწორ მომხმარებელთან და საჭირო sudo წვდომა მუშაობდეს. ძველი სესიის ღიად დარჩენა ამ ტესტს არ ცვლის. ჩაიწერეთ მიზეზი და ცვლილება, შემდეგ დაუბრუნდით Ubuntu VPS-ის გამართვას.

ხშირი კითხვები

ოფიციალური წყაროები

1. დოკუმენტაცია 1: ubuntu.com
2. დოკუმენტაცია 2: man.openbsd.org
3. დოკუმენტაცია 3: man.openbsd.org
4. დოკუმენტაცია 4: man.openbsd.org
5. დოკუმენტაცია 5: man.openbsd.org
6. დოკუმენტაცია 6: man.openbsd.org
7. დოკუმენტაცია 7: documentation.ubuntu.com
8. დოკუმენტაცია 8: docs.oracle.com