SSH достъп: Пълното техническо ръководство за сигурно дистанционно управление на сървър

SSH (Secure Shell) е криптографски мрежов протокол, който установява криптиран тунел между два мрежово свързани хоста, позволявайки автентикирано изпълнение на команди, прехвърляне на файлове и пренасочване на портове през ненадеждни мрежи. По подразбиране работи на TCP порт 22 и замества предшествениците с обикновен текст — Telnet, rsh и FTP — с протокол, осигуряващ поверителност, цялостност и взаимна автентикация в едно единствено ръкостискане.

За всеки администратор, управляващ VPS или dedicated сървър, SSH не е опционална инфраструктура — той е основната контролна плоскост. Всяко конфигурационно решение, което вземате около SSH, пряко влияе върху повърхността за атака на вашия сървър, оперативната надеждност и съответствието с изискванията.

Как работи SSH: Архитектурата на протокола

Разбирането на SSH на ниво протокол е това, което разграничава администраторите, които го конфигурират правилно, от тези, които оставят уязвими пропуски.

Моделът с три слоя

SSH е дефиниран от RFC 4251–4254 и работи в три отделни подслоя, наредени върху TCP:

• SSH протокол на транспортния слой — обработва автентикацията на сървъра, обмена на ключове, договарянето на криптиране и настройката на MAC (код за автентикация на съобщения). Тук се извършва криптографското ръкостискане.
• SSH протокол за автентикация на потребителя — работи върху транспортния слой и обработва автентикацията от клиент към сървър, използвайки методи като publickey, password, keyboard-interactive или gssapi-with-mic.
• SSH протокол за връзка — мултиплексира криптирания тунел в логически канали, всеки от които пренася сесия на обвивката, SFTP подсистема, пренасочен порт или агентска връзка.

Ръкостискането в детайли

Когато изпълните ssh user@host, следната последователност се изпълнява преди да видите подкана:

1. TCP връзката се установява към сървъра на конфигурирания порт.
2. Обмен на версии — клиентът и сървърът обменят низове с версии на протокола (SSH-2.0-OpenSSH_9.x).
3. Договаряне на алгоритми (SSH_MSG_KEXINIT) — двете страни обявяват поддържаните алгоритми за обмен на ключове, типове хост ключове, шифри, MAC-ове и методи за компресия. Първата взаимно поддържана опция от всеки списък печели.
4. Обмен на ключове (KEX) — обикновено Diffie-Hellman или Elliptic Curve Diffie-Hellman (ECDH). И двете страни извеждат споделена тайна, без да я предават. Това произвежда сесийни ключове.
5. Проверка на хост ключа на сървъра — сървърът подписва стойност с частния си хост ключ. Клиентът проверява този подпис спрямо файла ~/.ssh/known_hosts. Несъответствие предизвиква предупреждение и блокира връзката по подразбиране.
6. Криптирането се активира — целият последващ трафик е криптиран и защитен по отношение на цялостност, използвайки договорения шифър (напр. chacha20-poly1305) и MAC.
7. Автентикация на потребителя — клиентът се опитва да се автентикира, използвайки договорения метод. При автентикация с publickey, клиентът подписва предизвикателство с частния си ключ; сървърът проверява, използвайки съхранения публичен ключ.
8. Отваряне на канал — отваря се обвивка, SFTP подсистема или exec канал и сесията започва.

Целият процес обикновено завършва за по-малко от 100 милисекунди в локална мрежа.

Симетрична срещу асиметрична криптография в SSH

Честото погрешно схващане е, че SSH „използва криптиране с публичен ключ” за целия трафик. Това не е така. Ролите са различни:

SSH срещу наследени протоколи за отдалечен достъп

Генериране на SSH ключови двойки

SSH ключовите двойки са основата на сигурния, мащабируем достъп до сървъра. Автентикацията с парола е уязвима към атаки с груба сила и пълнене с идентификационни данни; автентикацията с ключ не е.

Избор на правилния алгоритъм за ключ

Ed25519 е текущата най-добра практика. Използва криптография с елиптична крива Curve25519, произвежда компактни 256-битови ключове, е по-бърз от RSA при еквивалентни нива на сигурност и се поддържа от OpenSSH 6.5+ (издаден 2014).

