Ubuntu VPS SSH қосылым қатесін анықтау
SSH қатесін оның кезеңіне қарай тексеріңіз: серверге жету, SSH қызметіне қосылу, пайдаланушы кілтімен кіру немесе host identity растау. Жұмыс істейтін сессияны жаппаңыз және өзгеріс алдында провайдердің recovery console мүмкіндігін дайындаңыз.
VPSuntu · Жаңартылды: · Оқу уақыты: шамамен 4 минут
Нұсқаулық мазмұны
Қатені жаңа қосылымда қайталаңыз
Клиент командаларын компьютердегі Bash-та, сервер тексерулерін бар SSH сессиясында немесе сенімді консольде орындаңыз. 203.0.113.10, ubuntu, порт пен key жолын өз деректеріңізге ауыстырыңыз. Қосылым уақыты мен толық қате мәтінін жазыңыз. Бөлісетін журналдан мекенжайлар мен жеке мәліметтерді жасырыңыз; 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.10ssh -G нақты қолданылатын баптауды көрсетеді. Жаңа диагностикалық қосылымда connection sharing өшіріледі: бұрынғы сессияны қайта пайдалану жаңа кірудің істейтінін дәлелдемейді.
Қате кезеңін анықтаңыз
Шағын экранда барлық бағанды көру үшін кестені көлденең жылжытыңыз.
| Белгі | Мағынасы | Келесі тексеру |
|---|---|---|
| Connection timed out, байланыс орнамады | Мақсатқа немесе портқа жетпеді | IP, маршрут, желі және firewall |
| Handshake басталғаннан кейін timeout | TCP байланысы бар, кейін тоқтады | SSH debug кезеңі, қызмет, аралық желі |
| Connection refused | Қосылымға жауап бар, бірақ порт қабылдамайды | SSH listener, порт және reject ережесі |
| Permission denied (publickey) | SSH қызметіне жетті, пайдаланушы кілті қабылданбады | Пайдаланушы, key және authorized_keys |
| REMOTE HOST IDENTIFICATION HAS CHANGED | Сақталған host identity сәйкес емес | Сенімді консольден нақты серверді тексеру |
Refused қатесі дұрыс сервер екенін өздігінен растамайды. Timeout кезінде аутентификацияны өзгертуге асықпаңыз; қай кезеңде тоқтағанын анықтаңыз.
IP, маршрут және firewall тексеріңіз
ssh -v шығысындағы мақсатты IP-ді provider console дерегімен салыстырыңыз. DNS, ескі IPv6, VPN, jump host, ProxyJump және клиент конфигурациясы бағытты өзгертуі мүмкін. VM іске қосылғанын және қоғамдық мекенжайы барын тексеріңіз.
Провайдер firewall ережесі нақты SSH портына қазіргі әкімшілік IP /32 мекенжайынан рұқсат беруі тиіс. Guest firewall да сол портты өткізуі керек. Oracle ішінде тіркелген security list пен NSG-дің бәрін тексеріңіз, image iptables және iSCSI ережелерін сақтаңыз. Барлық firewall ережесін тазаламаңыз және UFW-ді бейне нұсқаулығынсыз қоспаңыз. Ping жауап бермеуі SSH бұғатталғанының жеке дәлелі емес.
SSH listener және конфигурацияны қараңыз
Сервердің жұмыс істейтін сессиясында не консольде listener портын, ssh.service және ssh.socket күйін тексеріңіз:
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-pagerSocket activation қолданылғанда ssh.service inactive болуы қызметтің міндетті түрде бұзылғанын білдірмейді. Нақты тыңдап тұрған портты қараңыз. sshd -t конфигурация мен key файлдарын тексереді, бірақ сыртқы желі қолжетімділігін тексермейді. Қай service/socket басқарылатынын анықтаған соң ғана тиісті reload қадамын жоспарлаңыз.
Пайдаланушы мен ұсынылған кілтті салыстырыңыз
Провайдер берген немесе өзіңіз жасаған дұрыс пайдаланушыны таңдаңыз. Клиентте ұсынылған public-key fingerprint пен серверге тіркелген key сәйкес пе? IdentitiesOnly басқа кілттерді шектейді, бірақ ssh -G ішінде бірнеше IdentityFile қалуы мүмкін. Алдымен жергілікті private key рұқсат қатесін түзетіңіз.
ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Серверде getent арқылы нақты home жолын анықтап, мысалдағы пайдаланушы мен жолдарды ауыстырыңыз. authorized_keys fingerprint, файл иесі, рұқсаттар және journal мәліметтерін тексеріңіз.
getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keysMatch блоктары мен қызметтің нақты баптауларын ескеріңіз. Қажетті бар кілттерді сақтаңыз. Қатені жасыру үшін StrictModes өшірмеңіз және password login қоспаңыз.
Өзгерген host key мәнін сенімді жолмен растаңыз
Сервер қайта жасалған, IP басқа VM-ге берілген немесе қате endpoint таңдалған болуы мүмкін; бөгде қосылым қаупін де жоққа шығармаңыз. Instance identity және қайта жасау тарихын тексеріп, сенімді console ішінде guest Ed25519 host key fingerprint алыңыз:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256Бұл пайдаланушы key немесе console gateway key емес. Белгілі host жазбасының көшірмесін сақтап, тек identity расталған нақты host:port жазбасын жаңартыңыз. Бүкіл known_hosts файлын тазаламаңыз, StrictHostKeyChecking өшірмеңіз және тексерілмеген жаңа кілтті қабылдамаңыз.
Тар түзету енгізіп, жаңа сессияда сынаңыз
Тек анықталған себепті түзетіңіз. Құқық, конфигурация немесе порт өзгерсе, алдымен тексеріңіз; socket activation кезінде портты өзгерту socket баптауын да талап етуі мүмкін. Recovery console және ескі жұмыс істейтін сессия ашық қалсын.
Компьютерден connection sharing өшірілген жаңа қосылым жасаңыз. Дұрыс пайдаланушы мен күтілген host identity екенін тексеріп, керек болса sudo сынаңыз. Ескі сессиядағы пәрменнің сәттілігі жаңа кіруді тексермейді. Себепті, өзгерісті және тексеру уақытын жазыңыз.
Жиі қойылатын сұрақтар
Timeout пен publickey бір ақау ма?
Жоқ. Біріншісі көбіне байланыс кезеңін, екіншісі SSH-қа жеткеннен кейінгі аутентификацияны тексеруді талап етеді.
Ескі сессия ашық болса, кіру дұрыс па?
Жаңадан қосылуды бөлек тексеру керек. Ашық сессия жаңа firewall не key қатесін байқатпауы мүмкін.
Host key ескертуін өшіруге бола ма?
Алдымен нақты сервердің identity мәнін сенімді консоль арқылы растаңыз. Ескертуді айналып өту тексеруді алмастырмайды.