Come controllare il registro sshd?

126

Ho Ubuntu 9.10 installato sshde posso collegarmi con successo usando login e password. Ho configurato un RSAaccesso con chiave e ora ho "Server rifiutato la nostra chiave" come previsto. Ok, ora voglio controllare il sshdregistro per capire un problema. Ho esaminato /etc/ssh/sshd_confige lo ha fatto

SyslogFacility AUTH
LogLevel INFO

Ok. Sto guardando /var/log/auth.loge ... è vuoto O_O. Cambiare Loglevelin VERBOSEnon aiuta a nulla - auth.logè ancora vuoto. Qualche suggerimento su come posso controllare il sshdregistro?

ssh

— grigoryvp
fonte

7

Hai controllato la tua configurazione syslog? Non eseguo Ubuntu, ma potrebbe reindirizzare la funzione AUTH su un file di registro diverso. Forse / var / log / messaggi?

— Prof. Moriarty,

Come controllare una configurazione syslog? Sfortunatamente, non sono molto bravo su Linux :(. Non cat /var/log/messages | grep sshmostra nulla :(.

— grigoryvp

Hai ragione. /etc/syslog.confreindirizza AUTH a /var/logauth.log. Scrivi la tua risposta in modo che io possa accettarla :)

— grigoryvp

3

Sui miei server, sshd registra in / var / log / secure. Questo è configurato in /etc/rsyslog.conf, sulla riga che inizia "authpriv. *"

— Isaac Betesh

1

authpriv ?? Come diamine avremmo dovuto sapere che aveva qualcosa a che fare con sshd? :-)

— Spencer Williams

7

Se nessun altro sta usando il sistema al momento, potresti fare quello che ho fatto in questi casi:

interrompere il servizio sshd (almeno sono stato in grado di farlo mentre ho effettuato l'accesso tramite ssh)
avvia sshd manualmente e aggiungi alcune opzioni -d per ottenere un output di debug più dettagliato. A meno che tu non abbia qualcosa di strano, dovrebbe usare gli stessi tasti e configurarlo quando avviato correttamente

— Peto
fonte

143

Arrestare SSHD su un server remoto è una pessima idea. Questo può risolvere il problema per alcune (o la maggior parte) configurazioni per la maggior parte del tempo, ma se NESSUNO va storto - connessione, alimentazione alle estremità, dimenticanza, ecc. - sei bloccato fuori dalla scatola. Che è una brutta notizia.

— Sud

1

Bene, va notato che l'unico modo in cui è possibile avviare il servizio dopo averlo interrotto manualmente sarebbe quello di avere un altro tipo di accesso ad esso, come un'altra connessione remota non SSH, oppure ci si trova di fronte.

— Spencer Williams,

26

Come risponde alla domanda? Sono arrivato qui da una ricerca web in attesa di imparare a controllare i file di registro SSHD, non quello che ha funzionato per te per qualche problema ... Accidenti vorrei che i lettori sulla rete di Exchange Exchange leggessero e rispondessero alla domanda, e non la domanda che vogliono che sia ...

4

È possibile avviare un altro SSHD su un'altra porta. Connettiti a quello. Quindi interrompi lo sshd principale e avviane uno nuovo sulla porta 22. Se qualcosa non riesce, riavvia la scatola usando il tuo DRAC o la gestione del cloud. Dovresti avere sshd a partire all'avvio giusto? Nessun problema.

— Bruno Bronosky,

1

@JoelESalas La community non decide quali risposte sono accettate.

— Kasperd,

155

Creazione di una risposta basata sui commenti sopra, merito a @Prof. Moriarty e @Eye of Hell

Gli errori di autenticazione SSH vengono registrati qui /var/log/auth.log

Quanto segue dovrebbe darti solo linee di log relative a ssh

grep 'sshd' /var/log/auth.log

Per essere al sicuro, prendi le ultime centinaia di righe e poi cerca (perché se il file di registro è troppo grande, grep sull'intero file consumerebbe più risorse di sistema, per non parlare richiederà più tempo per l'esecuzione)

tail -500 /var/log/auth.log | grep 'sshd'

— ariete
fonte

8

Questa risposta Un'altra risposta con la freccia verde è falsa. Cambia freccia.

— meshfields

5

Perché non utilizzarlo tail -f ...per monitorarlo in tempo reale? Questo sarebbe un problema con file di registro più grandi?

— ingh.am,

6

less +F ...'coda' in tempo reale, ed è molto più potente della coda

— northben

5

Ed lnavè persino meglio di less / tail

— Wayne Werner il

7

Ps: se il tuo server è un Red Hat (come CentOS), il percorso del registro sshd / login records è / var / log / secure (controlla anche la cartella / var / log per i file di registro di date specifiche). Vedi questa risposta: serverfault.com/questions/465833/…

— Brian Hellekin il

15

Se riesci a provare di nuovo facilmente la connessione non riuscita, un modo semplice è quello di avviare un server SSH su una porta libera come 2222:

/usr/sbin/sshd -d -p 2222

e quindi riprovare la connessione con:

ssh -p 2222 user@host

Utilizzando la diversa porta -p 2222, non è necessario arrestare il server SSH principale, il che potrebbe bloccarci.

Vedi anche: https://unix.stackexchange.com/a/55481/32558

— Ciro Santilli 新疆改造中心法轮功六四事件
fonte

1

Una delle migliori opzioni, specialmente se si dispone solo dell'accesso SSH a un server. Il debug della connessione arrestando il server SSH ti farà uscire dalla sessione. Basta avviare un nuovo demone ssh su una porta diversa e testare l'accesso usando quella porta.

— Attila Antal,

1

Se vuoi vedere tutti i messaggi di log su sshd, esegui questo:

grep -rsh sshd /var/log |sort

— ospite
fonte

2

I registri inizieranno con voci come quelle Mar 14 19:52:04che escludono l'anno e non sono facilmente ordinabili (anche se potresti essere fortunato ad sort --month-sortassumere che non superi un limite tra gli anni). I file di registro stessi sono già ordinati, quindi devi solo scansionarli nell'ordine giusto. Inoltre, la grep -rchiamata ricorsiva sarà molto lenta su sistemi con registri di grandi dimensioni. Non c'è motivo di scansionare ulteriormente cose come i tuoi log HTTPD.

— Adam Katz,

1

Puoi tail -f /var/log/auth.log

— Aditya Mittal
fonte

1

Benvenuti in ServerFault. Hai letto la domanda? Non sta ottenendo dati in quel file. tailinutile se non contiene dati.

— pulcini,

@chicks È divertente. La risposta con la maggior parte dei voti è quasi la stessa di questa ...

— Qback