ssh-keygen -t ed25519 -C "admin@yourhost.example.com"

Използвайте RSA само когато имате нужда от съвместимост с наследени системи, които не поддържат Ed25519:

ssh-keygen -t rsa -b 4096 -C "admin@yourhost.example.com"

Не използвайте DSA (ограничен до 1024 бита, компрометиран) или ECDSA с NIST криви (опасения относно произхода на параметрите на NIST кривата). Ed25519 е недвусмисленият избор за нови внедрявания.

Ръководство за генериране на ключове

ssh-keygen -t ed25519 -C "ops-team-key-2025"

Ще бъдете подканени за:

• Местоположение на файла — по подразбиране е ~/.ssh/id_ed25519. Приемете стойността по подразбиране или посочете персонализиран път за среди с множество ключове.
• Парола — винаги задавайте такава. Паролата криптира частния ключ в покой, използвайки AES-256-CBC (или bcrypt с по-нов OpenSSH). Ако файлът с частния ви ключ бъде откраднат, паролата е последната линия на защита.

Това произвежда два файла:

~/.ssh/id_ed25519 — частният ключ. Никога не го споделяйте. Разрешенията трябва да бъдат 600.
~/.ssh/id_ed25519.pub — публичният ключ. Това е, което разпространявате до сървърите.

Управление на множество ключове с ~/.ssh/config
При управление на множество сървъри или акаунти, използвайте SSH конфигурационен файл, за да избегнете указването на флагове при всяка връзка:
# ~/.ssh/config

Host prod-web
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    Port 2222

Host staging
    HostName 203.0.113.20
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_staging
С това на място, ssh prod-web автоматично се разширява до пълните параметри за връзка.
Разполагане на публичния ви ключ на сървър
Метод 1: ssh-copy-id (Препоръчан за първоначална настройка)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip
Това добавя публичния ключ към ~/.ssh/authorized_keys на отдалечения хост и автоматично задава правилните разрешения.
Метод 2: Ръчно разполагане (Когато ssh-copy-id не е наличен)
cat ~/.ssh/id_ed25519.pub | ssh user@your_server_ip 
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && 
   cat >> ~/.ssh/authorized_keys && 
   chmod 600 ~/.ssh/authorized_keys"
Метод 3: Конзола или API на облачния доставчик
Повечето облачни доставчици и контролни панели за хостинг ви позволяват да инжектирате публични ключове по време на осигуряването на инстанцията. Това е правилният подход за автоматизирана инфраструктура — ключът е наличен преди инстанцията да стартира, елиминирайки проблема с пилето и яйцето при необходимостта от SSH за разполагане на SSH ключове.
Форматът на файла authorized_keys
Всеки ред в ~/.ssh/authorized_keys е един публичен ключ, опционално с префикс от опции:
restrict,command="/usr/local/bin/backup.sh" ssh-ed25519 AAAA... backup-key
from="192.168.1.0/24" ssh-ed25519 AAAA... ops-key
Опцията restrict деактивира пренасочването на портове, пренасочването на агента и разпределението на PTY за този ключ — полезно за ключове за разполагане или акаунти за автоматизация на резервни копия, които не трябва да имат интерактивен достъп до обвивката.
Укрепване на SSH сървъра: /etc/ssh/sshd_config
Инсталацията на OpenSSH по подразбиране е функционална, но не е укрепена. Следната конфигурация представлява базова линия за производствена среда. Приложете промените към /etc/ssh/sshd_config, след което валидирайте и презаредете:
sshd -t && systemctl reload sshd
Винаги изпълнявайте sshd -t преди презареждане — синтактична грешка в sshd_config няма да срине работещия демон, но ще попречи на рестартирането му след рестартиране на системата, блокирайки достъпа ви.
Препоръчан блок за укрепване на sshd_config
# /etc/ssh/sshd_config - Production hardening baseline

Port 2222
AddressFamily inet
ListenAddress 0.0.0.0

# Host keys - prefer Ed25519
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Cryptographic hardening
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Authentication
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes

# Session hardening
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive no

# Disable unused features
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no

