SSH կապի սխալներ․ գտեք խափանման պատճառը

Գրանցեք մեկ ձախողում և պահեք աշխատող մուտքը

Գործող SSH սեսիան բաց թողեք և գտեք մատակարարի recovery console-ը։ Կլիենտի հրամանները կատարվում են ձեր Linux, macOS կամ WSL համակարգչում։ Սերվերինը՝ առկա մուտքով կամ authenticated 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-ը փոխանցելուց առաջ ծածկեք usernames-ը, հասցեներն ու paths-ը․ private key երբեք մի փոխանցեք։

Ընտրեք սխալին համապատասխան ստուգումը

Փոքր էկրանին բոլոր սյունակները տեսնելու համար աղյուսակը ոլորեք հորիզոնական։

Այս դիտարկումները նեղացնում են պատճառների շրջանակը, բայց մեկ պատճառ չեն ապացուցում։ Եթե timeout-ից առաջ debug-ում արդեն կա Connection established, ուսումնասիրեք SSH handshake-ն ու server logs-ը՝ բոլոր փաթեթների արգելափակում ենթադրելու փոխարեն։

Timeout․ հետևեք նախատեսված ցանցային ուղուն

ssh -v-ում հասցեն համեմատեք մատակարարի պանելի ընթացիկ հասցեի հետ։ Հին DNS-ը կամ այլ IPv6 destination-ը կարող է փորձն այլ տեղ ուղարկել։ Պարզեք՝ այս VPS-ին պետք է public IP, VPN, թե jump host։

Համոզվեք, որ ինստանսն աշխատում է և ունի public routing։ Մատակարարի firewall-ում ստուգեք իրական SSH պորտն ու ձեր ընթացիկ public source IP-ն։ Տան հասցեն կարող է փոխվել, մինչ /32 allow կանոնը մնում է հինը։ Կոնսոլով ստուգեք նաև guest firewall-ը։

Oracle Cloud-ում կարևոր են security lists-ը, NSGs-ը, routing-ը և guest firewall-ը։ Պահպանեք իմիջի սկզբնական կանոնները․ UFW տեղադրելն ու iptables մաքրելը ախտորոշման քայլեր չեն։ Ցանցի կառուցվածքը բացատրված է Oracle Ubuntu-ի կարգավորման ուղեցույցում։ Միայն անհաջող ping-ը SSH-ի անհասանելիություն չի ապացուցում։

Refused․ ուսումնասիրեք լսող ծառայությունը

Մերժումը չի հաստատում, որ հասցեն ձեր սպասվող VPS-ն է։ Ճշտեք ինքնությունն ու պորտը, ապա սերվերում առկա մուտքով կամ recovery console-ով կատարեք այս read-only ստուգումները։

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-ի մերժում․ ստուգեք հաշիվն ու առաջարկված բանալին

Օգտագործեք մատակարարի սկզբնական հաշիվը կամ ձեր ստեղծած ադմինիստրատորին, ոչ ենթադրված username։ Կլիենտի debug-ում գտեք առաջարկված fingerprint-ը։ 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/ubuntu․ փոխարինեք getent-ի ցույց տված home-ով։

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 fingerprints-ը։ Journal-ում ստուգեք ownership, permissions և account-policy սխալները։ Ոչ ստանդարտ ուղու դեպքում ուսումնասիրեք AuthorizedKeysFile-ը, included snippets-ը և Match կանոնները։ Provider-managed key service-ն էլ կարող է փոխել մեխանիզմը։ Պահպանեք հին authorized keys-ը․ պատճառը թաքցնելու համար StrictModes մի անջատեք և passwords մի միացրեք։

Host identity-ն փոխվել է․ նախ ստուգեք այն

Rebuild-ը կամ IP-ի վերանշանակումը կարող է host key փոխել, բայց անսպասելի փոփոխությունը կարող է նաև սխալ endpoint կամ միջամտություն նշանակել։ Authenticated provider panel-ում հաստատեք instance ID-ն ու պլանավորված rebuild-ը։

Guest-ի վստահելի կոնսոլից կարդացեք կլիենտի ցույց տված ալգորիթմի public host key-ը։ Ed25519-ի օրինակ՝

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

SHA256-ը համեմատեք կլիենտի զգուշացման հետ։ Սա սերվերի բանալին է, ոչ login key-ը կամ provider console gateway-ինը։ Հաստատված փոխարինումից հետո կարող է պետք լինել այդ սերվերի պահված գրառման թարմացում․ նախ backup արեք ֆայլը և պահպանեք այլ գրառումները։ Մի ջնջեք ամբողջ known_hosts-ը և մի շրջանցեք ստուգումը։ Եթե ինքնությունը դեռ անհասկանալի է, դադարեցրեք կապը և ուսումնասիրեք պատճառը։

Կոնկրետ ուղղումը ստուգեք նոր սեսիայով

Ուղղեք հայտնաբերված հասցեն, օգտատիրոջը, բանալին, նեղ ցանցային կանոնը կամ configuration-ի սխալը։ Սերվերը փոխելիս պահեք անկախ մուտքի ուղի և մինչև կիրառելը ստուգեք SSH configuration-ը։ Նոր պորտը կարող է նաև socket activation կարգավորում պահանջել, ոչ միայն service restart։

Կրկնեք սկզբնական փորձը՝ connection sharing-ն անջատած։ Նոր մուտքը պետք է հասնի սպասվող հաշվին և անհրաժեշտ 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