Permission denied (publickey): jak najít skutečnou příčinu

Permission denied (publickey) znamená jedinou věc: server povoluje jen ověření klíčem, klient nabídl všechny klíče, které měl, a žádný z nich nebyl přijat. Chyba ti neřekne proč a je to záměr - server nebude vysvětlovat odmítnutí někomu, kdo může být útočník. Vysvětlení ale existuje. Je rozdělené na dvě místa: ssh -v na tvé straně, které ukáže, jaké klíče se nabízely a jak server odpověděl, a autentizační log na serveru, který řekne, proč byl ignorován klíč, jenž měl fungovat.

Přečti si je v tomto pořadí a téměř každý případ spadne do jedné ze šesti skupin: správný klíč se nikdy nenabídl, žádá se o špatného uživatele, server nemůže důvěřovat souborům s tvým klíčem, klíč nebo jeho podpisový algoritmus je odmítnut, překáží agent, nebo přihlášení zablokuje bezpečnostní vrstva jako SELinux či řádek AllowUsers dřív, než na klíčích vůbec záleží. Tento článek projde každou z nich a ukáže přesné řádky, podle kterých ji poznáš.

Pokud klíče nastavuješ poprvé a neladíš je, najdeš generování, instalaci a zabezpečení v článku SSH klíče a zabezpečení sshd_config. Tenhle článek začíná v okamžiku, kdy se dveře neotevřou.

Nejdřív: nech si cestu dovnitř#

Pokud se na server ještě dostaneš jakoukoli cestou - otevřená relace, druhý účet, heslo, které stále funguje, konzole od poskytovatele - drž ji otevřenou, dokud ladíš. Několik oprav níže znamená úpravu sshd_config nebo oprávnění souborů na serveru a chyba tam promění jeden zamčený účet v zamčený stroj.

Pokud se nedostaneš dovnitř vůbec, musí se každá oprava na straně serveru udělat přes konzoli poskytovatele nebo záchranný systém. Je to pomalejší, ale diagnóza je stejná: výstup klienta níže ti pořád řekne, co je špatně, a logy budou na disku, až se k nim dostaneš.

Čtení ssh -v: příběh z pohledu klienta#

Spusť připojení znovu s jedním -v. Dvě nebo tři (-vvv) přidávají detaily, které se u této chyby málokdy hodí a výstup je pak hůř čitelný.

$ ssh -v deploy@203.0.113.10

Důležité řádky z neúspěšného pokusu vypadají takto:

debug1: Authenticating to 203.0.113.10:22 as 'deploy'debug1: identity file /home/alex/.ssh/id_rsa type -1debug1: identity file /home/alex/.ssh/id_ed25519 type 3debug1: Authentications that can continue: publickeydebug1: Next authentication method: publickeydebug1: Offering public key: /home/alex/.ssh/id_ed25519 ED25519 SHA256:5xM8n... agentdebug1: Authentications that can continue: publickeydebug1: No more authentication methods to try.deploy@203.0.113.10: Permission denied (publickey).

Čti to shora dolů s těmito otázkami.

1. Který uživatel? as 'deploy' je účet, o který se na serveru žádá. Pokud je tam uživatelské jméno z tvého notebooku místo účtu na serveru, zapomněl jsi user@ nebo v ~/.ssh/config chybí pro tento host řádek User.
2. Které soubory s klíči existují? type -1 znamená, že soubor nebyl nalezen nebo ho nešlo přečíst. Jakékoli jiné číslo znamená, že ho klient načetl. Pokud klíč, který čekáš, ukazuje type -1, klient ho nikdy neměl.
3. Které klíče se nabízely? Každý řádek Offering public key: je jeden pokus s cestou k souboru a otisky. Pokud klíč, který jsi nainstaloval na server, v tomto seznamu není, na serveru zatím nezáleží - oprav nejdřív klienta.
4. Jak odpověděl server? Po nabídce znamená Server accepts key:, že server našel ten veřejný klíč v authorized_keys a zbývá už jen podpis. Další Authentications that can continue: publickey hned po nabídce znamená, že server hledal a nenašel, nebo našel a nechtěl mu důvěřovat.