# Restrict access
AllowUsers deploy ops-user
Banner /etc/ssh/banner.txt
Обяснение на критичните решения за укрепване
PermitRootLogin no — Влизането като root чрез SSH е високоценна цел. Използвайте обикновен потребител и ескалирайте с sudo. Ако абсолютно се нуждаете от root-еквивалентен достъп чрез конкретен ключ (напр. за автоматизация), използвайте PermitRootLogin prohibit-password, за да разрешите влизане като root само с ключ, като блокирате опитите с парола.
AllowTcpForwarding no — Ако вашият сървър не е бастион или jump хост, деактивирайте TCP пренасочването. Нападател с валидна SSH сесия иначе би могъл да използва вашия сървър като прокси за достъп до ресурси на вътрешната мрежа.
TCPKeepAlive no с ClientAliveInterval — TCPKeepAlive работи на TCP слоя и е видим за мрежовите посредници. ClientAliveInterval изпраща keepalive съобщения през криптирания SSH канал, което е едновременно по-надеждно и по-поверително.
LoginGraceTime 30 — Намалява прозореца, през който неавтентикирана връзка заема слот на сървъра. Стойността по подразбиране от 120 секунди е прекомерна.
AllowUsers — Включете в белия списък само акаунтите, които законно се нуждаят от SSH достъп. Това е твърда бариера, която работи преди всеки опит за автентикация.
Промяна на SSH порта по подразбиране
Преместването на SSH от порт 22 не подобрява сигурността срещу целенасочен нападател — всяко сканиране на портове ще го открие. Това, което прави, е да елиминира огромния обем от автоматизирани, опортюнистични ботове за груба сила, които изключително атакуват порт 22. Това значително намалява шума в журналите и натоварването на сървъра.
# In /etc/ssh/sshd_config
Port 2222
Преди презареждане, отворете новия порт в защитната си стена:
# UFW
ufw allow 2222/tcp
ufw delete allow 22/tcp

# firewalld
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --remove-service=ssh
firewall-cmd --reload

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
iptables -D INPUT -p tcp --dport 22 -j ACCEPT
Ако вашият сървър работи с SELinux, трябва също да актуализирате контекста на порта в SELinux:
semanage port -a -t ssh_port_t -p tcp 2222
Свързване към сървър
Основна връзка
ssh user@your_server_ip
Свързване към нестандартен порт
ssh -p 2222 user@your_server_ip
Свързване с конкретен ключ
ssh -i ~/.ssh/id_ed25519_prod user@your_server_ip
Подробен режим за отстраняване на грешки
ssh -vvv user@your_server_ip
Флагът -vvv отпечатва всяка стъпка от ръкостискането, опита за автентикация и договарянето на канала. Това е първият инструмент, към който да се обърнете, когато дадена връзка се провали неочаквано.
Сигурно прехвърляне на файлове чрез SSH
SCP (Протокол за сигурно копиране)
SCP е прост, неинтерактивен инструмент за копиране на файлове. Той е бърз и широко достъпен, но няма възможност за възобновяване и ограничена обработка на грешки.
Копиране на локален файл към отдалечен сървър:
scp -P 2222 /local/path/file.tar.gz user@your_server_ip:/remote/path/
Копиране на отдалечен файл локално:
scp -P 2222 user@your_server_ip:/remote/path/file.tar.gz /local/path/
Рекурсивно копиране на директория:
scp -rp -P 2222 /local/directory/ user@your_server_ip:/remote/directory/
Забележка: Проектът OpenSSH обяви за остарял наследения SCP протокол в OpenSSH 9.0. Съвременният scp вече използва SFTP протокола под капака по подразбиране. Командният интерфейс остава същият, но основният транспорт е по-надежден.
SFTP (SSH протокол за прехвърляне на файлове)
SFTP е пълнофункционална подсистема за прехвърляне на файлове с изброяване на директории, управление на разрешения и поддръжка на възобновяване. Това е правилният избор за интерактивно управление на файлове.
sftp -P 2222 user@your_server_ip
Общи SFTP команди в интерактивната сесия:
sftp> ls -la                          # List remote directory
sftp> lls                             # List local directory
sftp> put localfile.txt /remote/path/ # Upload file
sftp> get /remote/file.txt ./         # Download file
sftp> mput *.log /remote/logs/        # Upload multiple files
sftp> mkdir /remote/newdir            # Create remote directory
sftp> chmod 640 /remote/file.txt      # Change remote permissions
sftp> bye                             # Exit
rsync чрез SSH (Препоръка за производствена среда)
За синхронизиране на директории, инкрементални резервни копия или големи набори от данни, rsync чрез SSH е значително по-ефективен от SCP или SFTP. Той прехвърля само променените блокове, а не цели файлове.
rsync -avz --progress -e "ssh -p 2222 -i ~/.ssh/id_ed25519" 
  /local/data/ user@your_server_ip:/remote/data/
