SSH Permission denied (publickey) - jak naprawić błąd

Co w rzeczywistości oznacza błąd Permission denied (publickey)

Błąd Permission denied (publickey) oznacza, że klient wysłał jeden lub więcej kluczy publicznych, a serwer nie zaakceptował żadnego z nich. Połączenie sieciowe działa poprawnie, a usługa sshd jest uruchomiona: odmowa następuje na ostatnim etapie uwierzytelniania. Jeśli sesja kończy się przed tym momentem, przyczyną jest connection refused lub connection timed out, co stanowi odrębny przypadek wymagający innych testów. Rozwiązanie nie powinno być zgadywane, ponieważ ssh -v wskazuje, która z pięciu przyczyn występuje w danym przypadku.

Słowa w nawiasach określają metody, które serwer jest gotów zaakceptować. Komunikat Permission denied (publickey) oznacza, że logowanie hasłem jest na serwerze wyłączone, więc nie ma możliwości skorzystania z tej metody jako alternatywy. Komunikat Permission denied (publickey,password) oznacza, że logowanie hasłem było dostępne, ale próba ta również zakończyła się niepowodzeniem.

Jeden komunikat obejmuje pięć różnych błędów i jest celowo nieprecyzyjny. Serwer, który odpowiadałby "no such user" lub "that key is not installed", ułatwiałby zadanie osobom skanującym sieć w poszukiwaniu prawidłowych kont. Dlatego nie należy rozpoczynać od wymiany kluczy ani edycji plików konfiguracyjnych. Należy wykonać jedno polecenie, odczytać trzy linie wyjścia, co pozwoli zawęzić pięć możliwych przyczyn do jednej.

Uruchom najpierw ssh -v i przeczytaj trzy linie

Powtórz polecenie, które zakończyło się niepowodzeniem, dodając -v:

ssh -v deploy@203.0.113.10

Oczyszczony, lecz realistyczny wynik wygląda następująco:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

Trzy linie zawierają wszystkie niezbędne informacje.

Authenticating to 203.0.113.10:22 as 'deploy' to nazwa użytkownika, która zostanie faktycznie użyta. Nie ta, którą zamierzałeś podać: to nazwa, którą ssh wywiodło z linii poleceń, z ~/.ssh/config lub z Twojej lokalnej nazwy użytkownika.

Authentications that can continue: publickey to lista metod akceptowanych przez serwer, wysyłana przed próbą użycia jakiegokolwiek klucza. Jeśli publickey brakuje na tej początkowej liście, serwer ma wyłączone logowanie za pomocą klucza publicznego, więc żaden klucz nie zadziała.

Offering public key: ... to jedna linia dla każdego klucza faktycznie wysłanego przez klienta, wskazująca plik, z którego pochodzi, oraz jego odcisk SHA256. Klucz, dla którego nie ma linii Offering, nigdy nie został wysłany do serwera.

Teraz podziel problem na dwie części:

• Brak linii Offering public key dla oczekiwanego klucza. Błąd leży po stronie Twojej maszyny, ponieważ serwer w ogóle nie otrzymał Twojego klucza.
• Klucz został zaoferowany, a mimo to ponownie pojawia się Authentications that can continue: publickey. Serwer otrzymał ten klucz i go odrzucił, więc błąd leży po stronie serwera.

Poniższe przyczyny zostały uszeregowane według częstotliwości występowania.

Przyczyna 1: połączenie z użyciem błędnej nazwy użytkownika

Najczęstsza przyczyna jest jednocześnie najmniej złożona. sshd, demon serwera SSH (secure shell), nigdy nie informuje o nieistniejącym koncie. Przeprowadza pełną wymianę danych dla wymyślonej nazwy użytkownika, a na końcu odmawia dostępu z tym samym komunikatem, ponieważ ujawnianie poprawnych nazw kont ułatwia atak. Literówka w nazwie użytkownika wygląda identycznie jak uszkodzony klucz.