Tento rozdíl rozděluje problém na polovinu. „Nabídnuto, nepřijato“ je problém na straně serveru: špatný soubor, špatná oprávnění, špatný uživatel, pravidlo, které klíč odmítá. „Přijato a pak odmítnuto“ je téměř vždy krok podpisu: agent, který nemůže podepsat, nebo algoritmus, na kterém se obě strany nedomluví.

Otisky ti umožní ověřit, že nabízíš ten klíč, o kterém si myslíš, že jsi ho nainstaloval. Porovnej, co nabízí klient, s tím, co drží server:

$ ssh-keygen -lf ~/.ssh/id_ed25519.pub              # on your machine$ ssh-keygen -lf /home/deploy/.ssh/authorized_keys  # on the server, one line per key

Pokud žádný otisk na serveru neodpovídá žádnému nabídnutému klientem, našel jsi problém, aniž ses dotkl logu.

Klíč, který se nikdy nenabídl#

Nejčastější příčina ze všech, a ta, kterou lidé čekají nejméně, je, že klient prostě nezkusil správný klíč.

Klient OpenSSH hledá výchozí názvy souborů: id_rsa, id_ecdsa, id_ecdsa_sk, id_ed25519, id_ed25519_sk a k tomu to, co drží agent. Klíč uložený jako ~/.ssh/work_server nebo ~/.ssh/github je neviditelný, dokud ho nepojmenuješ. Na zkoušku to udělej na příkazové řádce, pak v konfiguraci, abys to už nikdy nemusel opakovat:

$ ssh -i ~/.ssh/work_server -o IdentitiesOnly=yes deploy@203.0.113.10

Host web-01    HostName 203.0.113.10    User deploy    IdentityFile ~/.ssh/work_server    IdentitiesOnly yes

IdentitiesOnly yes má smysl i v opačném směru. Bez něj klient nabídne každý klíč v agentovi dřív, než se dostane k souboru, který jsi pojmenoval, a každý se započítává do MaxAuthTries serveru (výchozí 6). Při dostatku načtených klíčů tě odpojí s Too many authentication failures, i když držíš správný klíč, což vypadá jako stejný problém a není.

Další tři způsoby, jak se správný klíč ztratí:

• `sudo ssh` běží jako root a čte /root/.ssh, ne tvoje. Skripty, které volají ssh pod sudo, cron úlohy běžící pod jiným uživatelem a CI runnery mají všechny vlastní domovský adresář a vlastní klíče.
• Soukromý klíč, který klient odmítne načíst. Pokud je soubor čitelný pro ostatní uživatele, klient nad řádky ladění vypíše WARNING: UNPROTECTED PRIVATE KEY FILE! a This private key will be ignored.. Pomůže chmod 600 ~/.ssh/id_ed25519.
• Špatná polovina. -i ~/.ssh/id_ed25519.pub míří na veřejný klíč. Novější klienti si poradí a hledají odpovídající soukromý soubor, starší selžou s Load key: invalid format. Nasměruj -i na soubor bez .pub.

Uživatelé PuTTY mají ještě jednu past: soubor .ppk není klíč OpenSSH. Nabídka Conversions v PuTTYgen exportuje soukromý klíč OpenSSH a veřejný klíč pro authorized_keys je jediný řádek zobrazený v jeho okně, ne víceřádkový blok ---- BEGIN SSH2 PUBLIC KEY ----. Ten blok je ve formátu RFC 4716 a sshd ho ignoruje; ssh-keygen -i -f key.pub ho převede na jednořádkový klíč, pokud nemáš nic jiného.

Špatný uživatel, špatný účet, špatný soubor#

Klíč se instaluje pro uživatele, do jeho domovského adresáře. Požádej o jiného uživatele a dostaneš jiný authorized_keys, nebo žádný.

Z té tabulky plynou obvyklé chyby:

• Cloudové image vytvářejí výchozího uživatele (ubuntu, debian, admin, ec2-user a další, podle distribuce) a klíč dávají tam, často se zakázaným přihlášením roota nebo s authorized_keys roota nastaveným tak, aby vypsal „přihlas se jako ubuntu“ a odpojil.
• Klíč skončil v tvém vlastním účtu, ne v servisním účtu. ssh-copy-id instaluje do účtu, pod kterým ses připojil. Přidat klíč pro deploy, když jsi přihlášený jako alex, znamená zapsat do /home/deploy/.ssh/authorized_keys a pak opravit vlastnictví, o čemž je další část.
• `AuthorizedKeysFile` byl změněn. Výchozí hodnota je .ssh/authorized_keys .ssh/authorized_keys2, relativně k domovskému adresáři. Některá zabezpečená nastavení ho přesouvají do /etc/ssh/authorized_keys/%u. Zjisti, co používá běžící démon, místo toho, co předpokládáš:

$ sudo sshd -T | grep -Ei 'authorizedkeysfile|pubkeyauthentication|allowusers|allowgroups'

sshd -T vypíše efektivní konfiguraci po zpracování všech Include a výchozích hodnot, a jen ta verze se počítá. Na Debianu a Ubuntu může soubor v /etc/ssh/sshd_config.d/ tiše přebít hlavní soubor, protože sshd si u klíčového slova ponechá první hodnotu, kterou přečte. Chceš-li zjistit, co dělá blok Match pro jedno konkrétní přihlášení, přidej údaje o spojení: sshd -T -C user=deploy,host=laptop,addr=198.51.100.7.

Nakonec zkontroluj samotný řádek s klíčem. Jeden veřejný klíč je přesně jeden řádek: typ, blob v base64, volitelný komentář. Vložení přes terminál nebo editor, který zalamuje dlouhé řádky, ho rozdělí na dva a sshd rozbitý řádek tiše přeskočí. wc -l na souboru s jedním klíčem má říct 1 a ssh-keygen -lf na něm má vypsat jeden otisk, ne chybu.

Oprávnění a vlastnictví souborů#

Tohle je klasická příčina na straně serveru a klient ji vůbec nevidí. Při StrictModes yes (výchozí) sshd odmítne použít soubor authorized_keys, pokud by ho, jeho adresář nebo domovský adresář nad ním mohl měnit někdo jiný než uživatel nebo root. Soubor, který může kdokoli upravit, je soubor, do kterého může kdokoli přidat vlastní klíč, takže ho démon považuje za kompromitovaný.

Pravidlo zní: žádné právo zápisu pro skupinu ani pro všechny nikde na té cestě. Domovské adresáře zapisovatelné pro skupinu jsou záludné: chmod -R 775 na domovský adresář kvůli sdílení složky projektu rozbije přihlášení klíčem pro daného uživatele a nic na straně klienta na to nenaznačuje.

Druhou polovinou je vlastnictví. Zápis souboru jako root, přes sudo nano nebo sudo cp, ho nechá ve vlastnictví roota. Obnov to najednou:

$ 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

Když je tohle příčina, log serveru to řekne jasně - Authentication refused: bad ownership or modes for directory /home/deploy nebo totéž pro .ssh či soubor. Vypnutí StrictModes chybu odstraní a skutečnou slabinu tam nechá; oprav raději oprávnění. Pokud sis lámal hlavu s oprávněními na jiných typech serverů, oprávnění a vlastnictví souborů vysvětluje osmičkový zápis podrobněji.

Typy klíčů a změna ssh-rsa SHA-1#

Od OpenSSH 8.8 (2021) je podpisový algoritmus ssh-rsa, který podepisuje pomocí SHA-1, ve výchozím stavu vypnutý u klienta i serveru. Je to nejzmatečnější příčina této chyby, protože typ klíče a podpisový algoritmus sdílejí jméno. Klíč RSA stále funguje naprosto dobře; podepisuje se místo toho pomocí rsa-sha2-256 nebo rsa-sha2-512. Potíže začnou jen tehdy, když je jedna strana příliš stará a variantu SHA-2 nezná.

Existují dva směry a vypadají odlišně.

Nový klient mluví se starým serverem. Typickými cíli jsou staré appliance, NAS, routery a distribuce, jejichž OpenSSH je starší než 7.2. S -v uvidíš, že klíč byl zvažován a pak přeskočen:

debug1: Offering public key: /home/alex/.ssh/id_rsa RSA SHA256:Qk2... explicitdebug1: send_pubkey_test: no mutual signature algorithm

no mutual signature algorithm je to, podle čeho to poznáš. Nejčistší oprava je klíč ed25519, pokud je server dost nový, aby ho přijal (OpenSSH 6.5 nebo novější). Pokud není, povol SHA-1 znovu jen pro tento jeden host, nikdy globálně:

Host old-nas    HostName 192.168.1.20    HostKeyAlgorithms +ssh-rsa    PubkeyAcceptedAlgorithms +ssh-rsa