Флагът -z активира компресия при пренос. За вече компресирани данни (архиви, изображения), пропуснете го — компресията на компресирани данни губи CPU без намаляване на размера на прехвърляните данни.
Пренасочване на SSH портове и тунелиране
Пренасочването на портове е една от най-мощните и недостатъчно използвани възможности на SSH. Позволява ви да получите сигурен достъп до услуги, които не са директно изложени в интернет.
Локално пренасочване на портове
Пренасочване на локален порт към отдалечена услуга. Пример: достъп до отдалечена MySQL инстанция (порт 3306), която е свързана към localhost на сървъра:
ssh -L 3307:127.0.0.1:3306 user@your_server_ip -N
Сега mysql -h 127.0.0.1 -P 3307 на вашата локална машина се свързва през криптирания тунел към отдалечения MySQL.
Отдалечено пренасочване на портове
Излагане на локална услуга към отдалечения сървър. Полезно за тестване на уеб куки или споделяне на локален сървър за разработка:
ssh -R 8080:127.0.0.1:3000 user@your_server_ip -N
Динамично пренасочване на портове (SOCKS прокси)
Превръщане на SSH връзката в SOCKS5 прокси, насочвайки произволен TCP трафик през сървъра:
ssh -D 1080 user@your_server_ip -N
Конфигурирайте браузъра или приложението си да използва SOCKS5 127.0.0.1:1080.
SSH агент и пренасочване на агента
ssh-agent съхранява декриптирани частни ключове в паметта, така че не е необходимо да въвеждате паролата си при всяка връзка.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Пренасочването на агента (ssh -A) позволява на отдалечен сървър да използва вашия локален агент за автентикация към трети сървър. Това е полезно за архитектури с бастион хост, но носи риск: root потребител на междинния сървър може да използва сокета на вашия пренасочен агент. Предпочитайте вместо това ProxyJump:
ssh -J bastion.example.com user@internal-server.example.com
ProxyJump насочва TCP връзката през бастиона, без да излага агента ви на него.
Отстраняване на често срещани SSH проблеми
Връзката е отказана (ssh: connect to host ... port 22: Connection refused)
Систематична диагностика:

Проверете дали SSH демонът работи: systemctl status sshd

• Потвърдете слушащия порт: ss -tlnp | grep sshd
• Проверете правилата на защитната стена: ufw status или iptables -L -n | grep 22
• Проверете дали сървърът е достъпен на мрежово ниво: ping your_server_ip
• Ако използвате облачен доставчик, проверете правилата на групата за сигурност или ACL на мрежата в конзолата на доставчика.

Достъпът е отказан (publickey)

Това е най-честата SSH грешка. Преминете през този контролен списък:

# On the server, check authorized_keys permissions
ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

# Fix permissions if wrong
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

# Verify the public key is actually present
cat ~/.ssh/authorized_keys

# Check sshd logs for the specific rejection reason
journalctl -u sshd -n 50 --no-pager
# or
tail -50 /var/log/auth.log

Чести причини извън разрешенията:

• Файлът authorized_keys съдържа грешен ключ (напр. копирали сте частния ключ вместо файла .pub).

StrictModes yes в sshd_config (по подразбиране) отхвърля връзки, ако разрешенията на домашната директория са твърде отворени — chmod 755 ~ е максимално допустимото.
AllowUsers или AllowGroups в sshd_config изключва свързващия се потребител.
SELinux блокира достъпа до ~/.ssh/ — проверете ausearch -m avc -ts recent.

Изтичане на времето за SSH връзка
# In /etc/ssh/sshd_config (server side)
ClientAliveInterval 60
ClientAliveCountMax 3

