Serverul a refuzat semnătura cu cheie publică, deși a acceptat cheia – putty (Unix, Ssh, Putty)

Joel a intrebat.

Am folosit puttygen pentru a genera atât fișierele mele de chei publice, cât și cele private (ssh2, 2048 bit). Am configurat corect setările în putty și acesta folosește fișierul de cheie privată corect. În ceea ce privește cheia publică, (folosesc aceste chei pentru root), aceasta se află în /root/.ssh/authorized_keys

Am încercat să folosesc chmod pe .ssh la 700 și pe authorized_keys to 400. Asta nu a făcut nimic.

Are cineva vreo recomandare?

editare: aici este un ls -ldZ de la .ssh folder și authorized_keys fișier

drwx------ root root ?                                /root/.ssh
-rw------- root root ?                                /root/.ssh/authorized_keys

Comentarii

  • dați mai multe informații. care este distribuția serverului la distanță, versiunea. există vreun strat de securitate între client și server? (SELinux, iptables,…). Capturați jurnalul de audit pe serverul dvs. la distanță atunci când încercați să vă conectați pentru a vedea orice indiciu. Activați debug-ul putty ar fi util. –  > Por cuongnv23.
  • Rulează CentOS 6.7 și, din câte știu eu, nu există niciun strat de securitate care să blocheze ceva. Unde aș putea căuta jurnalul de audit? Am încercat să verific jurnalul de autentificare, dar pare să nu existe. În ceea ce privește depanarea putty, doriți jurnalul de evenimente? L-am verificat și conținea destul de multe informații, dar până la verificarea cheii nu a fost de mare ajutor. –  > Por Joel.
  • Încercarea de a face ssh de pe o cutie Linux cu ssh -vvv ar putea fi de ajutor, deși poate conține unele informații private care trebuie filtrate. – user140866
  • ls -ldZ ~ ~/.ssh ~/.ssh/authorized_keys pe server. –  > Por Jakuje.
  • @Joel ar trebui să vă uitați la fișierul /var/log/audit/audit.log. De asemenea, actualizează-ți răspunsul cu ieșirea comenzii de la @Jakuje –  > Por cuongnv23.
4 răspunsuri
Maxiko

Setați LogLevel la DEBUG în sshd_config, și cred că vei găsi (în auth.log desigur) un motiv pentru care cheia ta publică este refuzată.

Comentarii

  • Nici măcar nu este nevoie să schimbați nivelul de jurnal. O autentificare refuzată este întotdeauna înregistrată cu un motiv și, de obicei, acel motiv este suficient pentru a vă da seama. –  > Por Gilles „SO- nu mai fi rău.
Joel

Privind jurnalul /var/log/secure a arătat că a fost pur și simplu refuzată. Sunt oarecum nou în centos, deoarece sunt în principal un tip debian, așa că nu știam de /var/log/secure

După ce am verificat acest lucru și am făcut câteva căutări, se pare că PermitRootLogin no trebuie să fie PermitRootLogin without-password dacă doriți să utilizați în mod specific doar chei pentru autentificarea root. Asta a făcut truc. Vă mulțumim tuturor pentru contribuția.

itoctopus

Am avut aceeași eroare („Server refused public-key signature despite accepting key”) în timp ce încercam să ne conectăm la ssh la un server folosind o cheie ca root. S-a dovedit că problema era cauzată de faptul că configurația SSH a serverului nu permitea utilizatorului root să utilizeze chei SSH.

TAOcode

Am avut această problemă aparent de nicăieri. Anterior adăugasem chei ssh și mă conectasem fără probleme. Chiar și butonul SSH pentru conectarea la VM disponibil prin intermediul site-ului Google Cloud Console nu reușea să înregistreze cheile.

Problema era că mediul Linux Guest Environment de la Google nu rula. Mi-am rezolvat problema urmând instrucțiunile pentru Instalare pe loc: Linux Guest Environment.

Tags:,