186

I have Ubuntu 9.10 installed with sshd and I can successfully connect to it using login and password. I have configured an RSA key login and now have "Server refused our key" as expected. Ok, now I want to check sshd log in order to figure out a problem. I have examined /etc/ssh/sshd_config and it have

SyslogFacility AUTH
LogLevel INFO

Ok. I'm looking at /var/log/auth.log and... it's empty O_O. Changing Loglevel to VERBOSE helps nothing - auth.log is still empty. Any hints how I can check sshd log?

peterh
  • 4,914
  • 13
  • 29
  • 44
grigoryvp
  • 3,415
  • 11
  • 38
  • 58
  • 8
    Did you check your syslog configuration? I don't run Ubuntu, but it may redirect the AUTH facility to a different logfile. Maybe /var/log/messages ? – Prof. Moriarty Apr 08 '10 at 10:23
  • How to check a syslog configuration? Unfortunately, i'm not very good a linux :(. `cat /var/log/messages | grep ssh` shows nothing :(. – grigoryvp Apr 08 '10 at 10:28
  • You are correct. `/etc/syslog.conf` redirects AUTH to `/var/logauth.log`. Please write your answer so i can accept it :) – grigoryvp Apr 08 '10 at 10:31
  • On my machine: The system logs are set in /etc/rsyslog.conf, which in turn includes /etc/rsyslog.d/* The actual file setting the location of the logs is /etc/rsyslog.d/50-default.conf. – Richard Holloway Apr 08 '10 at 11:53
  • 5
    On my servers, sshd logs to /var/log/secure. This is configured in /etc/rsyslog.conf, on the line beginning "authpriv.*" – Isaac Betesh Jun 20 '13 at 14:34
  • 1
    authpriv?? How the heck were we supposed to know that had anything to do with sshd? :-) – Spencer Williams May 31 '15 at 12:54
  • (6 years later ...) I guess /etc/ssh/sshd_config shows "SyslogFacility AUTHPRIV" but yeah that's a bit of a stretch! – lost Feb 25 '21 at 09:33

8 Answers8

225

Creating an answer based on the comments above, credit to @Prof. Moriarty and @Eye of Hell

SSH auth failures are logged here /var/log/auth.log

The following should give you only ssh related log lines:

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

To be on the safe side, get the last few hundred lines and then search (because if the log file is too large, grep on the whole file would consume more system resources, not to mention will take longer to run)

View sshd entries in the last 500 lines of the log:

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

or to follow the log output as you test:

tail -f -n 500 /var/log/auth.log | grep 'sshd'
galoget
  • 223
  • 1
  • 9
Ram
  • 2,351
  • 2
  • 11
  • 4
  • Thanks for the edit. That was an error on my part, should've been tail in the first place (not less). Like I say in the text - "get the last few hundred lines and then search" – Ram Sep 13 '13 at 18:32
  • 13
    This answer. Other answer with green arrow is bogus. Change arrow. –  Aug 04 '14 at 23:58
  • 8
    Why not use `tail -f ...` to monitor it in real time? Would this be an issue with larger log files? – ingh.am Feb 02 '15 at 12:12
  • 10
    `less +F ...` will 'tail' in real time, and it's much more powerful than tail – northben May 07 '15 at 15:45
  • If your log is spammed with `Connection closed by 127.0.0.1 [preauth]`, remember that your nagios may be doing just his job every 5 minutes... – mbx Jul 23 '15 at 20:08
  • 5
    And `lnav` is even better than less/tail – Wayne Werner Jan 13 '16 at 18:17
  • 19
    P.s.: if your server is a Red Hat (as CentOS), the path of sshd/login records log is /var/log/secure (check /var/log folder for the log files of specific dates too). See this answer: https://serverfault.com/questions/465833/where-is-the-sshd-log-file-on-red-hat-linux-stored – Brian Hellekin Jan 05 '18 at 16:25
  • 4
    The question must have been edited, because it specifically says auth.log is empty, so this answer wouldn't apply. I came here trying to find the alternative location for auth.log. Thanks @BrianHellekin. – Noumenon Jan 06 '18 at 17:35
  • less +F is nice, but doesn't let me add a few carriage returns to create some visual space after previous output. Also, no such directory as /var/log/secure on my Suse system, no such file "auth.log", and sshd_config is totally commented out. Suse must do things differently from RH and Ubuntu flavors. – Blisterpeanuts Feb 16 '20 at 18:22
41

If you can try the failing connection again easily, one way easy way is to start an SSH server on a free port such as 2222:

/usr/sbin/sshd -d -p 2222

and then retry the connection with:

ssh -p 2222 user@host

By using the different port -p 2222, we don't have to stop the main SSH server, which could lock us out.

See also: https://unix.stackexchange.com/a/55481/32558

Ciro Santilli OurBigBook.com
  • 3,518
  • 1
  • 28
  • 19
  • 5
    One of the best options, specially if you only have SSH access to a server. Debugging the connection by stopping the ssh server will drop you out of session. Just start a new ssh daemon on a different port and test the login using that port. – Attila Antal Oct 15 '19 at 19:38
  • 2
    @AttilaAntal Small correction: stopping sshd will not kill active ssh sessions. This method is a good precaution in case something goes wrong, but in theory you can easily stop and then restart sshd over ssh. – Parker Kemp Feb 09 '20 at 03:35
  • 1
    @ParkerKemp it doesn't kill the connection, and if everything is working as expected, you should be able to continue using it after after restarting the daemon. The problem, however, will be if for some reason the Daemon couldn't start. Then the active session will drop. – Attila Antal Feb 10 '20 at 15:35
34

The modern way to view logs:

  1. All messages about sshd:
    journalctl -t sshd
    or
    journalctl -u ssh where -u == unit

  2. Messages about sshd from the last boot:
    journalctl -t sshd -b0

  3. Messages about sshd from the last boot in the reverse order:
    journalctl -t sshd -b0 -r

RedEyed
  • 440
  • 4
  • 7
11

If no one else is using the system at the moment you could do what i've done in such cases:

  • stop sshd service (at least i've been able to do this while logged in via ssh)
  • start sshd manually and add some -d options to get more verbose debug output. Unless you have something funky going on it should use the same keys and config it does when started properly
Peto
  • 402
  • 3
  • 4
  • 187
    Stopping SSHD on a remote server is a really bad idea. This may solve the problem for some (or most) setups most of the time, but if ANYTHING goes wrong - your connection, power on either end, forgetfulness, etc - you're locked out of the box. Which is bad news. – Sudowned Nov 21 '12 at 18:58
  • 1
    Well, it should be noted that the only way you could start the service after manually stopping it would be to have some other kind of access to it, like another non-SSH remote connection, or you're sitting in front of it. – Spencer Williams Apr 23 '15 at 16:32
  • 48
    How does this answer the question? I landed here from a web search expecting to learn how to check the SSHD log files, not what worked for you for some problem... Damn I wish readers on the Stack Exchange network would actually read and answer the question at hand, and not the question they want it to be.... –  Aug 23 '15 at 16:00
  • 6
    You can start another sshd on another port. Connect to that one. Then stop the main sshd and start a new one on port 22. If anything fails, reboot the box using your DRAC or cloud management. You should have sshd starting on boot right? No worries. – Bruno Bronosky Feb 17 '17 at 14:43
  • @BrunoBronosky the second backup one can be configured as an onion service. – brownian Apr 18 '17 at 13:26
  • or just start a new instance on different port – Nikolay Dimitrov Aug 16 '17 at 08:06
  • Nowadays many VPS providers provide SSH console right within their control panel. So It's less likely you are locked out of the box. – Don Dilanga Oct 07 '17 at 12:59
  • I logged in just to downvote this answer. It's appalling and reflects poorly on ServerFault that this is considered a valid confirmed answer. – Joel E Salas Dec 21 '17 at 19:18
  • 3
    @JoelESalas The community doesn't decide which answers are accepted. – kasperd Feb 04 '18 at 13:10
  • Stop using this solution!. Except you want to ruin your lifes. Use the answers below instead. – Brain90 Aug 31 '18 at 02:19
  • 1
    This is such a dangerously bad solution. – Joshua Robinson Mar 18 '19 at 15:21
  • SSHD is not even possible to run interactive – Arrow_Raider May 12 '20 at 16:45
  • @Sudowned Will connection not be closed when `sshd` stops? You seem to imply this by your comment. – x-yuri Sep 25 '21 at 23:59
7

If you want to see all log messages about sshd, run this:

grep -rsh sshd /var/log |sort
Cory Knutson
  • 1,866
  • 12
  • 20
guest
  • 99
  • 1
  • 1
  • 2
    Logs will start with entries like `Mar 14 19:52:04` which exclude the year and are not easily sorted (though you may get lucky with `sort --month-sort` assuming you don't go over a boundary between years). The log files themselves are already sorted, so you just have to scan them in the right order. Also, the recursive `grep -r` call will be really slow on systems with large logs. There's no reason to additionally scan things like your HTTPD logs. – Adam Katz Aug 14 '17 at 17:27
  • thx, i didn't know what flavor i was on, but this helped me find `/var/log/secure` (i actually ended up changing the command to `grep -Rsl sshd /var/log` but +1 for getting my thinking cap to appear). – WEBjuju Dec 04 '19 at 00:01
  • 1
    tail -5000f /var/log/messages|grep -i sshd – Blisterpeanuts Feb 16 '20 at 18:26
4

You can use the following command to see the logs from SSH:

tail -f /var/log/auth.log
galoget
  • 223
  • 1
  • 9
Aditya Mittal
  • 157
  • 2
  • 1
    Welcome to ServerFault. Did you read the question? He isn't getting data in that file. `tail`ing it useless if it doesn't have any data in it. – chicks Nov 10 '17 at 01:56
  • @chicks That's funny. Answer with most votes is almost the same like this.. – Qback Feb 09 '18 at 07:27
0

Not for topicstarter, but for another opensuse tumbleweed users:

systemctl status sshd.service
journalctl -xeu sshd.service

The first gives you the status and time of fault:

 sshd.service - OpenSSH Daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Wed 2022-06-15 19:15:20 MSK; 10min ago

The second may give you more details, something like:

Jun 15 19:15:19 localhost.localdomain sshd[2124]: 
/etc/ssh/sshd_config.d/sshd.conf line 121: Directive 'usepam' is not allowed within a Match block
Mêlis Farothserkê
  • 1
-2

In CentOS 7. I have found out SSH logs over here:

$ tail /var/log/audit/audit.log
tri.akki7
  • 1
  • 1
  • 1
    In default installation, `/var/log/audit/audit.log` stores *SELinux* logs in CentOS, not `sshd`. Source: https://wiki.centos.org/HowTos/SELinux#Troubleshooting_SELinux – mforsetti Jul 09 '21 at 07:51