# In ~/.ssh/config (client side)
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
ClientAliveInterval изпраща нулев пакет през криптирания канал на всеки 60 секунди. След ClientAliveCountMax последователни пропуснати отговора, сървърът прекратява връзката. Това предотвратява натрупването на зомби сесии.
Проверката на хост ключа е неуспешна
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Това предупреждение означава, че хост ключът на сървъра вече не съответства на съхраненото в ~/.ssh/known_hosts. Законните причини включват преинсталиране на сървъра или преназначаване на IP адрес. Злонамерените причини включват атака тип „човек по средата”. Проучете преди да продължите.
Ако сте потвърдили, че сървърът е бил законно преинсталиран:
ssh-keygen -R your_server_ip
След това се свържете отново и проверете новия пръстов отпечатък на хост ключа спрямо конзолата на сървъра или таблото на доставчика, преди да го приемете.
Многофакторна автентикация за SSH
Автентикацията с ключ е силна, но добавянето на втори фактор TOTP (Еднократна парола, базирана на времето) създава защита в дълбочина. Дори ако частен ключ и неговата парола бъдат компрометирани, нападателят не може да се автентикира без TOTP токена.
Инсталирайте и конфигурирайте libpam-google-authenticator на сървъра:
apt install libpam-google-authenticator
google-authenticator
След това конфигурирайте PAM и sshd_config:
# /etc/pam.d/sshd - add this line
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config
UsePAM yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
С AuthenticationMethods publickey,keyboard-interactive, потребителят трябва да предостави валиден ключ И TOTP код. Това е правилната производствена конфигурация за сървъри с висока стойност.
SSH сертифициращ орган: Мащабиране на управлението на ключове
В среди с десетки сървъри и множество администратори, управлението на отделни записи в authorized_keys става оперативно неустойчиво. SSH сертификатите решават това.
SSH сертифициращ орган (CA) подписва потребителски и хост ключове. Сървърите се доверяват на публичния ключ на CA, а не на отделни потребителски ключове. Добавянето на нов администратор изисква само подписване на техния публичен ключ — без промени в файла authorized_keys на нито един сървър.
# Create a CA key pair (store the private key offline or in a secrets manager)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "infrastructure-ca-2025"

# Sign a user's public key, valid for 7 days, for specific principals
ssh-keygen -s /etc/ssh/ca_key 
  -I "alice-ops-cert" 
  -n alice,deploy 
  -V +7d 
  ~/.ssh/id_ed25519.pub
На всеки сървър конфигурирайте доверие към CA:
# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub
Така управляват SSH достъпа мащабните инфраструктури (включително облачни доставчици и предприятия) без управление на ключове за всеки сървър поотделно.
Практическа матрица за вземане на решения: SSH конфигурация по случай на употреба



Случай на употреба
Тип ключ
Порт
Автентикация с парола
Root влизане
Пренасочване
MFA








—
—
—
—
—
—
—








Личен VPS
Ed25519
2222+
Деактивирана
Забранено
Деактивирано
По избор








Производствен уеб сървър
Ed25519
Нестандартен
Деактивирана
Не
Деактивирано
Задължително








Бастион / jump хост
Ed25519
22 или персонализиран
Деактивирана
Не
Контролирано
Задължително








CI/CD автоматизация
Ed25519 (deploy ключ)
Нестандартен
Деактивирана
Не
Деактивирано
Не (само ключ)








База данни сървър
Ed25519
Нестандартен
Деактивирана
Не
Само локално
Задължително








Сървър за разработка
Ed25519
По подразбиране или персонализиран
По избор
Не
По избор
По избор





Настройване на SSH в инфраструктурата на AlexHost
Когато осигурявате VPS или dedicated сървър чрез AlexHost, SSH достъпът е конфигуриран по подразбиране. Първоначалната root парола се доставя чрез имейла за осигуряване, а препоръчаното първо действие е да:

Влезете като root, създайте не-root административен потребител и добавете публичния си ключ към ~/.ssh/authorized_keys на този потребител.
Приложете базовата линия за укрепване на sshd_config, документирана по-горе.
Деактивирайте автентикацията с парола и влизането като root.
Конфигурирайте защитната си стена да ограничава SSH достъпа до известни IP диапазони, където е оперативно осъществимо.

