ssh

OpenSSH SSH client (remote login )


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] ssh-copy-id
As with all the documentation on this site, this is rearrange and tersefied(in this case perhaps bludgened is a better phrase.

Used to logon to a remote host, using a shell, 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:

 /usr/bin/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.  (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 by QQQQQQQQ, 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_… type -1 
debug1: identity file /Users/me/.ssh/id_…-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_…: 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_…
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[, …] list of 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_… 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=x
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µ 
 µ This options is unsupported as per OpenSSH_8.6p1, LibreSSL 3.3.6 in use on Apple Mac os Ventura 13.1.

NIST CVE OpenSSH through 7.7 is subject to a vulnerability.

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 subsystem Invokes subsystem on the remote system to use 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 Enable X11 forwarding.
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.

Example:

/usr/bin/ssh -o EscapeChar=_ pi93graf 

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+Q1BEuKKu1REAocsIimS3pWjA.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.3.1' (…) 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 option controls logins to machines whose host key is not known or has changed.

TCP FORWARDING

Forwarding an 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.

This example is for encrypting communication between an IRC client and a server which 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.

      $ 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, using port 1234 and nickname pinky. It doesn't matter which port is used, as long as it doesn't conflict with ports already in use and is greater than 1023 ( only processes with root priveledge can open sockets below 1024.) The connection is forwarded to port 6667 on the remote server, the standard port for IRC services. -f Backgrounds ssh and sleep 10 is specified to allow some time to start the service which is to be tunnelled. If no connections are made within the time specified, ssh exits.

X11 FORWARDING

If ForwardX11 is set to yes or -X, -x, and -Y ) and the user is using X11 ($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 sysetm. 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 system (and no cookies are sent in the plain).

If ForwardAgent is set to yes (or -A and -a ) 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_…
    2048 7c:df:03:a8:49:1d:38:19:f7:f9:d7:13:3d:40:4d:f0   (…)

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  # domain name can be anything and prefixes the records

real-world-systems.com IN SSHFP 1 1 ab1454f8dee3955b89b137f88c765ab3ff54a12e
real-world-systems.com IN SSHFP 1 2 0404389c97116e9e0a7577a59f4e50f19159d28ea10a16a27b9d3d695cdb5ac1
real-world-systems.com IN SSHFP 2 1 cea9b5762b439a81592ae81730176307e0bd4a21
real-world-systems.com IN SSHFP 2 2 73742e8157fe150dc20e1481dee2e4121295b41b6d61ec43f726cf9295e6ded9
real-world-systems.com IN SSHFP 3 1 44242fde7d79fc316d52acfeac0d330aebe9a8e6
real-world-systems.com IN SSHFP 3 2 c608578c4a032d2ead79d4007a1bbf9fd24da54668125140a25f9a5558a412c7
real-world-systems.com IN SSHFP 4 1 3556fb30d5b4e2bde08ab62b4b8652ed78011c99
real-world-systems.com IN SSHFP 4 2 a70e22ea7f3765e7661956ae0e05446e6ee80c4fb7ebd1d9174cf1e2c7369dba
Put VerifyHostKeyDNS ask in your SSH client's config, usually ~/.ssh/config..

From ssh 4/04/19 Real-World-Systems.com Host key fingerprint is SHA256:0iQLS2WV1astZFyoKJThVcQKegJeucMSlXS9hmRGFhY

For Real-World-Systems.com ECDSA key fingerprint is SHA256:AA1Fco7eRba7XiYbqERz9wNls+rDsUWE98f/9IhsEgw. ECDSA key fingerprint is MD5:e2:08:4d:51:02:0c:19:df:6f:7d:f8:7c:cc:a0:48:a4.

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.
ssh_config PermitTunnel controls If the server supports this, and at what level (layer 2 or 3 traffic).

This 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 and the PermitRootLogin server option.

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

       tunnel="1",command="sh /etc/netstart tun1" ssh-… ... jane
       tunnel="2",command="sh /etc/netstart tun2" ssh-… ... 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 and isakmpd.

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

$DISPLAYLocation of the X11 server 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_CLIENT SSH_CLIENT='96.242.40.59 51677 2233'
$SSH_TTY SSH_TTY=/dev/pts/0
$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.
May be adjusted by users .profile.
$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.

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_… private key for authentication. must be 700 ~/.ssh/identity.pub
~/.ssh/id_dsa.pub
~/.ssh/id_….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_… 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

sshd scp, sftp, ssh-add, ssh-agent, ssh-keygen, ssh-keyscan, tun(4), hosts.equiv(5), ssh_config(5), ssh-keysign(8), sshd(8)

Errors

  1. /usr/bin/ssh-copy-id: ERROR: failed to open ID file '/home/duser/.pub': No such file (to install the contents of '/home/duser/.pub' anyway, look at -f )
    This occurs when the users home is not in /home
    use cat to get the keys.
  2. Address 174.327.119.33 maps to our-systems.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!  
  3. /usr/bin/ssh-copy-id: ERROR: No identities found
  4. ssh_dispatch_run_fatal: Connection to 192.168.3.1 port 22: Broken pipe 
    : The server disconnected most likely due to timeout 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.
  5. 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_… type 1
    debug1: identity file /Users/me/.ssh/id_…-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
    
    
    
  6. 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
  7. success

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

Errors

ssh_exchange_identification: read: Connection reset by peer

Host is down

Operation timed out

no matching host key type found. Their offer: ssh-…

 ~/.ssh/config
Host ssh.dev.azure.com
    User git
    PubkeyAcceptedAlgorithms +ssh-…
    HostkeyAlgorithms +ssh-… 
deprecated name PubkeyAcceptedKeyTypes instead of PubkeyAcceptedAlgorithms

ERROR: No identities found


Permission denied (publickey)



Definitive: OpenSSH for OpenBSD

sshd


ssh-copy-id

ssh-copy-id [-f] [-n] [-s] [-i [identity_file]] [-p port] [-o ssh_option] [user@]hostname
ssh-copy-id -h | -?

Assembles fingerprints and enables logins with those keys on the remote host by appending them to the remote user's ~/.ssh/authorized_keys

-i identity_file[.pub] Use only key(s) contained in identity_file .
Default default_ID_file (Not via ssh-add).
-f force don't check if the keys are present on the remote server.
-n not real-run,do a dry-run. outputs key(s) that would have been installed.
-s sftp mode: User's ~/.ssh/authorized_keys will be downloaded, modified locally and uploaded with sftp.
Useful if the server has restrictions on commands which can be used on the remote side.
-p port 
-o ssh_option It is preferred to use per-host settings in ssh_config.
-h
-?
display Usage summary

Default behaviour without -i use output from ssh-add -L .
This results in the comment on the key being the filename that was given to ssh-add when the key was loaded into your ssh-agent rather than the comment contained in that file. Otherwise, if ssh-add provides no keys contents of the default_ID_file will be used.

The default_ID_file is the most recent file that matches: ~/.ssh/id*.pub (excluding those that match ~/.ssh/*-cert.pub)
touch a key's .pub (making it newest) to have ssh-copy-id use a specific file.

Example

If you have installed keys from one system on several remote hosts, and then create a new key, on a new client machine, it can be difficult to keep track of which systems on which you've installed the new key.
Load both the new key and old key(s) into ssh-agent.
The new key first, without -c , then load one or more old keys into the agent, possibly by ssh-ing to the client machine that has that old key, using -A to allow agent forwarding:
 
           user@newclient$ ssh-add
           user@newclient$ ssh -A old.client
           user@oldl$ ssh-add -c
           ... prompt for pass-phrase ...
           user@old$ logoff
           user@newclient$ ssh someserver
now, if the new key is installed on the server: user@newclient$ ssh-copy-id -i someserver Specify -i in this case is to ensure that the comment on the installed key is the one from the .pub , rather than the filename that was loaded into your agent. It also ensures that only the id you intended is installed, rather than all the keys that you have in your ssh-agent. You can specify another id, or use the contents of the ssh-agent as you prefer.

Use ssh-add -c when using agent forwarding to avoid keys from being hijacked, It is better to use ssh's ProxyCommand and -W, to bounce through remote servers while always doing direct end-to-end authentication. This way the middle hop(s) don't get access to your ssh-agent.
Do a web search for ssh proxycommand nc (use the -W rather than nc).


ssh-add

adds private key identities to the authentication agent

ssh-add [-cDdkLlXx] [-E fingerprint_hash] [-t lifetime ] [file ]

ssh-add -e|-s pkcs11

Adds private key identities to the authentication agent, ssh-agent(1).

Without arguments, it adds ~/.ssh/id_…, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/identity.
After loading a private key, loads the corresponding certificate information from the filename obtained by appending -cert.pub to the name of the private key file.
Alternative file names can be given on the command line.

If a file requires a passphrase, it is accepted from the tty. The last passphrase is used if multiple identity files are given.

The authentication agent must be running and the $SSH_AUTH_SOCK must contain the name of its socket

-c added identities should be subject to confirmation before being used for authentication by ssh-askpass.
Zero exit status from ssh-askpass indicates successful confirmation rather text entered into the requester.
-D Deletes all identities from the agent.
-d pubKeyFiles[.pub] [,…] Deletes identites specified in the list of paths to public key files.
Default: Keys for the default identities and certificates.
-E md5 | sha256 algorithm used when displaying key fingerprints. default : sha256.
-k process plain private keys only.
-L List public key parameters of all identities currently represented by the agent.
-l List fingerprints of all identities.
-s pkcs11 Add PKCS#11 keys
-e pkcs11 erase PKCS#11 keys
-t lifetime Set a maximum lifetime in seconds or expiration in a time format specified in sshd_config
-X Unlock the agent.
-x Lock the agent with a password.

ENVIRONMENT

$DISPLAY and $SSH_ASKPASS
If ssh-add needs a passphrase, it will read it from the current terminal.
If no a terminal is associated but $DISPLAY and SSH_ASKPASS are set, it will execute the program specified by $SSH_ASKPASS (default ssh-askpass) and open an X11 window to read the passphrase. Useful when using an .xsession or related script.
Some machines may require redirecting the input to /dev/null .

$SSH_AUTH_SOCK
Path of a UNIX-domain socket used to communicate with the agent.

FILES

version 1 RSA ~/.ssh/identity ~/.ssh/identity.pub
version 2 DSA ~/.ssh/id_dsa~/.ssh/id_dsa.pub
version 2 ECDSA ~/.ssh/id_ecdsa~/.ssh/id_ecdsa.pub
version 2 Ed25519 ~/.ssh/id_ed25519~/.ssh/id_ed25519.pub
version 2 RSA ~/.ssh/id_rsa~/.ssh/id_rsa.pub

Identity files should be readable only by the user. ssh-add ignores identity files if they are accessible by others.


ssh-agent

authentication agent

ssh-agent [-c | -s] [-Dd] [-a bind_address] [-E fingerprint_hash] [-t lifetime] [command [arg ...]]
ssh-agent [-c | -s] -k

Holds private keys used for public key authentication (RSA, DSA, ECDSA, Ed25519).
Usually started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to ssh-agent . Environment variables allow the agent to be located and used for authentication when logging in to other machines using ssh .

The agent initially does not have any private keys. Keys are added using ssh-add. Multiple identities may be stored concurrently and ssh will use them if present.
ssh-add removes and query the keys that are held.

-a bind_address Bind the agent to the UNIX-domain socket bind_address. Default $TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>.
-c Generate C-shell commands . Default if SHELL looks like it's a csh
-s Generate Bourne shell commands. Default if SHELL does not look like it's a csh
-D Foreground mode. does not fork.
-d Debug mode. does not fork and writes debug information to standard error.
-E md5 | sha256 Hash algorithm used when displaying key fingerprints. Default sha256.
-k Kill the current agent (given by the $SSH_AGENT_PID).
-t lifeTime Set a default value for the maximum lifetime of identities added to the agent in seconds or in a format specified in sshd_config.
A lifeTime for an identity with ssh-add overrides this .
Default maximum lifetime is forever.

If a commandline is given, this is executed as a subprocess of the agent. When the command dies, so does the agent.

The agent is run in the user's local terminal. Authentication data need not be stored on any other machine and authentication passphrases don't go over the network. The connection to the agent is forwarded over SSH remote logins and the user can use the privileges given by the identities anywhere in the network in a secure way.