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

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. Rozwiązanie problemu nie powinno opierać się na domysłach, 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 uwierzytelnienia tą metodą 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 „brak takiego użytkownika” lub „ten klucz nie jest zainstalowany”, ułatwiałby zadanie osobom skanującym systemy 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, a liczba możliwych przyczyn ograniczy się 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

Skrócony, 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órej zamierzałeś użyć, lecz ta, którą ssh wywnioskowało z wiersza 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 pierwszej liście, logowanie za pomocą klucza publicznego jest na serwerze wyłączone, 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. Przyczyna leży po stronie Twojej maszyny, ponieważ serwer w ogóle nie otrzymał Twojego klucza.
• Klucz został zaoferowany, a komunikat Authentications that can continue: publickey pojawia się ponownie. Serwer otrzymał ten klucz i go odrzucił, więc przyczyna leży po stronie serwera.

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

Przyczyna 1: logowanie przy użyciu nieprawidłowej nazwy użytkownika

Najczęstsza przyczyna jest jednocześnie najmniej interesująca. 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 tym samym komunikatem, ponieważ ujawnianie poprawnych nazw kont ułatwia atak. Literówka w nazwie użytkownika wygląda dokładnie tak samo jak uszkodzony klucz.

Przed wykonaniem jakichkolwiek innych czynności sprawdź linię Authenticating to ... as. Jeśli wskazuje ona nazwę użytkownika z Twojego laptopa zamiast konta na serwerze, 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 dostarczają konto ubuntu, obrazy Debian zawierają debian lub admin, Rocky Linux i AlmaLinux oferują rocky oraz almalinux, a wielu dostawców VPS instaluje klucz bezpośrednio dla użytkownika root. Panel sterowania dostawcy rejestruje, 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 na nie nie jest możliwe, klucz prawdopodobnie 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 ma być wysłany, nie jest tym, który jest faktycznie 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 zawiera dla niego linii Offering public key.

Wskaż plik i zablokuj użycie kluczy z agenta:

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órego domyślna wartość 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

IdentitiesOnly=yes ogranicza próbę uwierzytelnienia wyłącznie do wskazanego pliku. Wyświetl listę kluczy przechowywanych przez agenta za pomocą ssh-add -l i wyczyść ją poleceniem ssh-add -D, jeśli zgromadziły się w nim stare klucze. Następnie zapisz ustawienia, aby kolejne logowanie nie wymagało pamiętania o flagach:

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 w systemie mają do niego uprawnienia odczytu. Wyświetlane jest ostrzeżenie, a klucz jest ignorowany, więc nie jest oferowany serwerowi i pozostaje niewidoczny:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         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ły sieciowe Windows to najczęstsza przyczyna utraty poprawnych 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 w celu weryfikacji 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 palca (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 palca w wierszu Offering public key. Jeśli brakuje go na liście, klucz nie został zainstalowany dla tego konta, niezależnie od podjętych wcześniej działań.

Występują cztery częste przyczyny tego problemu:

• Wklejono klucz prywatny zamiast zawartości pliku .pub. Wiersz 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 wierszach. Każdy wpis musi znajdować się dokładnie w jednym wierszu; zawinięty klucz jest interpretowany jako kilka uszkodzonych wpisów i nie pasuje do żadnego z nich.
• Klucz trafił 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.
• Pole "add my key" w panelu dostawcy dodało 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 palca 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 żaden 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 i 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 co tryb dostępu. 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, nawet jeśli tryby wyglądają na poprawne. sudo restorecon -Rv /home/deploy/.ssh przywraca 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 nie wystarcza w nowoczesnych systemach Ubuntu lub Debian. 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 sprawdzić, jakiej konfiguracji faktycznie używa sshd:

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 wyjściu polecenia:

• pubkeyauthentication no. Żaden klucz nie zostanie zaakceptowany. Występuje to również w ssh -v jako pierwsza lista Authentications that can continue: bez żadnego 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 drugą stronę.
• permitrootlogin no podczas próby logowania jako root. prohibit-password to użyteczne 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ło akceptować podpisy SHA-1 (ssh-rsa), więc klucz RSA działający 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 zgodnie z powyższym opisem. Ustawienie PubkeyAcceptedAlgorithms +ssh-rsa na serwerze ponownie włącza stare podpisy i pozwala na zalogowanie się, należy je jednak traktować jako tymczasowy sposób uzyskania dostępu, a nie jako docelowe rozwiązanie. Pozostałe ustawienia po stronie serwera, które warto przejrzeć, znajdują się w zabezpieczaniu 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 wyświetla 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 dodatkowo potwierdza znajomość 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 przez agenta. Należy teraz zestawić ze sobą cztery wartości: odcisk palca w linii Offering public key z pliku ssh -v, odcisk palca pliku .pub, odciski palców w pliku ssh-keygen -lf na serwerze w lokalizacji authorized_keys oraz odcisk palca w dzienniku serwera. Punkt, w którym wartości przestają się zgadzać, wskazuje na źródło błędu.

Odczyt dziennika serwera podczas nieudanego logowania

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

sudo journalctl -u ssh -f

System Ubuntu 24.04 nie instaluje domyślnie rsyslog, więc plik /var/log/auth.log może tam nie istnieć. W systemach Rocky Linux oraz 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 wówczas zapisanie 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 oraz 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 szczegółową diagnostykę, 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 nim przez adres pętli zwrotnej (loopback):

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

Użycie 127.0.0.1 pozwala wykluczyć wpływ firewalla na test. Dane wyjściowe trybu debugowania wskazują otwarty plik, porównany odcisk klucza oraz dokładną przyczynę odmowy, w tym wiersze takie jak Authentication refused: bad ownership or modes for directory /home/deploy. Po uzyskaniu odpowiedzi naciśnij Ctrl+C. Główny 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 drogi dostępu, która nie zależy od SSH. Należy ją skonfigurować, gdy połączenie SSH jeszcze działa, a nie po jego zerwaniu.

1. Otwórz konsolę dostawcy przez port szeregowy lub VNC (virtual network computing) i upewnij się, że możesz się przez nią zalogować.
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 użytkownika root z poziomu konsoli dostawcy.
3. Pozostaw bieżącą sesję SSH otwartą. Otwarta sesja przetrwa systemctl restart ssh, dzięki czemu pozostanie drogą powrotu, jeśli nowa konfiguracja okaże się błędna.
4. Sprawdź składnię przed restartem: sudo sshd -t nie wyświetla żadnych komunikatów, 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 aktualnie pracujesz, nie pozwoli zweryfikować poprawności wprowadzonych zmian.

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, dlatego 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 klucz nie jest wymieniony, 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 wymieniony, a serwer nadal odmawia dostępu, oznacza to, że klucz nie znajduje się w pliku authorized_keys na koncie, ś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 wymienia odciski palców przechowywane przez agenta. 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 innych użytkowników, albo należą do niewłaściwego konta. sshd nie ufa ścieżce, którą może zmienić ktoś inny, więc zachowuje się tak, jakby żaden 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 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łącza 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 zobaczyć 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 root z poziomu konsoli, a następnie napraw plik.