Na klientech starších než OpenSSH 8.5 se druhé klíčové slovo píše PubkeyAcceptedKeyTypes; současné verze berou obě. HostKeyAlgorithms je potřeba jen tehdy, když je vlastní klíč hostitele serveru RSA a jen SHA-1, což u tak starého zařízení obvykle je.

Starý klient mluví s novým serverem. Tady výstup klienta ukáže jen nabídku a odmítnutí a důvod nese log serveru: řádek říkající, že podpisový algoritmus, nebo u některých verzí typ klíče, ssh-rsa je not in PubkeyAcceptedAlgorithms. Znění se mezi verzemi liší, klíčové slovo v něm ne. Oprava patří na klienta: aktualizuj ho nebo ho přepni na klíč ed25519. Obvyklými podezřelými jsou staré nástroje pro Windows, staré knihovny SSH v Javě používané nasazovacím a záložním softwarem a vestavěné klienty. Přidání +ssh-rsa na server znovu zapíná SHA-1 pro všechny a mělo by to být krátkodobé řešení, ne odpověď.

Stojí za to vědět i tohle: klíče DSA (ssh-dss) jsou ve výchozím stavu vypnuté od OpenSSH 7.0 a v pozdějších vydáních byla podpora zcela odstraněna. Klíč id_dsa nebude proti současnému serveru fungovat při žádném nastavení a jediná oprava je nový klíč. Totéž platí pro klíče RSA kratší než 1024 bitů, které současný OpenSSH odmítá úplně.

Když překáží agent#

Agent pomáhá, dokud nepřestane. Stojí za to poznat tři selhání.

Agent má špatné klíče, nebo žádné. ssh-add -l vypíše, co drží. The agent has no identities. znamená, že běží a je prázdný; Could not open a connection to your authentication agent. znamená, že SSH_AUTH_SOCK není v tomto shellu nastaven, takže se klient k agentovi vůbec nedostane. Obvyklými příčinami jsou nové terminálové relace, tmux spuštěný před agentem a su na jiného uživatele.

$ ssh-add -l$ eval "$(ssh-agent -s)"$ ssh-add ~/.ssh/id_ed25519

Server klíč přijme a agent nechce podepsat. Projeví se to jako Server accepts key: následované sign_and_send_pubkey: signing failed ... agent refused operation. Běžné důvody jsou hardwarový klíč, který čeká na dotek, který nikdo neudělal, agent klíčenky na desktopu, který chce potvrzení v dialogu, jenž se nikdy neobjevil, nebo klíč přidaný s omezenou dobou platnosti (ssh-add -t), která vypršela. Odebrání a opětovné přidání klíče (ssh-add -d, pak ssh-add) vyřeší většinu případů; na linuxových desktopech opraví překvapivě velký zbytek kontrola, že soukromý klíč má 600.

Příliš mnoho klíčů. Popsáno výše a stojí za zopakování, protože je to tak časté: agent se šesti klíči vyčerpá MaxAuthTries dřív, než se dostane ke správnému. Trvalým řešením je IdentitiesOnly yes s výslovným IdentityFile pro každý host.

Ve Windows používá vestavěný klient OpenSSH službu ssh-agent, která je ve výchozím stavu vypnutá. Než ssh-add vůbec zafunguje, musí se jí v Services (nebo příkazem Set-Service ssh-agent -StartupType Automatic) změnit typ spouštění na automatický. Git for Windows má vlastní, oddělený OpenSSH, takže klíč přidaný do jednoho agenta druhý nevidí; pokud git selhává a ssh funguje, je tahle nesrovnalost první věc ke kontrole.

SELinux, AllowUsers a další strážci#

Některá odmítnutí se stanou ještě před porovnáním klíče a některá i tehdy, když všechny soubory vypadají správně.

SELinux na Fedoře, RHEL, Rocky, Alma a CentOS Stream označuje soubory štítky a sshd smí číst authorized_keys jen se štítkem ssh_home_t. Adresář .ssh vytvořený přes mv odjinud, obnovený z archivu nebo zkopírovaný na místo si ponechá starý štítek a oprávnění vypadají dokonale, zatímco démon nemá přístup.

$ ls -Z ~/.ssh/authorized_keysunconfined_u:object_r:user_home_t:s0 /home/deploy/.ssh/authorized_keys$ restorecon -Rv ~/.ssh$ sudo ausearch -m avc -ts recent

