The macosxhints Forums

The macosxhints Forums (http://hintsforums.macworld.com/index.php)
-   Networking (http://hintsforums.macworld.com/forumdisplay.php?f=14)
-   -   SSH server won't run? (http://hintsforums.macworld.com/showthread.php?t=98517)

hayne 02-05-2009 02:28 PM

When you turn on Remote Login in the Sharing Preferences, it reads the file "/System/Library/LaunchDaemons/ssh.plist" (as others have referred to above).

You can see this happening by running the following command in a Terminal window while you go to Sharing Preferences and turn on Remote Login:
sudo filebyproc.d | grep -i launchd

Maybe your copy of that file is corrupted somehow (even though the 'grep's above look fine) - what do you get from 'md5' applied to that file?
Code:

% md5 /System/Library/LaunchDaemons/ssh.plist
MD5 (/System/Library/LaunchDaemons/ssh.plist) = 32efeb6f3fb420f60e6ab3ef0ebfb06d


msp3k 02-05-2009 04:26 PM

Quote:

Originally Posted by tlarkin (Post 517550)
Well, by default it does that, and then actives the sshd once it becomes active. So, either your image is a botched OS install, or you did something in the image to configure the ssh or launchd items and it is not working.

what happens if you use launchctl and manually launch the ssh daemon? Does it work then?

# launchctl unload -w /System/Library/LaunchDaemons/ssh.plist
# launchctl load -w /System/Library/LaunchDaemons/ssh.plist
getaddrinfo(): nodename nor servname provided, or not known

I'm in the process of rebuilding my imaging machine now.

msp3k 02-05-2009 04:33 PM

Quote:

Originally Posted by msp3k (Post 517569)
I'm in the process of rebuilding my imaging machine now.

Oh, and I've discovered something nasty.

I restored the factory default image to the image master's hard drive.

I booted the image master and then set up it's LDAP configuration, binding it to the LDAP master.

Immediately after this, all of the clients installed using the old image lost their LDAP binding. They all, each and every one, reported that the LDAP server was not responding.

I have no idea why this happened.

tlarkin 02-05-2009 04:46 PM

Quote:

Originally Posted by msp3k (Post 517571)
Oh, and I've discovered something nasty.

I restored the factory default image to the image master's hard drive.

I booted the image master and then set up it's LDAP configuration, binding it to the LDAP master.

Immediately after this, all of the clients installed using the old image lost their LDAP binding. They all, each and every one, reported that the LDAP server was not responding.

I have no idea why this happened.

I have never seen or heard this and the only thing I can think that would cause this is that if your Open Directory Master server (or whatever server you are bound to) has had DNS or IP changes to it.

msp3k 02-05-2009 11:52 PM

Quote:

Originally Posted by hayne (Post 517557)
When you turn on Remote Login in the Sharing Preferences, it reads the file "/System/Library/LaunchDaemons/ssh.plist" (as others have referred to above).

You can see this happening by running the following command in a Terminal window while you go to Sharing Preferences and turn on Remote Login:
sudo filebyproc.d | grep -i launchd

Maybe your copy of that file is corrupted somehow (even though the 'grep's above look fine) - what do you get from 'md5' applied to that file?
Code:

% md5 /System/Library/LaunchDaemons/ssh.plist
MD5 (/System/Library/LaunchDaemons/ssh.plist) = 32efeb6f3fb420f60e6ab3ef0ebfb06d


MD5 (/System/Library/LaunchDaemons/ssh.plist) = be1e3b8480daa175f18cf391e17b823f

Mine differs from yours?

Here's the complete contents of my file:
Code:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Label</key>
        <string>com.openssh.sshd</string>
        <key>Program</key>
        <string>/usr/libexec/sshd-keygen-wrapper</string>
        <key>ProgramArguments</key>
        <array>
                <string>/usr/sbin/sshd</string>
                <string>-i</string>
        </array>
        <key>SHAuthorizationRight</key>
        <string>system.preferences</string>
        <key>SessionCreate</key>
        <true/>
        <key>Sockets</key>
        <dict>
                <key>Listeners</key>
                <dict>
                        <key>Bonjour</key>
                        <array>
                                <string>ssh</string>
                                <string>sftp-ssh</string>
                        </array>
                        <key>SockServiceName</key>
                        <string>ssh</string>
                </dict>
        </dict>
        <key>StandardErrorPath</key>
        <string>/dev/null</string>
        <key>inetdCompatibility</key>
        <dict>
                <key>Wait</key>
                <false/>
        </dict>
</dict>
</plist>


msp3k 02-06-2009 12:29 AM

Quote:

Originally Posted by tlarkin (Post 517572)
I have never seen or heard this and the only thing I can think that would cause this is that if your Open Directory Master server (or whatever server you are bound to) has had DNS or IP changes to it.

I'm discovering lots of things about my apple computers that don't seem to work 100%.

I was thinking that maybe the problem was that my image master was already bound when I made the image. And although I had the workflow set to bind the client on install, I thought that perhaps there was something left behind from the binding of the image master when it did so, such that all clients made from that image were incorrectly using some value with the LDAP server that should have instead been unique to each host. (Apple does seem to put a lot of strange things that I don't understand in their LDAP database.) And that perhaps when I bound the freshly re-made image master with the same name, it overwrote something in the LDAP server that caused the other clients to suddenly be out of whack.

But that was just a guess.

My new approach will be to leave the image master un-bound when I make a new image, and then bind it via a post-install script after it's been installed on the client.

tlarkin 02-06-2009 01:10 AM

Quote:

Originally Posted by msp3k (Post 517622)
I'm discovering lots of things about my apple computers that don't seem to work 100%.

I was thinking that maybe the problem was that my image master was already bound when I made the image. And although I had the workflow set to bind the client on install, I thought that perhaps there was something left behind from the binding of the image master when it did so, such that all clients made from that image were incorrectly using some value with the LDAP server that should have instead been unique to each host. (Apple does seem to put a lot of strange things that I don't understand in their LDAP database.) And that perhaps when I bound the freshly re-made image master with the same name, it overwrote something in the LDAP server that caused the other clients to suddenly be out of whack.

But that was just a guess.

My new approach will be to leave the image master un-bound when I make a new image, and then bind it via a post-install script after it's been installed on the client.

I have scripts to change binding on a client on my site, linked below.

hayne 02-06-2009 03:00 AM

Quote:

Originally Posted by msp3k (Post 517618)
MD5 (/System/Library/LaunchDaemons/ssh.plist) = be1e3b8480daa175f18cf391e17b823f

Mine differs from yours?

Here's the complete contents of my file:
Code:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Label</key>
        <string>com.openssh.sshd</string>
[...]


The ssh.plist on my Mac (with 10.5.6) has the following extra lines just after the "<dict>":
Code:

        <key>Disabled</key>
        <true/>



All times are GMT -5. The time now is 07:59 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
Site design © IDG Consumer & SMB; individuals retain copyright of their postings
but consent to the possible use of their material in other areas of IDG Consumer & SMB.