Przed podjęciem innych działań sprawdź linię Authenticating to ... as. Jeśli wskazuje ona na nazwę użytkownika z Twojego laptopa zamiast na konto serwerowe, oznacza to, że w poleceniu pominięto nazwę użytkownika.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

Domyślne konto zależy od obrazu przygotowanego przez dostawcę. Według stanu na sierpień 2026, obrazy chmurowe Ubuntu zazwyczaj zawierają konto ubuntu, obrazy Debian zawierają debian lub admin, Rocky Linux i AlmaLinux zawierają rocky oraz almalinux, a wielu dostawców VPS instaluje klucz bezpośrednio w root. Panel sterowania dostawcy zawiera informację o tym, jakie konto zostało utworzone. Żadne polecenie uruchomione spoza serwera nie jest w stanie tego sprawdzić.

Blok Host w pliku ~/.ssh/config również definiuje nazwę użytkownika i ma ona pierwszeństwo przed lokalną nazwą użytkownika:

Host vps-prod
  HostName 203.0.113.10
  User deploy

Jeśli konto zostało utworzone samodzielnie, a logowanie nie powiodło się, prawdopodobnie klucz został zainstalowany dla domyślnego użytkownika obrazu i nie został skopiowany. Ten krok jest częścią poradnika pierwsze dziesięć minut na nowym VPS i łatwo go pominąć.

Przyczyna 2: klucz, który według Ciebie jest wysyłany, nie jest tym, który faktycznie jest wysyłany

Domyślnie ssh oferuje tylko klucze przechowywane przez ssh-agent oraz stały zestaw nazw plików w ~/.ssh: id_ed25519, id_ecdsa, id_rsa, a także warianty sprzętowe i DSA tych nazw. Klucz zapisany jako ~/.ssh/vps-prod jest niewidoczny dla ssh, dopóki nie zostanie wskazany z nazwy, dlatego szczegółowe wyjście (verbose) nie pokazuje dla niego linii Offering public key.

Wskaż plik i zablokuj klucze agenta, aby nie zajmowały jego miejsca:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

Samo -i nie wystarcza, gdy agent przechowuje klucze, ponieważ ssh nadal oferuje klucze agenta w pierwszej kolejności, a wskazany plik na końcu. Ma to znaczenie, ponieważ serwer zlicza każdy odrzucony klucz do limitu MaxAuthTries, który domyślnie wynosi 6. Agent przechowujący siedem kluczy może wyczerpać limit, zanim ssh dotrze do właściwego klucza, co skutkuje zmianą komunikatu na:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

Jeśli zamiast tego wyświetlany jest ten komunikat, serwer przerwał sesję, zanim została użyta właściwa klucz, co opisano w sekcji zbyt wiele nieudanych prób uwierzytelniania. IdentitiesOnly=yes ogranicza próbę do przekazanego pliku. Zawartość przechowywaną przez agenta można wyświetlić za pomocą ssh-add -l, a następnie usunąć ją za pomocą ssh-add -D, jeśli agent zgromadził stare klucze z wielu lat. Następnie należy zapisać ustawienia, aby kolejne logowanie nie wymagało pamiętania flag:

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

Jeszcze jedna pułapka po stronie klienta. ssh odmawia użycia klucza prywatnego, jeśli inne konta na Twoim komputerze mają do niego uprawnienia do odczytu. Wyświetlane jest ostrzeżenie, a klucz jest ignorowany, więc nigdy nie jest oferowany i serwer go nie widzi:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod rozwiązuje ten problem. Przenoszenie klucza przez pamięć USB lub udział sieciowy Windows to najczęstszy powód utraty odpowiednich uprawnień. Lokalizacja kluczy oraz zasady ich nazywania zostały opisane w podstawy zarządzania kluczami SSH.

Przyczyna 3: klucz publiczny nie trafił do pliku authorized_keys

Jeśli ssh -v wskazuje na wysłanie klucza, a serwer nadal odmawia dostępu, należy sprawdzić, czy klucz znajduje się w pliku authorized_keys danego konta. Należy otworzyć konsolę dostawcy usług, ponieważ logowanie przez SSH jest niemożliwe.

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