user_home_t tam, kde má být ssh_home_t, je ten problém; restorecon obnoví štítky na výchozí hodnoty politiky. Pokud domovský adresář leží na neobvyklém místě, třeba /data/home, politika pro něj nemá pravidlo a musíš SELinuxu nejdřív říct, že je ekvivalentní s /home, příkazem semanage fcontext -a -e /home /data/home, a pak spustit restorecon. ausearch čte /var/log/audit/audit.log a ukáže samotné odmítnutí, což vlastní log sshd neukáže.

`AllowUsers`, `AllowGroups`, `DenyUsers`, `DenyGroups`. Pokud některá z těchto direktiv existuje, uživatel, který neodpovídá, je odmítnut bez ohledu na klíč. Log říká User deploy from 198.51.100.7 not allowed because not listed in AllowUsers a klient vidí stejné Permission denied (publickey) jako při chybějícím klíči. Přidat nový účet a zapomenout na tento řádek je velmi častý způsob, jak ztratit hodinu.

`PermitRootLogin` nastavené na no odmítne roota i s platným klíčem. prohibit-password (výchozí od OpenSSH 7.0) povolí roota jen s klíčem.

Stav shellu a účtu. Uživatel s shellem /usr/sbin/nologin se ověří a pak je vyhozen, což vypadá jinak (This account is currently not available). S UsePAM no může být účet se zamčeným heslem v /etc/shadow odmítnut i při přihlášení klíčem; většina linuxových distribucí běží s UsePAM yes, kde se to netýká.

Windows OpenSSH Server má vlastní pravidlo, na které narazí každý jednou. U uživatele ve skupině Administrators sshd ignoruje jeho vlastní .ssh\authorized_keys a čte místo toho C:\ProgramData\ssh\administrators_authorized_keys a tento soubor smí být zapisovatelný jen pro Administrators a SYSTEM:

icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"

Čtení logů serveru#

Když výstup klienta věc nerozhodne, rozhodne ji log serveru. Kde leží, záleží na distribuci:

Sleduj ho živě, zatímco se z jiného terminálu zkoušíš připojit; přiřadit časové razítko k pokusu je mnohem snazší než hledat zpětně.

$ sudo journalctl -u ssh -f$ sudo tail -f /var/log/auth.log

Řádky, které odpovídají na otázku:

Connection closed by authenticating user deploy ... [preauth] bez čehokoli před tím je ta frustrující varianta: účet existuje, soubor byl čitelný a žádný z nabídnutých klíčů v něm nebyl. To tě posílá zpět k otiskům. Nastavení LogLevel VERBOSE v sshd_config způsobí, že démon loguje otisk každého klíče, který zvažuje, a tím se z hádání stane porovnání. Logy, které stojí za to uchovat pokrývá uchovávání těchto logů, až bude akutní problém vyřešený.

Když ani to nestačí, spusť druhého démona v ladicím režimu na volném portu. Obslouží jedno spojení, vypíše každé rozhodnutí do tvého terminálu a skončí, takže skutečnou službu nenaruší:

$ sudo /usr/sbin/sshd -d -p 2222$ ssh -v -p 2222 deploy@203.0.113.10        # from your machine

Port 2222 musí být po tu dobu otevřený ve firewallu - průvodce ufw má pravidlo na jeden řádek - a poté ho zase zavři. Ladicí výstup pojmenuje přesný soubor, který se snažil otevřít, oprávnění, které mu vadilo, i klíč, který porovnával, a tím skončí téměř každá zbylá záhada.

Poznámka o šumu: auth log veřejného serveru je plný řádků Invalid user od skenerů, které zkoušejí admin, test a oracle. To je pozadí, ne tvůj problém, i když je to dobrý důvod mít fail2ban před vším, co ještě přijímá hesla.

Git hosty a SFTP: stejná chyba jinde#

Nejčastější místo, kde se lidé s touto chybou setkají, není vůbec server, ale git push. git@github.com: Permission denied (publickey). je stejný mechanismus se dvěma zvláštnostmi: uživatel je vždy git, nikdy jméno tvého účtu, a klíč se musí přidat do tvého účtu na Git hostu, ne do souboru na serveru. Otestuj to bez Gitu v cestě:

$ ssh -T git@github.com

