Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Restore logging of SSH logins System 10.4
Tiger only hintWith the release of 10.4, Apple has changed logging for ssh. I used to keep an eye on break-in attempts to my home computer (see this hint), which has SSH login enabled so I can log in from work.

After I installed Tiger, I didn't see any more attacks, which was quite odd. After some digging, I found that Apple is changing the logfile system, and plans for further changes in the future (see man syslogd for a bit more detail). The upshot of all this is that to get a service to log correctly, an entry is needed in the file /etc/syslog.conf, which is documented in the syslog.conf help file (man syslog.conf). The short of it is that you need to look at the file /etc/sshd_config, and find the logging section. There you should see this:
# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
This shows you sshd's log settings, which you need for the next step. Edit the file /etc/syslog.conf with some text editor (and sudo) and change this line (the second line in the file):
*.notice;authpriv,remoteauth,ftp,install.none;kern.debug;mail.crit
  /var/log/system.log
You need to add ;auth.info immediately after mail.crit (before the Tab that preceeds the /var/log... bit). Save the file and either reboot (ugly) or restart the syslog daemon with this command: sudo kill -HUP `cat /var/run/syslog.pid` What you have done is added a directive to syslog.conf to inform syslogd that log requests from auth at level info and above should be logged in the system log file. Then you signaled syslogd to reload the configurations (those are back ticks (the key just under the esc key)). Presto, login attempts are now back in the system log.

[robg adds: I wrapped the long code line above for a narrower display. In the original file, the /var/log bit appears after a Tab at the end of the line. Do not add a line break if you edit this file! I tested this, and it worked -- as soon as I made the change and restarted the daemon, the login attempts started showing up again.]
    •    
  • Currently 4.00 / 5
  You rated: 4 / 5 (6 votes cast)
 
[25,152 views]  

Restore logging of SSH logins | 8 comments | Create New Account
Click here to return to the 'Restore logging of SSH logins' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Restore logging of SSH logins
Authored by: GlowingApple on Oct 14, '05 09:56:38AM
Great hint! I've been wondering why I couldn't see ssh attempts myself. I also recommend adding auth.* ... /var/log/auth.log towards the end of the file (in my case below the local0.* line) so that any of these log entries will not only be added to the main system log file, but also to an individual file reserved for auth log entries. This way all of my sshd log entries can be easily read together in /var/log/auth.log without the other entries crowding things up.

---
Jayson --When Microsoft asks you, "Where do you want to go today?" tell them "Apple."

[ Reply to This | # ]

Restore logging of SSH logins
Authored by: PanicRoom on Oct 16, '05 10:25:58AM

If this hint aims at logging 'attempted' SSH logins, then I must be doing something wrong: at my end, it's logging successful SSH logins but not failed attempts (I entered a wrong password a few times to check). The only thing that might be different with my setup is that I use a publickey (not an admin password) for SSH logins. But why would this suppress the logging of attempted logins?



[ Reply to This | # ]
Restore logging of SSH logins
Authored by: kd4ttc on Oct 16, '05 03:28:48PM

what happens if you try a bad user name, such as ssh -l nosuchuser xx.xx.xx.xx to your machine?



[ Reply to This | # ]
Restore logging of SSH logins
Authored by: PanicRoom on Oct 16, '05 11:03:09PM

Thanks for the tip - now it works! It only logs failed SSH attempts if the user name is incorrect. If the user name is right, it doesn't log anything. Obviously this is good for detecting brute force attacks where the attacker doesn't know the user name or password. Curiously, if I tried hacking into a known computer where you already know the user name (say at work) then none of the attempts would be logged. Even more interesting if you think that a good proportion of mac users will still have the default setup in place where their real full name acts as their user name and first name as short name. In the long run, it really comes down to having a good passphrase.



[ Reply to This | # ]
logging of SSH login failures
Authored by: ccase on Oct 16, '05 11:43:13PM

Both failed user names and failed passwords are logged. To see that, you have to be using password authentication.

What you are doing is using a public key with a passphrase. That is failing on the client side, not the server side, so there is nothing to log.

To see this, rename the directory with the public key (mv .ssh .ssh.save). Then try logging in. You'll be asked for a password. If you type in non-sense a few times, then login will fail, and a log entry will be generated.



[ Reply to This | # ]
Restore logging of SSH logins
Authored by: TigerKR on Oct 19, '05 11:45:17PM

Great hint. After using this hint, and noticing a lot of activity, I decided to change my outside ssh port using this tip:

http://www.macosxhints.com/article.php?story=20050707140439980



[ Reply to This | # ]
this might not be necessary
Authored by: Glamdring on Feb 16, '07 08:22:31PM

It looks like the location of ssh log in attempts was just moved from /var/log/system.log to /var/log/secure.log.



[ Reply to This | # ]
How do you change the level of logging of SSH logins
Authored by: rsnyder on May 29, '08 10:45:31AM

Since /etc/sshd_config is not consulted when launchd gets a request for ssh on the selected port (port 22 by default) how do you go about changing the logging level, say from INFO to VERBOSE?



[ Reply to This | # ]