Polecenie ssh-keygen -lf wykonane na pliku authorized_keys wyświetla jeden odcisk klucza (fingerprint) dla każdego wpisu:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

Należy porównać te wartości z odciskiem klucza w linii Offering public key. Jeśli klucza nie ma na liście, oznacza to, że nie został on zainstalowany dla tego konta, niezależnie od podjętych wcześniej działań.

Oto cztery najczęstsze przyczyny problemów:

• Wklejono klucz prywatny zamiast zawartości pliku .pub. Linia klucza publicznego zaczyna się od ssh-ed25519 lub ssh-rsa. Klucz prywatny zaczyna się od -----BEGIN OPENSSH PRIVATE KEY-----.
• Wklejony tekst został automatycznie zawinięty w wielu liniach. Każdy wpis musi znajdować się dokładnie w jednej linii; zawinięty klucz jest interpretowany jako kilka uszkodzonych wpisów i nie pasuje do żadnego z nich.
• Klucz dodano do /root/.ssh/authorized_keys, podczas gdy logowanie odbywa się jako deploy (lub odwrotnie). Plik jest przypisany do konkretnego konta i nie istnieje plik współdzielony.
• Funkcja "add my key" w panelu dostawcy dodała klucz tylko dla domyślnego użytkownika obrazu systemu, przez co konto utworzone później posiada pusty katalog .ssh.

Bezpieczny sposób dodania klucza z poziomu konsoli, jako root:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

Następnie należy ponownie uruchomić sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys. Nowy odcisk klucza powinien pojawić się na liście. Z maszyny, która nadal pozwala na logowanie hasłem, polecenie ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 wykonuje to samo zadanie i automatycznie ustawia poprawne uprawnienia.

Przyczyna 4: dlaczego sshd ignoruje authorized_keys przy zbyt otwartych uprawnieniach

StrictModes yes to domyślne ustawienie sshd. Zgodnie z nim sshd odmawia odczytu authorized_keys, jeśli ten plik, katalog .ssh lub katalog domowy użytkownika mogą być zapisywane przez kogokolwiek innego niż właściciel. Powód jest bezpośredni: jeśli grupa lub inni użytkownicy mają uprawnienia do zapisu w katalogu domowym, każde konto z takim dostępem może podmienić authorized_keys i przejąć logowanie. sshd traktuje niezaufaną ścieżkę tak, jakby klucz nie istniał.

Klient otrzymuje prosty komunikat Permission denied. Dziennik serwera rejestruje rzeczywistą przyczynę:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

lub, gdy problemem jest sam plik:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

Co sshd zaakceptuje:

• Katalog domowy: brak uprawnień do zapisu dla grupy i innych użytkowników. 755, 750 oraz 700 są poprawne. 775 oraz 777 kończą się niepowodzeniem.
• ~/.ssh: tryb 700.
• ~/.ssh/authorized_keys: tryb 600.
• Własność: wszystkie trzy elementy muszą należeć do konta, na które następuje logowanie, a nie do root.

Własność jest równie ważna jak tryb. Plik wewnątrz /home/deploy/.ssh należący do root nie przejdzie tej samej kontroli, co zdarza się przy tworzeniu go za pomocą sudo nano i zapomnieniu o zmianie właściciela. Napraw oba parametry jednocześnie:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

Ostatnie polecenie pokazuje wynik. Wymagane jest drwxr-xr-x lub bardziej restrykcyjne uprawnienia dla katalogu domowego oraz drwx------ dla .ssh. Jeśli te ciągi znaków nie są jeszcze zrozumiałe, przeczytaj jak interpretować ciąg uprawnień typu drwxr-xr-x przed zmianą trybów na działającym serwerze.

W systemach Rocky Linux i AlmaLinux dodaj SELinux (security-enhanced Linux) do listy podejrzanych. Katalog .ssh utworzony w nietypowy sposób może posiadać błędną etykietę pliku, przez co sshd otrzymuje odmowę dostępu do odczytu, mimo że tryby wyglądają na poprawne. sudo restorecon -Rv /home/deploy/.ssh przywraca właściwe etykiety, a sudo ausearch -m avc -ts recent pokazuje, czy to SELinux był komponentem blokującym dostęp.

