SSH грешки при поврзување со Ubuntu VPS
Кога SSH пристапот до Ubuntu VPS не успева, точната порака одредува што да проверите. Одделете ги мрежата, сервисот, автентикацијата и идентитетот на host, со зачувување на секој работен пристап.
VPSuntu · Ажурирано: · Читање: околу 5 мин
Содржина на водичот
Снимете еден неуспех и зачувајте работен пристап
Оставете ја успешната SSH сесија отворена и најдете recovery console на провајдерот. Клиентските команди се извршуваат на вашиот Linux, macOS или WSL компјутер; серверските преку постоен пристап или автентицирана конзола. Не внесувајте серверски команди во локалниот терминал.
Заменете 203.0.113.10, ubuntu, портата 22 и патеката до клучот со вистинските податоци. Адресата е документациски пример. Прво испечатете ги применетите клиентски поставки, па направете нов обид:
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. Втората команда го исклучува споделувањето врска за овој обид. Запишете време и конечна грешка. Секое ново host-key прашање проверете го според делот за идентитет. Пред споделување сокријте кориснички имиња, адреси и патеки; никогаш не споделувајте приватен клуч.
Изберете ја гранката според грешката
На мал екран поместете ја табелата странично за да ги видите сите колони.
| Порака или фаза | Што покажува | Следна проверка |
|---|---|---|
| Connection timed out пред воспоставување врска | TCP поврзувањето не завршило | Адреса, routing, firewall и состојба на провајдерот |
| Connection refused | Активно одбивање на адресата и портата | Порта, listener и правила за одбивање |
| Permission denied (publickey) | Достигната е автентикација, но клучевите се одбиени | Корисник, понуден клуч и серверска политика |
| REMOTE HOST IDENTIFICATION HAS CHANGED | Прикажаниот host се разликува од зачуваниот | Доверлива проверка на host key |
Пораките го стеснуваат проблемот, но не докажуваат една причина. Ако пред timeout пишува Connection established, проверете SSH handshake и серверски логови, наместо да претпоставите целосно блокирани пакети.
Timeout: следете ја мрежната патека
Споредете ја адресата во ssh -v со актуелната во панелот. Стар DNS или друга IPv6 адреса може да го насочи обидот на погрешно место. Потврдете дали VPS бара јавна IP, VPN или jump host.
Проверете дали инстанцата работи и има јавно рутирање. Кај провајдерот проверете ја вистинската SSH порта и сегашната јавна изворна IP. Домашна IP може да се смени додека /32 правилото останува старо. Преку конзолата проверете го и guest firewall.
Кај Oracle влијаат security lists, NSG, routing и guest firewall. Зачувајте ги испорачаните правила; инсталирање UFW или празнење iptables не е дијагностички чекор. Oracle поставувањето го објаснува распоредот. Неуспешен ping сам не докажува недостапен SSH.
Одбиена врска: проверете што слуша
Одбивањето не докажува дека одредиштето е вашата VM. Потврдете идентитет и порта, па на серверот преку постоен пристап или конзола извршете:
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 на очекуваната порта и адреса и споредете логови со времето на обидот. Ubuntu може да користи socket activation: неактивен ssh.service не значи недостапен SSH ако ssh.socket слуша.
sshd -t проверува конфигурација и host keys без да го стартува daemon. Успех без излез не докажува мрежна достапност. Ако има грешка, утврдете датотека или поставка пред повторно вчитување; не рестартирајте слепо.
Одбиен јавен клуч: проверете сметка и идентитет
Користете го почетниот корисник од провајдерот или создадениот администратор. Во 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. За нечитлив приватен клуч или прешироки дозволи прво поправете ја локалната датотека.
На серверот проверете ја целната сметка и јавните клучеви. Примерот претпоставува /home/ubuntu; користете го home од 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Споредете ги овластените fingerprints со понудениот и прегледајте journal за сопственост, дозволи или политика на сметката. Ако патеката е друга, проверете AuthorizedKeysFile, include датотеки и Match правила. Провајдерски key services можат да го менуваат механизмот. Чувајте ги постојните клучеви; не исклучувајте StrictModes и не вклучувајте лозинки за да ја сокриете причината.
Сменет host key: проверете пред поврзување
Повторно создавање или прераспределена IP може да го сменат клучот, но неочекувана промена може да значи погрешна точка или пресретнување. Преку автентицираниот панел проверете идентификатор и планирана промена.
Во доверлива конзола на гостинскиот систем проверете го јавниот host key за алгоритмот од предупредувањето. За Ed25519:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256Споредете SHA256 fingerprint. Ова е серверскиот клуч, не вашиот login клуч или клучот на console gateway. За потврдена замена може да треба да го обновите конкретниот запис: прво зачувајте копија од known_hosts и чувајте ги другите записи. Не ја бришете целата датотека и не ја заобиколувајте проверката. Ако идентитетот остане нејасен, запрете и истражете.
Проверете ја поправката во нова сесија
Поправете ја утврдената адреса, сметка, клуч, тесно мрежно правило или конфигурациска грешка. Чувајте независен пристап при промени и валидирајте SSH конфигурација пред примена. Нова порта може да бара и socket activation поставки, не само рестарт на сервис.
Повторете го првиот обид со исклучено connection sharing. Потврдете нова најава во точната сметка и потребен sudo пристап. Стара сесија што останала отворена не е оваа проверка. Запишете причина и поправка, па вратете се на поставувањето Ubuntu VPS.
Често поставувани прашања
Треба ли да го реинсталирам Ubuntu за да поправам SSH?
Прво направете дијагностика. Погрешна адреса, сметка или клуч не бара реинсталација, а таа може да ги уништи податоците. Кога нема пристап, користете го обновувањето на провајдерот.
Дали работна конзола значи дека SSH мора да работи?
Не. Конзолата и јавниот SSH имаат различни патеки. Listener, автентикација и мрежни правила одделно треба да го дозволат SSH поврзувањето.