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] 
 
logon to a remote host and for executing commands, (replaces rlogin and rsh)
and provide secure encrypted communications between two untrusted hosts over an insecure network.
X11 connections and arbitrary TCP ports can be forwarded over the secure channel.
All communication is encrypted.

When connecting to a server for the first time, a fingerprint of the server's public key is presented to the user
if no record for the host exists in /etc/ssh_known_hosts (unless StrictHostKeyChecking has been disabled).

The authenticity of host 'dapie (192.168.1.2)' can't be established.
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)? 
To retrieve the SSH host FingerPrint from the Domain Name System use:
 dig -t SSHFP host.example.com +short

After verifying the fingerprint a response of yes causes the fingerprint is the added to ~/.ssh/known_hosts which is used for subsequent connections.

If the dig does not report the fingerprint, the connection may be continued without verification by entering yes.

The connection continues with user authentication.

After the user's identity has been validated ssh executes command or logs on and presents a shell prompt.

If the fingerprint was not verified the posibility exists that the connection has been made to a spoofing host.
Check the available files and if they are not what is expected:

  1. terminate the connection,
  2. Contact the host's administrator and have your password changed and explain that you had a connection spoofed.
  3. edit ~/.ssh/known_hosts and delete the last entry just entered for this host.

The session terminates when command or shell on the remote machine exits and any X11 and TCP connections have been closed.

-l login_name to use on the remote host, specifies on a per-host basis in the configuration file.