Przyczyna 5: konfiguracja sshd odrzuca połączenie

Samo odczytanie /etc/ssh/sshd_config w nowoczesnych systemach Ubuntu lub Debian nie wystarcza. Plik ten zaczyna się od Include /etc/ssh/sshd_config.d/*.conf, a OpenSSH przyjmuje pierwszą napotkaną wartość dla każdego ustawienia. Plik typu drop-in, taki jak 50-cloud-init.conf, jest odczytywany jako pierwszy i ma pierwszeństwo przed wszelkimi zmianami wprowadzonymi w dalszej części głównego pliku. Dlatego edycja może wyglądać na poprawną, nie przynosząc żadnego efektu.

Należy zapytać sshd o konfigurację, która jest faktycznie używana:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

Poprawna odpowiedź wygląda następująco:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

Na co zwrócić uwagę w danych wyjściowych:

• pubkeyauthentication no. Żaden klucz nie zostanie zaakceptowany. Informacja ta pojawia się również w ssh -v jako pierwsza lista Authentications that can continue:, w której nie ma publickey.
• authorizedkeysfile wskazujące na inną lokalizację, na przykład /etc/ssh/authorized_keys/%u. Plik w katalogu domowym jest wtedy całkowicie ignorowany, a zasady dotyczące uprawnień z przyczyny 4 mają zastosowanie do nowej ścieżki.
• Obecność allowusers lub allowgroups. Każde konto, którego nie ma na liście, jest odrzucane z tym konkretnym błędem bez dodatkowych wyjaśnień. denyusers oraz denygroups działają analogicznie w odwrotnym kierunku.
• permitrootlogin no podczas próby logowania jako root. prohibit-password to przydatne ustawienie pośrednie: root może użyć klucza, ale nie hasła.

Bloki Match nie pojawiają się w zwykłym sshd -T, ponieważ ich wynik zależy od tego, kto się łączy. Należy sprawdzić konkretne połączenie:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

Jeszcze jedno ustawienie wpływa na starsze klucze. OpenSSH 8.8 domyślnie przestał akceptować podpisy SHA-1 (ssh-rsa), więc klucz RSA, który działał przez lata, może przestać działać zaraz po aktualizacji serwera. Klient informuje o tym wprost:

debug1: send_pubkey_test: no mutual signature algorithm

Poprawnym rozwiązaniem jest wygenerowanie nowego klucza: ssh-keygen -t ed25519 -C "deploy@vps-prod", a następnie zainstalowanie pliku .pub w sposób opisany powyżej. Ustawienie PubkeyAcceptedAlgorithms +ssh-rsa na serwerze ponownie włącza stare podpisy i umożliwia dostęp, należy je jednak traktować jako tymczasowy sposób na uzyskanie dostępu, a nie jako docelowe rozwiązanie. Pozostałe ustawienia serwera, które warto przejrzeć, znajdują się w zabezpieczanie serwera SSH na VPS.

Jak zweryfikować zgodność klucza prywatnego z zainstalowanym kluczem publicznym

Większość domysłów w przypadku tego błędu wynika z braku pewności, czy dwa pliki stanowią parę. Jedno polecenie pozwala to rozstrzygnąć:

ssh-keygen -y -f ~/.ssh/vps-prod

Polecenie to wypisuje klucz publiczny wygenerowany na podstawie klucza prywatnego. Nie odczytuje ono pliku .pub znajdującego się obok, dzięki czemu wskazuje rzeczywistą zawartość klucza prywatnego, a nie to, co sugeruje nieaktualny plik .pub. Jeśli klucz jest zabezpieczony hasłem, polecenie poprosi o jego podanie, co jednocześnie potwierdza znajomość tego hasła.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

Pierwsze polecenie wyświetla odcisk palca (fingerprint) pliku klucza publicznego. Drugie wyświetla odciski palców przechowywane w agencie. Należy teraz zestawić cztery widoki tego samego ciągu znaków: odcisk palca w linii Offering public key z pliku ssh -v, odcisk palca pliku .pub, odciski palców w ssh-keygen -lf na serwerze w pliku authorized_keys oraz odcisk palca w dzienniku serwera. Miejsce, w którym przestają się one zgadzać, wskazuje źródło błędu.

Odczyt dziennika serwera podczas nieudanego logowania

Klient celowo nie otrzymuje żadnych użytecznych informacji. Serwer zapisuje rzeczywistą przyczynę. Uruchom śledzenie dziennika w sesji konsoli, a następnie wykonaj nieudaną komendę ssh ze swojego laptopa.

sudo journalctl -u ssh -f

Ubuntu 24.04 domyślnie nie instaluje rsyslog, więc /var/log/auth.log może tam nie istnieć. W systemach Rocky Linux i AlmaLinux jednostka nosi nazwę sshd, a te same wpisy trafiają również do /var/log/secure.

Ustaw LogLevel VERBOSE w konfiguracji sshd i przeładuj usługę. Każda próba logowania spowoduje zapisanie w dzienniku odcisku klucza, który faktycznie otrzymał serwer:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

Ten wiersz wskazuje, po której stronie leży błąd. Rozpoznawalny odcisk oznacza, że klucz dotarł, ale został odrzucony przez serwer – należy wówczas sprawdzić przyczyny 3, 4 i 5. Nierozpoznawalny odcisk oznacza, że klient wysłał inny klucz niż zamierzony – należy wrócić do przyczyny 2.

Jeśli dziennik nadal nie jest jasny, uruchom drugą instancję sshd na innym porcie w trybie debugowania. Pozostaje ona na pierwszym planie, obsługuje jedno połączenie, wypisuje powód decyzji, a następnie kończy działanie:

sudo /usr/sbin/sshd -ddd -p 2222

Z sesji konsoli na tym samym serwerze połącz się z nią przez adres loopback:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

Użycie 127.0.0.1 pozwala wykluczyć firewall z testu. Dane wyjściowe trybu debugowania wskazują otwarty plik, porównany odcisk oraz dokładną przyczynę odmowy, w tym wiersze takie jak Authentication refused: bad ownership or modes for directory /home/deploy. Naciśnij Ctrl+C, gdy uzyskasz odpowiedź. Rzeczywisty proces sshd na porcie 22 pozostaje w tym czasie nienaruszony.

Jak uniknąć utraty dostępu do serwera

Każda operacja edycji konfiguracji serwera wymaga posiadania alternatywnej metody dostępu, która nie zależy od SSH. Należy ją skonfigurować, gdy SSH jeszcze działa, a nie po wystąpieniu awarii.

1. Otwórz konsolę dostawcy przez port szeregowy lub VNC (virtual network computing) i upewnij się, że logowanie przebiega pomyślnie.
2. Upewnij się, że znasz działające hasło lokalne dla konta z uprawnieniami sudo. Jeśli go nie posiadasz, najpierw zresetuj hasło root z poziomu konsoli dostawcy.
3. Pozostaw bieżącą sesję SSH otwartą. Otwarta sesja przetrwa systemctl restart ssh, więc pozostanie drogą powrotu, jeśli nowa konfiguracja okaże się błędna.
4. Sprawdź składnię przed restartem: sudo sshd -t nie wyświetla nic, gdy plik jest poprawny, a w przeciwnym razie wskazuje plik oraz numer linii z błędem.
5. Otwórz drugie okno terminala i zaloguj się ponownie przed zamknięciem pierwszego. Błędna konfiguracja blokuje nowe logowania, ale nie przerywa istniejących sesji, więc sesja, w której pracujesz, nie potwierdzi, czy zmiana zadziałała.

Zrestartuj usługę za pomocą sudo systemctl restart ssh w systemach Debian i Ubuntu lub sudo systemctl restart sshd w systemach Rocky Linux i AlmaLinux. W systemie Ubuntu 24.04 usługa sshd jest uruchamiana z jednostki typu socket, więc zmiana w Port lub ListenAddress wymaga również wykonania sudo systemctl restart ssh.socket, aby weszła w życie.

FAQ

Dlaczego otrzymuję błąd Permission denied (publickey), skoro ten sam klucz działa na innym serwerze?

Ponieważ klucz jest poprawny, a problem leży w jego otoczeniu. Uruchom ssh -v i znajdź linię Offering public key. Jeśli klucza nie ma na liście, ssh go nie wysłało: plik nie znajduje się w ~/.ssh pod domyślną nazwą i nie został załadowany do agenta, więc dodaj go za pomocą -i /path/to/key -o IdentitiesOnly=yes. Jeśli klucz jest na liście, a serwer nadal odmawia dostępu, oznacza to, że klucza brakuje w pliku authorized_keys na koncie użytkownika, ścieżka do niego jest zapisywalna przez grupę lub konfiguracja sshd blokuje użytkownika. Dziennik serwera pozwala rozróżnić te przypadki.

Jak sprawdzić, który klucz jest faktycznie wysyłany przez SSH?

ssh -v host wyświetla jedną linię debug1: Offering public key: dla każdego klucza, wskazując plik źródłowy oraz odcisk palca SHA256. ssh-add -l wypisuje odciski palców przechowywane w agencie. ssh-keygen -lf ~/.ssh/id_ed25519.pub drukuje odcisk palca pojedynczego pliku klucza, a ssh-keygen -y -f ~/.ssh/id_ed25519 wyświetla klucz publiczny wygenerowany z klucza prywatnego. Aby logowanie powiodło się, odcisk palca z linii Offering musi również pojawić się w wyniku ssh-keygen -lf uruchomionego dla pliku authorized_keys na serwerze.

Dlaczego sshd ignoruje mój plik authorized_keys?

Ponieważ StrictModes jest domyślnie włączone, a plik, katalog .ssh lub katalog domowy są zapisywalne przez grupę lub wszystkich, albo należą do niewłaściwego użytkownika. sshd nie ufa ścieżce, którą może zmienić ktoś inny, więc zachowuje się tak, jakby klucz nie istniał. Ustaw uprawnienia katalogu domowego na 755 lub bardziej restrykcyjne, .ssh na 700, authorized_keys na 600 i upewnij się, że właścicielem wszystkich trzech jest konto użytkownika. Dzięki LogLevel VERBOSE serwer rejestruje Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

Mój klucz przestał działać zaraz po aktualizacji serwera. Co się zmieniło?

Jeśli jest to klucz RSA, najprawdopodobniej przyczyną jest zmiana dotycząca SHA-1. OpenSSH 8.8 domyślnie wyłączyło podpisy ssh-rsa SHA-1, więc klucz, który może podpisywać tylko w ten sposób, jest teraz odrzucany. Szczegółowe wyjście klienta pokazuje debug1: send_pubkey_test: no mutual signature algorithm. Wygeneruj nowoczesny klucz za pomocą ssh-keygen -t ed25519 i zainstaluj jego plik .pub. Jeśli potrzebujesz natychmiastowego dostępu, PubkeyAcceptedAlgorithms +ssh-rsa na serwerze ponownie włączy stare podpisy; usuń tę linię, gdy nowy klucz zacznie działać.

Edytowałem sshd_config i teraz w ogóle nie mogę się zalogować. Jak odzyskać dostęp?

Użyj konsoli dostarczonej przez dostawcę, która nie korzysta z SSH. Zaloguj się tam za pomocą lokalnego hasła, uruchom sudo sshd -t, aby sprawdzić błąd składni i numer linii, cofnij zmiany i zrestartuj usługę. Następnie sprawdź sudo sshd -T, aby potwierdzić aktualne wartości, ponieważ plik w /etc/ssh/sshd_config.d/ może nadpisywać główną konfigurację. Jeśli nie masz lokalnego hasła, najpierw zresetuj hasło roota z poziomu konsoli, a następnie napraw plik.