4 Replies Latest reply: Aug 21, 2009 2:15 PM by Mabel O'Farrell
Abel408 Level 1 Level 1 (0 points)
Hello everyone!

Lately We have been getting ssh errors such as this:

Invalid user tky from 222.73.216.8
fatal: initgroups: NOUSER: No such file or directory
/etc/sshd_config line 74: Unsupported option KerberosGetAFSToken
Invalid user tkz from 222.73.216.8
fatal: initgroups: NOUSER: No such file or directory
/etc/sshd_config line 74: Unsupported option KerberosGetAFSToken

But several 100s of them. We have OSX server 10.5 and from what I understand this has an adaptive firewall. Well it doesn't seem to be doing much. We also have a hosts.allow file with just the ip address that are allowed to connect. That doesn't seem to be stopping these attacks either.

What can I do to prevent these attacks?

xserve 10.5
  • 1. Re: How to deny suspicious hosts
    Camelot Level 8 Level 8 (45,790 points)
    I think your problem lies a little deeper. The issue isn't with hosts.allow or even the firewall.

    hosts.allow only has any real effect when you also have a hosts.deny file that blocks unwanted addresses. man 5 hosts_access goes into more detail.

    The specific problem you're encountering here is with the sshd_config option KerberosGetAFSToken. For whatever reason, this option is causing an sshd error and would likely occur regardless of whether a legitimate or illegitimate user was trying to log on.

    What's most concerning is that KerberosGetAFSToken is a standard configuration command that should work, and exists in the default configuration.

    You can stop this login attempt by adding the relevant IP address to /etc/hosts.deny but I'd look to spend some time working out why the sshd_config is now throwing errors.
  • 2. Re: How to deny suspicious hosts
    Mabel O'Farrell Level 3 Level 3 (975 points)
    You need to employ one of the below to block password based 'attacks' against an Internet-facing ssh server:

    DenyHosts: http://denyhosts.sourceforge.net/

    BlockHosts: http://www.aczoom.com/cms/blockhosts

    You should also setup your ssh server to use key-based logins not password-based logins.

    The IP address, 222.73.216.8, that you are seeing is from a netblock in China. Chinese-based ssh dictionary attacks have been a common problem for many years.

    Additionally, comment out this line, KerberosGetAFSToken in /etc/sshd_config as this is for the AFS filesystem that is not supported OOB on OS X.
  • 3. Re: How to deny suspicious hosts
    Abel408 Level 1 Level 1 (0 points)
    Thanks guys.

    Would this be something I could use?
    http://scothoser.blogspot.com/2009/05/kerberized-ssh-on-mac-os-x-v105-server.htm l

    And if I set up that, does that mean that only those computers which are authenticated to OD are allowed to access ssh? Does this mean I will not be able to ssh into the server form home?

    Thanks again

    Message was edited by: Abel408
  • 4. Re: How to deny suspicious hosts
    Mabel O'Farrell Level 3 Level 3 (975 points)
    Would this be something I could use?


    No. This will not stop dictionary attacks against your ssh server. What it could do is be used as a DOS against your directory server. Any Internet facing system that employs a directory backend could easily be used as way to deny service to your internal clients simply by way of overwhelming it with requests. Vulnerabilities in the Pluggable Authentication Module (PAM) could possibly lead to privilege escalation that might be used to take over the box, also.

    And if I set up that, does that mean that only those computers which are authenticated to OD are allowed to access ssh?


    Yes. Even employing the GSSAPI-with-MIC method of login would limit the ability to login to the server to OD bound clients only.

    Does this mean I will not be able to ssh into the server form home?


    Yes.

    Your best course of action is to employ key-based authentication -denying password authentication and 'root' user logins- by employing a method of blocking password-based attacks such as one of the software solutions posted earlier. Manually adding hosts to the /etc/hosts.deny file will soon become a daily task for you to protect your ssh server.