Ако предпочитате графичен слой за управление заедно с SSH, опциите VPS с cPanel и VPS контролни панели на AlexHost предоставят уеб интерфейс за общи задачи, като оставят SSH наличен за пълен административен контрол.
За среди, в които трябва да защитите уеб приложения, работещи на същия сървър, съчетаването на укрепването на SSH с правилно конфигуриран SSL сертификат покрива както административния, така и транспортния слой на приложението.
Контролен списък с технически ключови изводи
Преди да считате SSH конфигурацията си за готова за производствена среда, проверете всяко от следните:
Управление на ключове

Частните ключове използват Ed25519 или минимум RSA-4096
Всички частни ключове са защитени с силна парола
Директорията ~/.ssh/ има разрешения 700; authorized_keys има 600

• Deploy ключовете използват опциите restrict и command= където е приложимо
• Графикът за ротация на ключовете е документиран и прилаган

Конфигурация на сървъра

PasswordAuthentication no е зададен и активен
PermitRootLogin no или prohibit-password е приложен
SSH работи на нестандартен порт с актуализирани правила на защитната стена
AllowUsers или AllowGroups ограничава достъпа до именувани акаунти
LoginGraceTime е зададен на 30 секунди или по-малко
sshd -t преминава без грешки след всяка промяна в конфигурацията

Криптографско укрепване

KexAlgorithms изключва diffie-hellman-group1-sha1 и diffie-hellman-group14-sha1

• Ciphers изключва 3des-cbc, arcfour и blowfish-cbc
• MACs използва само варианти -etm (encrypt-then-MAC)

Оперативна сигурност

• Журналите за SSH автентикация се наблюдават (/var/log/auth.log или journalctl -u sshd)
• fail2ban или еквивалент е конфигуриран за блокиране на повторни неуспешни автентикации
• Пръстовите отпечатъци на хост ключовете са записани и съхранени извън обхвата за проверка
• MFA е активирано за всички интерактивни потребителски сесии на производствени системи
• SSH CA се използва за среди с повече от пет сървъра или трима администратори

Често задавани въпроси

Каква е разликата между SSH ключове и SSH сертификати?

SSH ключовете изискват всеки сървър да съхранява публичния ключ на потребителя в authorized_keys. SSH сертификатите се подписват от сертифициращ орган; сървърите се доверяват на CA, а не на отделни ключове. Сертификатите се мащабират до големи флотове без управление на ключове за всеки сървър и поддържат времена за изтичане, което прави отмяната лесна.

Защо се появява Permission denied (publickey) дори когато ключът е правилен?

Най-честите причини са неправилни разрешения на файловете за ~/.ssh/ (трябва да бъде 700) или authorized_keys (трябва да бъде 600), домашна директория с разрешения за запис за всички (блокирана от StrictModes) или директива AllowUsers в sshd_config, която изключва свързващия се акаунт. Проверете journalctl -u sshd на сървъра за конкретната причина за отхвърляне.

Промяната на SSH порта от 22 реална мярка за сигурност ли е?

Тя елиминира автоматизираните опортюнистични атаки, насочени към порт 22, което значително намалява шума в журналите и неуспешните опити за автентикация. Не защитава срещу целенасочен нападател, който извършва сканиране на портове. Трябва да се комбинира с fail2ban, автентикация само с ключ и разрешителен списък с IP адреси в защитната стена за значително подобрение на сигурността.

Мога ли да използвам SSH без статичен IP адрес от страна на клиента?

Да. Автентикацията с ключ не изисква фиксиран клиентски IP. Ако искате да ограничите по IP, използвайте опцията from= в authorized_keys или правила на защитната стена. За динамични IP адреси, помислете за VPN за установяване на стабилна мрежова идентичност преди свързване, вместо да отваряте SSH за целия интернет.

Какъв е най-сигурният начин за възстановяване на SSH достъп при блокиране?

Достъпете сървъра чрез out-of-band конзолата на вашия хостинг доставчик (VNC, IPMI или KVM over IP). Оттам монтирайте файловата система, коригирайте проблема с sshd_config или authorized_keys и рестартирайте SSH демона. При плановете за VPS и dedicated сървър на AlexHost, конзолата на доставчика е достъпна чрез клиентския портал и не зависи от функционалността на SSH.