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-id-copy
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:

 /usr/bin/dig -t SSHFP +short 
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 (' 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.
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
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 .    |
|           .     |
|                 |
|                 |
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
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to [] 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 '' 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_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,
-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 emacs & will start emacs on, 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).

 µ These options are unsupported as per OpenSSH_8.6p1, LibreSSL 3.3.6 in use on Apple Mac os Ventura 13.1 OpenSSH through 7.7 is prone to a user enumeration vulnerability due to not delaying bailout for an invalid authenticating user until after the packet containing the request has been fully parsed

-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 ' (' 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 '' (RSA) to the list of known hosts.
If a host's identification differs from the previous one, ssh reports:
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
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 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.


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 (localhost) to remote server

 $ ssh -f -L 1234:localhost:6667 sleep 10
 $ irc -c '#users' -p 1234 pinky

This tunnels a connection to IRC server, 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.


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  # domain name can be anything and prefixes the records IN SSHFP 1 1 ab1454f8dee3955b89b137f88c765ab3ff54a12e IN SSHFP 1 2 0404389c97116e9e0a7577a59f4e50f19159d28ea10a16a27b9d3d695cdb5ac1 IN SSHFP 2 1 cea9b5762b439a81592ae81730176307e0bd4a21 IN SSHFP 2 2 73742e8157fe150dc20e1481dee2e4121295b41b6d61ec43f726cf9295e6ded9 IN SSHFP 3 1 44242fde7d79fc316d52acfeac0d330aebe9a8e6 IN SSHFP 3 2 c608578c4a032d2ead79d4007a1bbf9fd24da54668125140a25f9a5558a412c7 IN SSHFP 4 1 3556fb30d5b4e2bde08ab62b4b8652ed78011c99 IN SSHFP 4 2 a70e22ea7f3765e7661956ae0e05446e6ee80c4fb7ebd1d9174cf1e2c7369dba
Put VerifyHostKeyDNS ask in your SSH client's config, usually ~/.ssh/config..

From ssh 4/04/19 Host key fingerprint is SHA256:0iQLS2WV1astZFyoKJThVcQKegJeucMSlXS9hmRGFhY

For 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 +short

the client connects:

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

See VerifyHostKeyDNS in ssh_config(5)


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 with remote network using a point-to-point connection from to, provided that the SSH server running on the gateway to the remote network, at, allows it.

On the client:
 # ssh -f -w 0:1 true
 # ifconfig tun0 netmask
 # route add 
On the server:
 # ifconfig tun1 netmask
 # route add 
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

~# 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.


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=' 49516 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
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).


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/id_rsa private key for authentication. must be 700 ~/.ssh/
~/.ssh/ 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_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, sftp, ssh-add, ssh-agent, ssh-keygen, ssh-keyscan, tun(4), hosts.equiv(5), ssh_config(5), ssh-keysign(8), sshd(8)


  1. Address 174.327.119.33 maps to, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
  2. ssh_dispatch_run_fatal: Connection to port 22: Broken pipe 
    : The server disconnected most likely due to timeout There is a mismatch in the DNS system.
    Issue dig and determine which address is correct and have the DNS records corrected.
  3. 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
    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 [] 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 $?
  4. 5/01/17 sshgd aicv is now/usr/bin/dig +short +nocl +short +noshort to show ttl +nssearch for NameServers GoDaddy is --failed, see sshgd.sshvvv.log debug2: ciphers stoc: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-ctr,aes192-ctr,aes256-ctr debug2: MACs ctos: hmac-md5,hmac-sha1,,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96 debug2: MACs stoc: hmac-md5,hmac-sha1,,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96 debug2: compression ctos: none, debug2: compression stoc: none, 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 port 22: no matching host key type found. Their offer: ssh-dss
  5. success

  6. 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!.


     /* we need this for the home * directory.  */
        pw = getpwuid(getuid());
        if (!pw) { printf("You don't exist, go away!\n"); exit(1);
     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. 

    /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.[92780]: Error adding file shadow


ssh_exchange_identification: read: Connection reset by peer

Host is down

Operation timed out

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



use locally available keys to authorise logins on a remote machine

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 Use only the key(s) contained in identity_file (rather than looking for identities via ssh-add or in the default_ID_file). If the filename does not end in .pub this is added.

-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
pass through with their argument, to allow setting the port or other ssh options It is better to use (per-host) settings in ssh_config(5).
display Usage summary

Default behaviour without -i, is to check if `ssh-add -L' provides any output, and if so those keys are used.
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/*
If you created a key that is not the one you want ssh-copy-id to use, touch your preferred key's .pub file cause it to be newest.


If you have already installed keys from one system on a lot of remote hosts, and you then create a new key, on a new client machine, say, 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, you'll 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.

Consider using ssh-add -c when using agent forwarding to avoid your key being hijacked, It is better to use ssh's ProxyCommand and -W option, 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.
A web search for `ssh proxycommand nc' should prove enlightening (use the -W rather than nc).