ssh

OpenSSH SSH client (remote login program)

     ssh [-1246AaCfgkMNnqsTtVvXxY]   [user@]hostname [command]
            [-e escape_char] [-l login_name] 
            [-p port] [-F configfile] 
            [-i identity_file]      
            [-O ctl_cmd] 
            [-o option] 
            [-b bind_address] [-D [bind_address:]port] 
            [-L [bind_address:]port:host:hostport] [-R [bind_address:]port:host:hostport] 
            [-S ctl_path]
            [-w local_tun[:remote_tun]] [-c cipher_spec] [-m mac_spec] 
 
As with all the documentation on this site, this is rearrange and tersefied(in this case perhaps bludgened is a better phrase. ssh has many variants and many options from antiquity(well pre broadband connection anyway) many of which no longer make sense. If you are setting up login on a server (like if anybody even does that anymore) or need to understand the various security issues, look elsewhere!

Logon to a remote host for executing commands with secure encrypted communications between two untrusted hosts over an insecure network.

Before you connect to a host for the first time, retrieve the SSH host FingerPrint using:

 dig -t SSHFP +short host.example.com 
If dig does not report the fingerprint it may just be that the administrator didn't bother to set it up.

When connecting to a server for the first time, the fingerprint is displayed.

The authenticity of host 'dapie (192.168.1.2)' can't be established.  (Well yes, since this is my first time!)
RSA key fingerprint is db:b0:c6:0e:63:73:af:87:6b:d9:dd:10:35:99:eb:6e.
or
ECDSA key fingerprint is 61:5f:65:2e:6c:a3:dc:09:57:cd:77:fd:bc:24:95:84

Are you sure you want to continue connecting (yes/no)? 

After YOU verify the fingerprint, continuing will add it to ~/.ssh/known_hosts for subsequent connections.

If the fingerprint does not match
-or-

If dig did not report the fingerprint, continue and check the files (use: ls -la).
If they are not what you expect (don't poke around!)

  1. terminate the connection ( via ~. )
  2. Contact the host's administrator and explain that you had a connection spoofed. Have your password changed
  3. edit ~/.ssh/known_hosts and delete the entry for this host (check the end of the file).

After your identity has been validated command is executed or a shell prompt is displayed.

-l login_name to use on the remote host

-F configfile default:/.ssh/config.

If given on the command line, the system-wide configuration file (/etc/ssh_config) will be ignored.

-v Verbose mode. display debugging messages.
Helpful in debugging connection, authentication, and configuration problems. Multiple -v options increase the verbosity. maximum is 3 For example: -v -v -v
 -v
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to Real-World-Systems.com [174.127.119.33] port 22.
debug1: Connection established.

debug1: identity file /Users/dgerman/.ssh/id_rsa type -1 
debug1: identity file /Users/dgerman/.ssh/id_rsa-cert type -1
debug1: identity file /Users/dgerman/.ssh/id_dsa type -1
debug1: identity file /Users/dgerman/.ssh/id_dsa-cert type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host 'real-world-systems.com' is known and matches the RSA host key.
debug1: Found key in /Users/dgerman/.ssh/known_hosts:5 
debug1: ssh_rsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server

debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/dgerman/.ssh/id_rsa
debug1: Trying private key: /Users/dgerman/.ssh/id_dsa
debug1: Next authentication method: password
ssh -vvv and another and the diff
Success to GoDaddy success

-A authentication agent connection forwarding. Should be avoided.
-aauthentication agent connection forwarding is Disabled
-b bind_address on local machine as the source addres
-c cipher_spec Protocol version 1 : 3des or blowfish

Protocol version 2: comma-separated list of ciphers in order of preference :
default : aes128‑cbc,3des‑cbc,blowfish‑cbc,cast128‑cbc,arcfour128,
arcfour256,arcfour,aes192‑cbc,aes256‑cbc,aes128‑ctr,aes192‑ctr,aes256‑ctr

-1 protocol version 1 only
-2 version 2 only
-m mac_spec for protocol version 2 a comma-separated list of MAC (message authentication code) algorithms can be specified in order of preference. See the MACs keyword for more information.
-D [bind_address:]port Specifies a local dynamic application-level port forwarding. Allocates a socket to listen to port on the local side, optionally bound to the specified bind_address.
Connections to this port are forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine.
The SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server.
Dynamic port forwardings can also be specified in the configuration file.

IPv6 addresses : [bind_address/]port or by enclosing the address in square brackets.
Only the root can forward privileged ports.
By default, the local port is bound in accordance with the GatewayPorts setting.
An explicit bind_address may be used to bind the connection to a specific address.
The bind_address of localhost indicates that the listening port be bound for local use only, an empty address or * indicates that the port should be available from all interfaces.

-4 use IPv4 addresses only.
-6 use IPv6 addresses only.
-g Allows remote hosts to connect to local forwarded ports.

-f go to background just before command execution.
Useful if ssh is going to ask for passwords or passphrases, but the user wants it in the background.
implies -n. The recommended way to start X11 programs at a remote site is with something like ssh -f host xterm.

-I smartcard_device used for storing the user's private RSA key. Only if support is compiled in (default is no support).
-i identity_file contains the identity (private key) for RSA or DSA authentication is read.
default /.ssh/identity for protocol version 1,
and /.ssh/id_rsa and ~/.ssh/id_dsa for protocol version 2.
May be specified on a perhost basis in the configuration file.
Multiple -i options (and multiple identities specified in configuration files) is permitted.
-k Disables forwarding (delegation) of GSSAPI credentials to the server.
-L [bind_address:]port:host:hostport Port on the local (client) host is to be forwarded to the given host and port on the remote side.
Allocates a socket to listen to port on the local side, optionally bound to the specified bind_address. Whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the remote machine.
Port forwardings can also be specified in the configuration file.
IPv6 addresses are specified with : [bind_address/]port/host/hostport or by enclosing the address in square brackets.
Only the superuser can forward privileged ports.
By default, the local port is bound in accordance with the GatewayPorts setting. However, an explicit bind_address may be used to bind the connection to a specific address. The bind_address of localhost indicates that the listening port be bound for local use only, while an empty address or * indicates that the port should be available from all interfaces.
-M master mode for connection sharing.
Multiple -M options places ssh into master mode with confirmation required before slave connections are accepted. Refer to ControlMaster in ssh_config(5)
-N Do not execute a remote command. for just forwarding ports (protocol version 2 only).
-n Redirects stdin from /dev/null (i.e., prevents reading from stdin). Must be used when ssh is run in the background.
Use this to run X11 programs on a remote machine. For example, ssh -n shadows.cs.hut.fi emacs & will start an emacs on shadows.cs.hut.fi, and the X11 connection will be automatically forwarded over an encrypted channel. The ssh program will be put in the background. Does not work if password is needed; see -f
-O ctl_cmd Control an active connection multiplexing master process.
ctl_cmd is interpreted and passed to the master process.
  • check check that the master process is running
  • exit request the master to exit
-o option in the format used in the configuration file. useful for specifying options for which there is no command-line flag, see ssh_config(5).
AddressFamily
BatchMode
BindAddress
CheckHostIP
Cipher
Ciphers
ClearAllForwardings
Compression
CompressionLevel
ConnectionAttempts
ConnectTimeout
ControlMaster
ControlPath
DynamicForward
EscapeChar
ExitOnForwardFailure
ForwardAgent
ForwardX11
ForwardX11Trusted
GSSAPIDelegateCredentials 
GatewayPorts
GlobalKnownHostsFile
HashKnownHosts
Host

PreferredAuthentications
PubkeyAuthentication
ChallengeResponseAuthentication 
GSSAPIAuthentication
HostbasedAuthentication
RhostsRSAAuthentication
PasswordAuthentication
NumberOfPasswordPrompts

HostKeyAlgorithms
HostKeyAlias
HostName
IdentityFile
IdentitiesOnly
KbdInteractiveDevices
LocalCommand
LocalForward
LogLevel
MACs
NoHostAuthenticationForLocalhos;
PermitLocalCommand
Port
Protocol
ProxyCommand
RekeyLimit
RemoteForward
RSAAuthentication
SendEnv
ServerAliveInterval
ServerAliveCountMax
SmartcardDevice
StrictHostKeyChecking
TCPKeepAlive
Tunnel
TunnelDevice
UsePrivilegedPort
User
UserKnownHostsFile
VerifyHostKeyDNS
XAuthLocation
-p port
-q Quiet (IMHO not a good idea). Warnings and diagnostics are suppressed.
-R [bind_address:]port:host:hostport port on the remote host is to be forwarded to the given host and port on the local side.
Allocates a socket on the remote side, and whenever a connection is made to this port, it is forwarded over the secure channel, and a made to hostport from the local machine.

Privileged ports can be forwarded only when logging in as root on the remote machine

By default, the socket on the server will be bound to the loopback interface. This may be overriden by specifying a bind_address.
An empty bind_address, or * specifies the remote socket should listen on all interfaces.
remote bind_address will only succeed if the server's GatewayPorts option is enabled (see sshd_config.

-S ctl_path control socket for connection sharing. Refer to ControlPath and ControlMaster in ssh_config(5)
-s invocates subsystem on the remote system, a feature of the SSH2 protocol which facilitate the use of SSH as a secure transport for other applications (eg. sftp(1)). The subsystem is specified as the remote command.
-T Disable pseudo-tty allocation.
-t Force pseudo-tty allocation, allows execution of screen-based programs on a remote host, which can be , e.g. when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty.
-V Display the version number and exit.
-w local_tun[:remote_tun ] Requests tunnel device forwarding with the specified tun(4) devices between the client (local_tun) and the server (remote_tun). The devices may be specified by numerical ID or any. If remote_tun is not specified, it defaults to any. See the Tunnel and TunnelDevice directives in ssh_config
Default tunnel mode is point-to-point.
-X Enables X11 forwarding.
Use caution, users with the ability to bypass file permissions on the remote host can access the local X11 display through the forwarded connection and may be able to perform activities such as keystroke monitoring.
-x Disables X11 forwarding.
-Y Enables trusted X11 forwarding which are not subjected to the X11 SECURITY extension controls.

ssh obtains configuration data from per-user and system-wide configuration files as described in ssh_conf.

ssh exits with the exit status of the remote command or with 255 if an error occurred.

Authentication

~/.ssh/known_hosts contains identification for hosts. /etc/ssh_known_hosts is checked for known hosts.
New hosts are added .
If a host's identification differs from the previous one, ssh reports:

@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the DSA key sent by the remote host is
SHA256:MhtvZsNm5yqnKqKv8/trTiJiK4FmqdQrsKUSk5klXfk.
Please contact your system administrator.
Add correct host key in /Users/dauser/.ssh/known_hosts to get rid of this message.
Offending DSA key in /Users/dauser/.ssh/known_hosts:9
DSA host key for theDomain.com has changed and you have requested strict checking.
Host key verification failed.  

and disables password authentication.

StrictHostKeyChecking controls logins to machines whose host key is not known or has changed.

TCP FORWARDING

Forwarding of arbitrary TCP connections over the secure channel can be specified either on the command line or in a configuration file. One application is a secure connection to a mail server; another is going through firewalls.

In the example below for encrypting communication between an IRC client and server, where the IRC server does not directly support encrypted communications. The user connects to the remote host using ssh, specifying a port to be used to forward connections to the remote server. Then starts the service which is to be encrypted on the client machine, connecting to the same local port, and ssh will encrypt and forward the connection.

The following example tunnels an IRC session from client machine 127.0.0.1 (localhost) to remote server server.example.com

 $ ssh -f -L 1234:localhost:6667 server.example.com sleep 10
 $ irc -c '#users' -p 1234 pinky 127.0.0.1

This tunnels a connection to IRC server server.example.com, joining channel #users, nickname pinky, using port 1234. It doesn't matter which port is used, as long as it's greater than 1023 ( only root can open sockets on privileged ports) and doesn't conflict with any ports already in use.
The connection is forwarded to port 6667 on the remote server, the standard port for IRC services.

-f backgrounds ssh and the remote command sleep 10 is specified to allow an amount of time (10 seconds, in the example) to start the service which is to be tunnelled. If no connections are made within the time specified, ssh will exit.

X11 FORWARDING

If the ForwardX11 variable is set to yes (or see the description of the -X, -x, and -Y options above) and the user is using X11 (the DISPLAY environment variable is set), the connection to the X11 display is automatically forwarded to the remote side in such a way that any X11 programs started from the shell (or command) will go through the encrypted channel, and the connection to the real X server will be made from the local machine. The user should not manually set DISPLAY. Forwarding of X11 connections can be configured on the command line or in configuration files.

The DISPLAY value set by ssh will point to the server machine, but with a display number greater than zero. This is normal, and happens because ssh creates a proxy X server on the server machine for forwarding the connections over the encrypted channel.

ssh will also automatically set up Xauthority data on the server machine. For this purpose, it will generate a random authorization cookie, store it in Xauthority on the server, and verify that any forwarded connections carry this cookie and replace it by the real cookie when the connection is opened. The real authentication cookie is never sent to the server machine (and no cookies are sent in the plain).

If the ForwardAgent variable is set to yes (or see the description of the -A and -a options above) and the user is using an authentication agent, the connection to the agent is automatically forwarded to the remote side.

Verifying Host KEYS

Fingerprints are generated using from the hosts private key file: ssh-keygen:
      $ ssh-keygen -l -f /etc/ssh_host_rsa_key
    2048 7c:df:03:a8:49:1d:38:19:f7:f9:d7:13:3d:40:4d:f0   (RSA)

If the fingerprint is known, it is matched and the key is accepted.
SSH FingerPrints may be availale through the DNS (Domain Name System).
A resource record (RR), SSHFP, is added to a zonefile and the connecting client is able to match the fingerprint with that of the key presented.

 ssh-keygen -r real-world-systems.com

real-world-systems.com IN SSHFP 1 1 a018c6c85022337171b9e00b1249cb754e48b58a
real-world-systems.com IN SSHFP 2 1 d5d9919c49691fb8566a179aff988f1b18e9491bA

From ssh 5/25/13 Real-World-Systems.com RSA key fingerprint is 3a:c4:63:5a:0b:51:4b:98:2f:e1:8a:79:e4:7a:99:d7.

The displayed lines must be added to the zonefile.
To retrieve the fingerprint :

 dig -t SSHFP host.example.com +short

the client connects:

   ssh -o "VerifyHostKeyDNS ask" host.example.com
           [...]
           Matching host key fingerprint found in DNS.
           Are you sure you want to continue connecting (yes/no)?

See VerifyHostKeyDNS in ssh_config(5)

SSH-BASED VIRTUAL PRIVATE NETWORKS

ssh contains support for Virtual Private Network (VPN) tunnelling using the tun(4) network pseudo-device, allowing two networks to be joined securely.
The sshd_config(5) configuration option PermitTunnel controls whether the server supports this, and at what level (layer 2 or 3 traffic).

The following example would connect client network 10.0.50.0/24 with remote network 10.0.99.0/24 using a point-to-point connection from 10.1.1.1 to 10.1.1.2, provided that the SSH server running on the gateway to the remote network, at 192.168.1.15, allows it.

On the client:
 # ssh -f -w 0:1 192.168.1.15 true
 # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
 # route add 10.0.99.0/24 10.1.1.2 
On the server:
 # ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
 # route add 10.0.50.0/24 10.1.1.1 
Client access may be more finely tuned via /root/.ssh/authorized_keys (see below) and the PermitRootLogin server option.

The following entry would permit connections on tun(4) device 1 from user jane and on tun device 2 from user john, if PermitRootLogin is set to forced-commands-only:

       tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
       tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john
                 
Since an SSH-based setup entails a fair amount of overhead, it may be more suited to temporary setups, such as for wireless VPNs. More permanent VPNs are better provided by tools such as ipsecctl(8) and isakmpd(8).

Escape Character pairs

Valid escape pairs are only recognized at the beginning of a line. Typing ~/scriptname is not handled specially.
Default escape leadin is ~ .
~? list escape pairs.
~~ transmit ~
~C Open command line.
!command executes a command on the local host

allows addition of
-L|R[bind_address:]port:host:hostport Request local|remote forward
-D[bind_address:]port Request dynamic forward
-KR[bind_address:]port Cancel remote forward

~B Send BREAK
~# List forwarded connections.
~R Request rekeying of the connection
~. Disconnect.
~^Z Background ssh.
~& Background ssh at logout when waiting for forwarded connection / X11 sessions to terminate.

ssh_config.

The escape character can be changed in configuration files with the EscapeChar or on the command line with -e . (default: ~).
Setting the character to none disables escapes and makes the session fully transparent. X11 connections and arbitrary TCP ports can be forwarded over the secure channel.
All communication is encrypted.

Environment Variables

$DISPLAYindicates the location of the X11 server.
points to a value of the form hostname:n
$MAIL path of the user's mailbox. example:/var/spool/mail/realr
$SSH_ASKPASS ask the $passphrase from the current terminal
If no terminal is associated and $DISPLAY and SSH_ASKPASS are set, it will execute the program specified by $SSH_ASKPASS and open an X11 window to read the passphrase. when calling ssh from a .xsession or related script.
$SSH_AUTH_SOCK -domain socket used to communicate with the agent.
$SSH_CONNECTION client IP address, port, server IP address, and port .
Example: SSH_CONNECTION='74.105.211.198 49516 174.127.119.33 22'
$SSH_ORIGINAL_COMMAND contains the original command line if a forced command is executed. It can be used to extract the original arguments.
$SSH_TTY name of the tty (path to the device) associated with the current shell or command. example:/dev/pts/3
$TZ the present time zone if it was set when the daemon was started
$USER
LOGNAME
$
ssh reads ~/.ssh/environment, and adds lines of the format VARNAME=value to the environment if users are allowed to change their environment. See PermitUserEnvironment in sshd_config(5). StrictHostKeyChecking has been disabled).

Files

See sshd for more information.
Some of these files are expected to have restricted access or they will be ignored.

~/.rhosts for host‑based authentication. owned by the user, must be 700
~/.ssh/authorized_keys public keys (RSA/DSA) . sshd
~/.ssh/config configuration file. ssh_config
~/.ssh/environment additional definitions >
~/.ssh/identity
~/.ssh/id_dsa
~/.ssh/id_rsa private key for authentication. must be 700 ~/.ssh/identity.pub
~/.ssh/id_dsa.pub
~/.ssh/id_rsa.pub public key
~/.ssh/known_hosts list of host keys for all hosts the user has logged into not in systemwide known hosts.
~/.ssh/rc Commands executed when the user logs in, before the user's shell (or command) is started.

/etc/hosts.equiv for host‑based authentication (see above). It should only be writable by root.
/etc/shosts.equivlike hosts.equiv, but allows host‑based authentication without permitting login with rlogin/rsh.

etc/ssh_config Systemwide configuration /etc/ssh_config.system_default differes only in the 2 (also commented out) lines:GSSAPI Authentiation and KeyExchange

/etc/ssh_host_key
/etc/ssh_host_dsa_key
/etc/ssh_host_rsa_key private parts of the host keys and are used for host‑based authentication.
/etc/ssh_known_hosts Systemwide known host keys.
/etc/sshrc Commands executed at logs in, before the shell (or command) is started.

See also

screen (multiple terminal sessions over a single (possibly dial-up) line,
sshd scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-keyscan(1), tun(4), hosts.equiv(5), ssh_config(5), ssh-keysign(8), sshd(8)

Errors

  1. ssh_exchange_identification: Connection closed by remote host
    Tried several times, waited, added -v tried again and it worked.

    to GoDaddy 7/29/14

     > /usr/bin/ssh -vl m4685586 autoinsurancecoverageverify.com
    OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
    debug1: Reading configuration data /etc/ssh_config
    debug1: /etc/ssh_config line 20: Applying options for *
    debug1: /etc/ssh_config line 102: Applying options for *
    debug1: Connecting to autoinsurancecoverageverify.com [50.63.41.190] port 22.
    debug1: Connection established.
    debug1: identity file /Users/dgerman/.ssh/id_rsa type 1
    debug1: identity file /Users/dgerman/.ssh/id_rsa-cert type -1
    debug1: identity file /Users/dgerman/.ssh/id_dsa type -1
    debug1: identity file /Users/dgerman/.ssh/id_dsa-cert type -1
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_6.2
    ssh_exchange_identification: Connection closed by remote host
     > echo $?
    255
    
    
    
  2. 5/01/17 sshgd aicv is now/usr/bin/dig +short +nocl autoinsurancecoverageverify.com +short 50.63.41.190 +noshort to show ttl +nssearch for NameServers GoDaddy is 50.63.41.190 --failed, see sshgd.sshvvv.log debug2: ciphers stoc: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: MACs ctos: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: MACs stoc: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: compression ctos: none,zlib@openssh.com debug2: compression stoc: none,zlib@openssh.com debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 debug1: kex: host key algorithm: (no match) Unable to negotiate with 50.63.41.190 port 22: no matching host key type found. Their offer: ssh-dss
  3. success

  4. You don't exist. Go Away!
    Although I was unable to locate the cause of this error, rebooting the laptop resulted in it no longer occuring.ed
    Additionally, ssh xxx produces the same message clarifying any network issues.
    and : su user2 then ssh host works fine!.

    From

    ssh-keygen.c
     /* we need this for the home * directory.  */
        pw = getpwuid(getuid());
        if (!pw) { printf("You don't exist, go away!\n"); exit(1);
    and
    ssh.c
     pw = getpwuid(original_real_uid);
        if (!pw) { logit("You don't exist, go away!"); exit(255);

    echo $? to see who it was.

    getpwuid should return:

    char    *pw_name   User's login name. 
    uid_t    pw_uid    Numerical user ID. 
    gid_t    pw_gid    Numerical group ID. 
    char    *pw_dir    Initial working directory. 
    char    *pw_shell  Program to use as shell. 

    Intesteringly
    /var/log/warn contains:

    coreservicesd[38]: _scserver_ServerCheckin: client uid validation failure; getpwuid(503) == NULL
    /var/log/notice for May 5 08:01:26 2012contains:
    applepushserviced[90]: <APSCourier: 0x102e27bb0>: Stream error occurred for <APSTCPStream: 0x7fe46351c1e0>: The operation          couldn?~@~Yt be completed. Socket is not connecte>
    applepushserviced[90]: <APSCourier: 0x102e27bb0>: Stream error occurred for <APSTCPStream: 0x7fe46351c1e0>: The operation          couldn?~@~Yt be completed. (kCFErrorDomainCFNetwork error 2.>
    com.apple.var-db-shadow-backup[92780]: Error adding file shadow

Definitive: OpenSSH for OpenBSD

sshd