Before you can use sshd on Mac OS X, you'll need to enable the server and possibly open up the Mac's firewall. In addition, you'll want to know about some configuration differences as compared to most other OpenSSH installations.
SSH server startup is controlled from the Sharing pane in System Preferences, under Services, as in Figure 15-1. To enable sshd, select Remote Login and click the Start button.
By default, the Mac OS X personal firewall will block SSH connections from the outside world. If you have this firewall enabled, you must manually permit SSH traffic through it. This is done from the Sharing pane in System Preferences, under Firewall, as in Figure 15-2.
In most Unix-like operating systems, the OpenSSH server runs as a daemon, listening for SSH connections. On Mac OS X, however, sshd is controlled by the super-server daemon, xinetd. [5.3.3.2] Whenever an SSH client attempts to contact sshd on TCP port 22, xinetd notices the attempt and invokes a single instance of sshd (specifically, sshd -i) to serve that connection.
The xinetd configuration file for sshd is /etc/xinetd.d/ssh:
# /etc/xinetd.d/ssh:
service ssh
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/libexec/sshd-keygen-wrapper
server_args = -i
groups = yes
flags = REUSE IPv6
session_create = yes
}Note the use of the wrapper script sshd-keygen-wrapper: it will generate new host keys if they are missing, as after a fresh OS install.
On Mac OS X, the serverwide configuration files are found in the /etc directory instead of the more common /etc/ssh: for example, the serverwide configuration file is /etc/sshd_config rather than /etc/ssh/sshd_config.
The SSH software is a modified version of OpenSSH maintained by Apple; they backport security fixes to it whenever required.
The OS X OpenSSH build has protocol 2 Kerberos support for both
user and server authentication, following the major Internet-Drafts on
these (draft-ietf-secsh-gsskex
and draft-ietf-galb-secsh-gssapi). It implements user
authentication via the gssapi and
external-keyx methods; it does not
yet have the improved gssapi-with-mic method. In case a
Kerberos-secured key exchange has been used for server authentication,
the external-keyx method allows the
userauth protocol to refer back to
the previous Kerberos exchange for user authentication, skipping an
unnecessary extra authentication phase.
This Kerberos support is also fully DNS-enabled, meaning it will find Kerberos authentication servers from information in the DNS if it is available. In a network of compatible and correctly configured Kerberos and OpenSSH servers, no extra configuration is needed for a plain OS X host newly attached to the network to use Kerberos for secure, single-signon client SSH connections. All that is required is to run:
$ kinit user@REALMPlease enter the password for user@REALM:********$ sshuser@host
Place the following lines into /etc/krb5.conf to relieve the user from having to specify the realm—and if the Kerberos principal and OS X account usernames are the same, then a simple kinit will suffice:
[libdefaults]
default_realm =REALMInstead of the command-line utility kinit, you can use the OS X GUI Kerberos utility: /System/Library/CoreServices/Kerberos.app.