Проблеми със SSH: проверете точната грешка

Запишете един неуспешен опит

Оставете работещата SSH сесия отворена и намерете конзолата за възстановяване. Клиентските команди се изпълняват на вашия 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 и прокси настройките. Вторият ред изключва споделянето на връзки за този опит. Запишете часа и последната грешка. Нов хост ключ изисква доверена проверка. Преди споделяне скрийте потребители, адреси и пътища; не изпращайте частен ключ.

Изберете правилната диагностична посока

На малък екран плъзнете таблицата настрани, за да видите всички колони.

Тези признаци стесняват търсенето, но не доказват една-единствена причина. Ако преди timeout вече има Connection established, проверете SSH обмена и журналите, вместо да приемате, че цялата мрежа е блокирана.

При timeout проследете мрежовия път

Сравнете адреса от ssh -v с текущия адрес в панела. Стар DNS или друг IPv6 адрес могат да насочат връзката другаде. Уточнете дали са нужни публичен IP, VPN или междинен SSH хост.

Проверете дали машината работи, има публичен маршрут и правилата допускат реалния SSH порт от текущия ви публичен адрес. Домашният адрес може да се смени, а правилото /32 да остане старо. Проверете и гостовата защитна стена през конзолата.

При Oracle Cloud участват списъци за сигурност, NSG, маршрути и правила на образа. Не инсталирайте UFW и не изчиствайте iptables като диагностична стъпка. Oracle примерът описва мрежата. Неуспешен ping сам по себе си не доказва, че SSH е недостъпен.

При отказана връзка проверете слушащата услуга

Отказът не доказва, че адресът е вашият VPS. Потвърдете машината и порта, после изпълнете през съществуващ достъп или конзолата:

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

Съпоставете слушащия адрес и порт с опита и журналите. Ubuntu може да използва активиране чрез socket: неактивна ssh.service не доказва липса на SSH, ако ssh.socket слуша.

sshd -t проверява конфигурацията и хост ключовете, без да стартира услугата. Успех без изход не доказва мрежова достъпност. Отстранете конкретния файл или настройка при грешка, вместо да рестартирате на сляпо.

При отхвърлен ключ проверете потребителя и ключа

Използвайте началния потребител на доставчика или създадения от вас администратор. В изхода вижте кой ключ е предложен. За ограничаване на несвързани ключове от агент опитайте локално:

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 с домашния път, върнат от 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

Сравнете разрешените отпечатъци с предложения ключ. Проверете журнала, собствеността, правата, AuthorizedKeysFile, включените настройки и Match правила. Запазете съществуващите ключове; не изключвайте StrictModes и не разрешавайте пароли, за да прикриете причината.

При променен хост ключ потвърдете самоличността

Преинсталиране или пренасочен IP може да промени хост ключа. Неочаквана промяна може да означава грешна крайна точка или прихващане. Проверете идентификатора и планираните промени в удостоверения панел.

През доверената конзола на гостовата система покажете публичния ключ със същия алгоритъм. За Ed25519:

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

Сравнете SHA256 отпечатъка с предупреждението. Това е ключът на сървъра, не потребителският ключ или този на конзолния шлюз. При потвърдена замяна обновете само съответния запис, като запазите копие и останалите записи. Не изтривайте целия known_hosts и не заобикаляйте проверката.

Проверете корекцията с нова сесия

Поправете установения адрес, потребител, ключ, конкретно мрежово правило или настройка. Запазете независим достъп при сървърни промени и проверете SSH конфигурацията преди прилагане. Смяна на порт може да включва и socket настройки.

Повторете първоначалния опит без споделяне на връзки. Проверете правилния потребител и необходимото sudo. Стара отворена сесия не замества теста. Запишете причината и промяната, после продължете с настройката на сайта.