-F configfile an alternative per-user configuration file, 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 i.e. ssh -v -v -v . -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. Can also be specified on a per-host basis in a configuration file.
Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.
-aauthentication agent connection forwarding is Disables
-b bind_address on local machine as the source address of
-C compression of all data (including stdin, ,stdout, stderr, and data for forwarded X11 and TCP connections). The compression algorithm is the same used by gzip(1), and the level can be controlled by the CompressionLevel option for protocol version 1.
Compression is desirable on modem lines and other slow connections, but will slow down things on fast networks.
The default value can be set on a host‑by‑host basis in the configuration files; see the Compression option.
-c cipher_spec
  • Protocol version 1 allows specification of a single cipher.
    • 3des (triple-des) is an encrypt-decrypt-encrypt triple with three different keys (Default)
    • blowfish a fast block cipher; faster than 3des.
    • des is only supported in the ssh client for interoperability with legacy protocol 1 implementations that do not support the 3des cipher. Its use is strongly discouraged due to cryptographic weaknesses.
  • Protocol version 2, cipher_spec is a comma-separated list of ciphers listed 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 tries 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 can be specified with an alternative syntax: [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 available if support for smartcard devices is compiled in (default is no support).

-i identity_file file from which 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 can be specified with an alternative syntax: [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 Places the ssh client into 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 provide options 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
ChallengeResponseAuthentication 
CheckHostIP
Cipher
Ciphers
ClearAllForwardings
Compression
CompressionLevel
ConnectionAttempts
ConnectTimeout
ControlMaster
ControlPath
DynamicForward
EscapeChar
ExitOnForwardFailure
ForwardAgent
ForwardX11
ForwardX11Trusted
GSSAPIDelegateCredentials 
GatewayPorts
GlobalKnownHostsFile
GSSAPIAuthentication
HashKnownHosts
Host
HostbasedAuthentication
HostKeyAlgorithms
HostKeyAlias
HostName
IdentityFile
IdentitiesOnly
KbdInteractiveDevices
LocalCommand
LocalForward
LogLevel
MACs
NoHostAuthenticationForLocalhost 
NumberOfPasswordPrompts
PasswordAuthentication
PermitLocalCommand
Port
PreferredAuthentications
Protocol
ProxyCommand
PubkeyAuthentication
RekeyLimit
RemoteForward
RhostsRSAAuthentication
RSAAuthentication
SendEnv
ServerAliveInterval
ServerAliveCountMax
SmartcardDevice
StrictHostKeyChecking
TCPKeepAlive
Tunnel
TunnelDevice
UsePrivilegedPort
User
UserKnownHostsFile
VerifyHostKeyDNS
XAuthLocation

-p port Can be specified on a per-host basis in the configuration file.

-q Quiet (IMHO not a good idea). Warnings and diagnostics are suppressed.

-R [bind_address:]port:host:hostport port on the remote (server) host is to be forwarded to the given host and port on the local side.
Works by allocating a socket to listen to port on the remote side, and whenever a connection is made to this port, it is forwarded over the secure channel, and a connection is made to host port hostport from the local machine.

Port forwardings can also be specified in the configuration file.
Privileged ports can be forwarded only when logging in as root on the remote machine.
IPv6 addresses can be specified by enclosing the address in square braces or using an alternative syntax: [bind_address/]host/port/hostport.

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

-S ctl_path location of a 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 the keyword any, which uses the next available tunnel device. If remote_tun is not specified, it defaults to any. See also the Tunnel and TunnelDevice directives in ssh_config(5). If the Tunnel directive is unset, it is set to the default tunnel mode, which is point-to-point.

-X Enables X11 forwarding. can be specified on a per-host basis in a configuration file.

X11 forwarding should be enabled with caution.
Users with the ability to bypass file permissions on the remote host (for the user's X authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring.

For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default. refer to -Y and the ForwardX11Trusted directive in ssh_config(5) for more information.
-x Disables X11 forwarding.

-Y Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls.

ssh may additionally obtain configuration data from a per-user configuration file and a system-wide configuration file. The file format and configuration options are described in ssh_config(5).

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

AUTHENTICATION

The OpenSSH SSH client supports SSH protocols 1 and 2.
Protocol 2 is the default, with ssh falling back to protocol 1 if it detects protocol 2 is unsupported. These settings may be altered using the Protocol option in ssh_config(5), or enforced using the -1 and -2 options (see above). Both protocols support similar authentication methods, but protocol 2 is preferred since it provides additional mechanisms for confidentiality (the traffic is encrypted using AES, 3DES, Blowfish, CAST128, or Arcfour) and integrity (hmac-md5, hmac-sha1, hmac-ripemd160). Protocol 1 lacks a strong mechanism for ensuring the integrity of the connection.

The methods available for authentication are: GSSAPI-based authentication, host‑based authentication, public key authentication, challenge‑ response authentication, and password authentication.
Authentication methods are tried in that order, protocol 2 has a configuration option to change the default order.

Preferred Authentications

ssh maintains and checks a database containing identification for all hosts it has been used with, in ~/.ssh/known_hosts .
Additionally, the file /etc/ssh_known_hosts is checked for known hosts.
New hosts are added to the user's file.
If a host's identification differs from the previous one, ssh warns about this and disables password authentication to prevent server spoofing or man-in-the-middle attacks, which could be used to circumvent the encryption. 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 CHARACTERS

If a pseudo-terminal has been allocated (normal login session), the user may use the escape characters to control the connection, i.e. issue commands to ssh.

If a pseudo-terminal has not been allocated(-T), the session is transparent and can be used to reliably transfer binary data. On most systems, setting the escape character to none will also make the session transparent even if a tty is used.

Only recognized at the beginning of a line, and if next character is not one of the escape sequences the characters are sent to the host.
So typing ~/scriptname is not handled specially.
Default escape is ~ .

~~ transmit ~
~. Disconnect.
~^Z Background ssh.
~# List forwarded connections.
~& Background ssh at logout when waiting for forwarded connection / X11 sessions to terminate.
~? Display a list of escape characters.
~B Send a BREAK to the remote system (only useful for SSH protocol version 2 and if the peer supports it)
~R Request rekeying of the connection (only version 2 if the peer supports it).
~C Open command line. allows addition of
-L[bind_address:]port:host:hostport Request local forward
-R[bind_address:]port:host:hostport Request remote forward
-D[bind_address:]port Request dynamic forward
-KR[bind_address:]port Cancel remote forward
!command allows executetion of a command at the local host if PermitLocalCommand is enabled in ssh_config.
Basic help is available, using the -h option.

The escape character can be changed in configuration files with the EscapeChar or on the command line with -e .

-e escape_char (default: ~). Setting the character to none disables escapes and makes the session fully transparent.

Environment Variables

DISPLAYindicates the location of the X11 server. points to a value of the form hostname:n , where hostname indicates the host where the shell runs, and n is an integer > 0. ssh uses this special value to forward X11 connections over the secure channel. The user should normally not set DISPLAY explicitly, as that will render the X11 connection insecure (and will require the user to manually copy any required authorization cookies).
HOME
LOGNAME Synonym for USER
MAIL path of the user's mailbox. example:/var/spool/mail/realr
PATH default PATH, as specified when compiling ssh.
SSH_ASKPASS If ssh needs a passphrase, it will ask the passphrase from the current terminal if it was run from a terminal. If ssh does not have a terminal associated with it but DISPLAY and SSH_ASKPASS are set, it will execute the program specified by SSH_ASKPASS and open an X11 window to read the passphrase. This is particularly useful when calling ssh from a .xsession or related script. (Note that on some machines it may be necessary to redirect the input from /dev/null to make this work.)
SSH_AUTH_SOCK path of a UNIX-domain socket used to communicate with the agent.
SSH_CONNECTION space-separated : client IP address, client port number, server IP address, and server port number.
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 (i.e. the daemon passes the value on to new connections).
USER Set to the name of the user logging in.
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).

FILES

see sshd
~/.rhosts used for host‑based authentication. world-readable if the user's home directory is on an NFS partition, because sshd(8) reads it as root. owned by the user, and must not have write permissions for group or world.

~/.shosts used as .rhosts which allows host‑based authentication without permitting login with rlogin/rsh.

~/.ssh/authorized_keys Lists the public keys (RSA/DSA) for this user. The format of this file is described in the sshd(8) manual page. This file is not highly sensitive, but the recommended permissions rw-------.

~/.ssh/config per-user configuration file. The file format and configuration options are described in ssh_config(5). permissions: rw-------

~/.ssh/environment Contains additional definitions for environment variables; see Environment

~/.ssh/identity
~/.ssh/id_dsa
~/.ssh/id_rsa Contains the private key for authentication.
These files contain sensitive data and should be readable by the user but not accessible by others (rwx------
ssh ignores a private key file if it is accessible by others.
It is possible to specify a passphrase when generating the key which will be used to encrypt the sensitive part of this file using 3DES.

~/.ssh/identity.pub
~/.ssh/id_dsa.pub
~/.ssh/id_rsa.pub Contains the public key for authentication. These files are not sensitive and can (but need not) be readable by anyone.

~/.ssh/known_hosts Contains a list of host keys for all hosts the user has logged into that are not already in the systemwide list of known host keys. See sshd(8) for further details of the format of this file.

~/.ssh/rc Commands in this file are executed when the user logs in, before the user's shell (or command) is started. See sshd(8)

/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 file from darwin Mac OS X. Notice all lines are commented out.
/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 contain the private parts of the host keys and are used for host‑based authentication. If protocol version 1 is used, ssh must be setuid root, since the host key is readable only by root. For protocol version 2, ssh uses ssh-keysign(8) to access the host keys, eliminating the requirement that ssh be setuid root when host‑based authentication is used. By default ssh is not setuid root.

/etc/ssh_known_hosts Systemwide list of known host keys. This file should be prepared by the system administrator to contain the public host keys of all machines in the organization. It should be world-readable. See sshd(8)

/etc/sshrc Commands in this file are executed by ssh when the user logs in, just before the user's shell (or command) is started. See the sshd(8)

See also

screen, 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)

The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, 2006.
Architecture: RFC 4251, Authentication Protocol: RFC 4252, Transport Layer Protocol: RFC 4253, Connection Protocol: RFC 4254,
Session Channel Break Extension: RFC 4335, Transport Layer Encryption Modes: RFC 4344,
Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255,
Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256,
Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345,
Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419,

Errors

  1. ssh_exchange_identification: Connection closed by remote host
    Tried several time, 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
    
    success

  2. 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