Skip to main content
Solved

Did Mavericks kill SSH?

  • November 7, 2013
  • 14 replies
  • 88 views
C
Forum|alt.badge.img+11

2012 MBP running 10. 9 Mavericks. Attempted enrollment with Recon 9.2
Error: A connection error occurred: SSH failed to start up session with host '127.0.0.1' (Remote host closed connection) Confirmed that SSH is on and the admin pw for the Management Account is correct. Tried to do a remote enrollment and received an error that port 22 is off.
I confirmed that the hosts file is correct with 127.0.0.1 localhost

Any ideas?

Thanks!
Corbin

Best answer by Chris

I ran into this today.
For me the issue was that /var/empty wasn't owned by root for whatever reason.
In /var/log/system.log it showed

sshd[1654]: fatal: /var/empty must be owned by root and not group or world-writable.
sudo chown -R root /var/empty/

fixed it.

    14 replies

    N
    Forum|alt.badge.img+18
    • nessts
    • Valued Contributor
    • November 7, 2013

    Firewall?

    S
    Forum|alt.badge.img+13
    • Sean_M_Harper
    • Contributor
    • November 7, 2013

    No issue on my side. I would agree it is likely network related (and firewall at that).

    C
    Forum|alt.badge.img+11
    • corbinmharris
    • Author
    • Valued Contributor
    • November 7, 2013

    Firewall is enabled but allows port 22/SSH on my Mac
    Having the same issue with my boss, Recon 9.2 is not able to connect to his MBA running 10.9, but he sent me confirmation the SSH is running. He does not have firewall on -

    dhcp-10-14-70-249:~ esantelices$ netstat -an | grep 22 | grep LISTEN
    tcp4 0 0 *.22 *.* LISTEN
    tcp6 0 0 *.22 *.* LISTEN

    C
    Forum|alt.badge.img+11
    • corbinmharris
    • Author
    • Valued Contributor
    • November 7, 2013

    I'm getting the same results in the terminal -
    Last login: Thu Nov 7 11:24:47 on console
    mbp153F1G3:~ charris$ netstat -an | grep 22 | grep LISTEN
    tcp6 0 0 *.22 *.* LISTEN tcp4 0 0 *.22 *.* LISTEN mbp153F1G3:~ charris$

    N
    Forum|alt.badge.img+18
    • nessts
    • Valued Contributor
    • November 7, 2013

    works for me and has since seed1

    K
    Forum|alt.badge.img+9
    • kstrick
    • Valued Contributor
    • November 8, 2013

    I have one machine with mavericks that is exhibiting this behavior

    C
    Forum|alt.badge.img+11
    • corbinmharris
    • Author
    • Valued Contributor
    • November 8, 2013

    Thanks everyone! I took the ultimate step and reinstalled Mavericks this morning. Recon 9.2 connected to JSS without a problem even with the firewall on.

    Corbin

    C
    Forum|alt.badge.img+13
    • Chris
    • Valued Contributor
    • Answer
    • November 15, 2013

    I ran into this today.
    For me the issue was that /var/empty wasn't owned by root for whatever reason.
    In /var/log/system.log it showed

    sshd[1654]: fatal: /var/empty must be owned by root and not group or world-writable.
    sudo chown -R root /var/empty/

    fixed it.

      jhbush
      Forum|alt.badge.img+27
      • jhbush
      • Esteemed Contributor
      • January 11, 2014

      Chris, thanks for the fix. I had a few test 10.9 VM's exhibit this behavior.

      L
      Forum|alt.badge.img+4
      • leegalan
      • New Contributor
      • July 17, 2014

      Thanks for the fix. This helped me out of some frustration. Any ideas as to what causes this? Thanks again.

      P
      Forum|alt.badge.img+3
      • psherman
      • New Contributor
      • October 18, 2015

      Thanks mate.

      N
      Forum|alt.badge.img+6
      • nigelg
      • Contributor
      • September 4, 2017

      I had this issue this morning on a Sierra machine. The /var/empty folder was owned by a domain user account. changing ownership to root fixed it straight away.

      H
      Forum|alt.badge.img+1
      • hector_cast
      • New Contributor
      • December 6, 2017

      This fix worked for me. I noticed this same issue on a macOS 10.13.1 (17B1003) after deleting my initial temporary administrator account using DEP enrollment.

      A
      Forum|alt.badge.img+2

      Saw the same error message on a 10.12.6 Mac this morning that turned out to be an erroneous subnet mask. Verified that the mask that worked was proper by our network team, and updated the documentation.

      Terms & ConditionsCookie settingsAccessibility statement