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.

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

Before connecting 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 verifying the finger print answer yes which 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 DISCONNECT (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).
If there is nothing to use to verify the fingerprint, continue but beware that the finger print will be added to ~/.ssh/known_hosts for subsequent connections.
Copy/paste the randomart into a file for future comparision.

host key: is used to verify the identity of the remote host,
To display the host's randomart include -o VisualHostKey=yes in the ssh command line, or put VisualHostKey=yes in ~/.ssh/config.

Host key fingerprint is SHA256:0iQLS2WV1astZFyoKJThVcQKegJeucMSlXS9hmRGFhY
+---[RSA 2048]----+
|  oo=EB=+o.o     |
|.. =BB .o . o    |
|..+oO.oooo . .   |
| oo=o+oB. + .    |
|  .oo.+ So o     |
|       .  o .    |
|           .     |
|                 |
|                 |
+----[SHA256]-----+
If the randomart is unfamiluar there may be a Man In The Middle attaack or the host is not the genuine one!

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

ssh has many variants and many options from antiquity(well pre broadband connection anyway) many of which no longer make sense.

-l login_name to use on the remote host
-F [configfile] default:/.ssh/config. The system-wide configuration file (/etc/ssh_config) is ignored.
-v Verbose mode. display debugging messages.
For debugging connection, authentication, and configuration. 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/me/.ssh/id_rsa type -1 
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.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/me/.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/me/.ssh/id_rsa
debug1: Trying private key: /Users/me/.ssh/id_dsa
debug1: Next authentication method: password

Another eample: 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 MACs keyword
-D [bind_address:]port 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 background just before command execution.
Useful if ssh will ask for passwords, but the user wants it in the background.
Implies -n.
The recommended syntax to start X11 programs: ssh -f host xterm.
-n Redirects stdin from /dev/null (i.e., prevents reading from stdin).
Required 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 emacs on shadows.cs.hut.fi, and the X11 connection will be automatically forwarded over an encrypted channel, ssh is put in the background.
Not if password is needed; see -f
-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 version 1 and
/.ssh/id_rsa and ~/.ssh/id_dsa for version 2.
May be specified on a perhost basis in the configuration file.
Multiple -i options (and multiple identities specified in configuration files) are 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).
-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
ChallengeResponseAuthentication
CheckHostIP
Cipher
Ciphers
ClearAllForwardings
Compression
CompressionLevel
ConnectionAttempts
ConnectTimeout
ControlMaster
ControlPath
ControlPersist
DynamicForward
EscapeChar
ExitOnForwardFailure
ForwardAgent
ForwardX11
ForwardX11Timeout
ForwardX11Trusted
GlobalKnownHostsFile
GSSAPIAuthentication
GSSAPIDelegateCredentials
HashKnownHosts
Host
HostbasedAuthentication
HostKeyAlgorithms
HostKeyAlias
HostName
IdentityFile
IdentitiesOnly
IPQoS
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
LocalCommand
LocalForward
LogLevel
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
PasswordAuthentication
PermitLocalCommand
PKCS11Provider
Port
PreferredAuthentications
Protocol
ProxyCommand
PubkeyAuthentication
RekeyLimit
RemoteForward
RequestTTY
RhostsRSAAuthentication
RSAAuthentication
ServerAliveInterval
ServerAliveCountMax
StrictHostKeyChecking
TCPKeepAlive
Tunnel
TunnelDevice
UsePrivilegedPort
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
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 invoces 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, rsync). 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 Options

/etc/ssh_known_hosts is checked for known hosts.
~/.ssh/known_hosts contains identification for hosts.
New hosts can be added by ssh on first connection.

The authenticity of host '192.168.3.1 (192.168.3.1)' can't be established. RSA key fingerprint is SHA256:AI+Xndd4h3tbWICI+Q1BEuKKu1REAocsIiZNmS3pWjA. Are you sure you want to continue connecting (yes/no)? yesi Warning: Permanently added '192.168.3.1' (RSA) to the list of known hosts.
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

Used to communicate tot the ssh utility (not the remote host) once connected. Valid escape pairs are only recognized at the beginning of a line. Typing ~/scriptname is not treated as an escape.
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. Address 174.327.119.33 maps to our-systems.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
    
    There is a mismatch in the DNS system.
    Issue dig our-systems.com and determine which address is correct and have the DNS records corrected.
  2. 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/me/.ssh/id_rsa type 1
    debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
    debug1: identity file /Users/me/.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
    
    
    
  3. 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
  4. success

  5. 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't be completed. Socket is not connected
    applepushserviced[90]: <APSCourier: 0x102e27bb0>: Stream error occurred for <APSTCPStream: 0x7fe46351c1e0>: The operation          couldn't be completed. (kCFErrorDomainCFNetwork error 2.
    com.apple.var-db-shadow-backup[92780]: Error adding file shadow

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!

Definitive: OpenSSH for OpenBSD

sshd