Funkční klíč odpoví pozdravem s tvým uživatelským jménem a poznámkou, že shellový přístup není poskytován. Selhávající ukáže stejné odmítnutí a ssh -vT git@github.com ti dá seznam nabídnutých klíčů z dřívější části. Pokud adresa repozitáře začíná https://, klíče SSH se vůbec netýkají; to je problém s tokenem, ne tento.

Spravované herní, aplikační a webové servery obvykle nemají vlastního démona SSH, ke kterému by ses připojil. Přístup k souborům na RE:NODE běží přes SFTP s přihlašovacími údaji vydanými pro každý server v panelu, takže oprava odmítnutého přihlášení SFTP tam je host, port a uživatelské jméno uvedené na stránce daného serveru, ne soubor s klíčem - SFTP a správce souborů má podrobnosti o připojení. Každá část tohoto článku platí plně na VDS, kde je sshd tvůj ke konfiguraci.

Kontrolní seznam ve správném pořadí#

Když chceš jen pořadí kroků:

1. ssh -v user@host - potvrď uživatelské jméno a že je tvůj klíč v řádcích Offering public key.
2. Pokud se nenabízí, oprav klienta: IdentityFile, IdentitiesOnly yes, režim soukromého klíče 600, agent.
3. Pokud se nabízí a je odmítnut, porovnej otisky pomocí ssh-keygen -lf na obou stranách.
4. Zkontroluj vlastnictví a režimy domovského adresáře, .ssh a authorized_keys.
5. Zkontroluj v sshd -T hodnoty AuthorizedKeysFile, AllowUsers a PermitRootLogin.
6. Sleduj auth log při připojování; na systémech se SELinux zkontroluj ls -Z a ausearch.
7. Pokud klient říká no mutual signature algorithm nebo server zmiňuje PubkeyAcceptedAlgorithms, je to změna kolem SHA-1 - přejdi na ed25519.
8. Pořád to nejde: sshd -d -p 2222 a přečti každý řádek.

Jakmile to funguje, udělej opravu trvalou v ~/.ssh/config, abys za měsíc neladil totéž, a projdi zbytek nastavení podle první hodiny na novém VDS.

FAQ#

Proč ssh-copy-id funguje, ale klíč je přesto odmítnut?

ssh-copy-id nainstaluje klíč správně do účtu, pod kterým ses připojil, ale neopraví domovský adresář zapisovatelný pro skupinu ani štítek SELinux, který byl špatně už před jeho během. Zkontroluj v logu serveru bad ownership or modes a na systémech rodiny Fedora nebo RHEL spusť pro daného uživatele restorecon -Rv ~/.ssh.

Je bezpečné vypnout StrictModes, aby chyba zmizela?

Ne. StrictModes existuje proto, že zapisovatelný authorized_keys dovolí kterémukoli jinému lokálnímu uživateli přidat vlastní klíč a přihlásit se jako ty. Oprava oprávnění zabere čtyři příkazy a ochranu nechá na místě; její vypnutí skutečnou slabinu jen skryje.

Můj klíč fungoval roky a po aktualizaci přestal. Proč?

Téměř vždy za to může změna ssh-rsa se SHA-1 v OpenSSH 8.8 nebo odstranění klíčů DSA. Jedna strana byla aktualizována a obě se už neshodnou na podpisovém algoritmu. Vygeneruj klíč ed25519 a nainstaluj ho vedle starého; ssh-rsa povoluj znovu jen pro jednotlivé hosty u zařízení, které nejde aktualizovat.

Mohu zjistit, proč mě server odmítl, bez přístupu root?

Ze strany serveru ne - autentizační log je na většině systémů čitelný jen pro roota nebo skupinu adm. S ssh -v a porovnáním otisků se ale dostaneš většinu cesty a pak můžeš správci serveru poslat přesné časové razítko svého pokusu, aby rychle našel odpovídající řádek logu.

Znamená Permission denied (publickey), že mi někdo ukradl klíč nebo byl server hacknutý?

Skoro nikdy. Je to server, který dělá svou práci: odmítá klíč, který nezná. Znepokojit by tě měla zpráva o změněném klíči hostitele, ne tahle. Pokud se ale v authorized_keys objeví klíče, které jsi nepřidal, je to úplně jiná situace a co dělat, když je server hacknutý je další čtení.