The Matrix Data Bank

You finally checked your console log, and you don\’t know what to make about these entries?  Never fear… I\’ll help explain it…  Then you can be afraid of the big bad internet…
The following is a sample of the console log of someone attempting to connect to \”Power-mac-g5\” via SSH, without having the proper username and/or password.
Jul 18 19:35:09 power-mac-g5 com.apple.SecurityServer[23]: getpwnam() failed for user kenneth, creating invalid credential
Jul 18 19:35:08 power-mac-g5 com.apple.SecurityServer[23]: getpwnam() failed for user tom, creating invalid credential
Jul 18 19:34:48power-mac-g5 sshd[30475]: Failed password for invalid user matt from 190.202.80.3 port 58310 ssh2
Jul 18 03:27:11 power-mac-g5 sshd[28184]: Invalid user test from 218.22.9.118
The first two lines (SecurityServer) shows the attempted login as \”kenneth\”, and as \”tom\”.  Both logins failed (\”Invalid credential\”), and the following SSH lines in the log give the IP information of the two attempts…
On the other hand, a successful login would look like:
Jul 21 11:23:38 power-mac-g5 sshd[385]: Accepted keyboard-interactive/pam for The_Big_One from 192.168.1.125 port 1210 ssh2
There are only a few solutions for this:

1. Since script kiddies are going to be attempting to login via SSH, if you have it enabled, make sure you have a \”hard\” password and username.  Try to choose an username that is not a dictionary word, or a easy to guess name (eg. Tom, Dick, Harry, George, etc).  If you must use a common name, try to do a letter substitution (eg. t0m, with a ZERO instead of a O).
2. Just don\’t have it enabled, if you don\’t need it.  The username / password can\’t be compromised if it\’s not running / available.
3. Block SSH access to specific IP\’s or IP ranges.
4. SSH Keys.  Restrict the SSH to only accept connections that use your SSH Private Key…  (I have to research this one).  (Or only via a VPN connection)

To automate the process of scanning the log file, you can just simply view the  /var/log/secure.log for the details…Another option is to download and use \”Check Failed Password Attempts for Mac\”, which gives you a nice GUI view of the Secure log…

Check Failed Password Attempts is a small application that parses the /var/log/secure.log file looking for failed authorization attempts. It presents a summary of the total number of failed attempts (and successes) per user. It will also optionally display the full log listing of each failed attempt, each successful attempt, and SSH information from the /var/log/system.log (see the preferences to enable/disable these options).
http://www.macupdate.com/info.php/id/17555

Here is one method to setup trusted key pairs, from a Macintosh discussion…

\”The best thing you can do is disable \”Remote Login\” and all other network access via Mac OS X\’s \”Sharing\” preferences and firewall. It\’s also imperative that you use strong passwords that cannot be broken via sophisticated \”dictionary\” attacks.\”

The best thing to do if you need to use ssh for remote access is to turn OFF ssh password authentication and log in using public/private keypairs. Crackers can try dictionary attacks til the end of time but they won\’t get in, because dictionary attacks work against a username/password pair, just people who have both sides of the key and can authenticate against it. Turning off all services/firewalling is great….til you need to actually use the computer remotely.

This behavior can be changed in /private/etc/sshd_conf by changing:

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no < defaults to yes
PermitEmptyPasswords no < should be no no matter what (I also turn off \”allow root login\” too)

The next step is to generate a public/private keypair from the command line using \”ssh-keygen -t dsa -f id_dsa\” and give a good pass PHRASE to the key. This creates two keys, a private and a public key. The public key would go in the .ssh folder of the logging in users home directory, and the private key would be plugged into the connecting program (in the .ssh folder if it\’s a *nix system, or plugged into a Windows program like VanDyke\’s SecureCRT).

The log for a successful login looks like:

Mar 27 22:57:03 tux sshd[13827]: Connection from ::ffff:192.168.1.130 port 55831
Mar 27 22:57:03 tux sshd[13827]: Found matching DSA key: 98:07:02:87:af:6a:ae:9c:cc:0f:7f:9b:a4:f4:85:66
Mar 27 22:57:05 tux sshd[13827]: Found matching DSA key: 98:07:02:87:af:6a:ae:9c:cc:0f:7f:9b:a4:f4:85:66
Mar 27 22:57:05 tux sshd[13827]: Accepted publickey for rzeman from ::ffff:192.168.1.130 port 55831 ssh2

And a failed session gives:

GreyGhost:~/temp rzeman$ ssh tux
Enter passphrase for key \’/Users/rzeman/.ssh/id_dsa\’:
Enter passphrase for key \’/Users/rzeman/.ssh/id_dsa\’:
Enter passphrase for key \’/Users/rzeman/.ssh/id_dsa\’:
Permission denied (publickey,keyboard-interactive).
From http://www.macintouch.com/security-mon.html