Home | History | Annotate | Download | only in contrib
      1 .ig \"  -*- nroff -*-
      2 Copyright (c) 1999-2013 hands.com Ltd. <http://hands.com/>
      3 
      4 Redistribution and use in source and binary forms, with or without
      5 modification, are permitted provided that the following conditions
      6 are met:
      7 1. Redistributions of source code must retain the above copyright
      8    notice, this list of conditions and the following disclaimer.
      9 2. Redistributions in binary form must reproduce the above copyright
     10    notice, this list of conditions and the following disclaimer in the
     11    documentation and/or other materials provided with the distribution.
     12 
     13 THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
     14 IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
     15 OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
     16 IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
     17 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
     18 NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
     19 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
     20 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
     21 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
     22 THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     23 ..
     24 .Dd $Mdocdate: June 17 2010 $
     25 .Dt SSH-COPY-ID 1
     26 .Os
     27 .Sh NAME
     28 .Nm ssh-copy-id
     29 .Nd use locally available keys to authorise logins on a remote machine
     30 .Sh SYNOPSIS
     31 .Nm
     32 .Op Fl f
     33 .Op Fl n
     34 .Op Fl i Op Ar identity_file
     35 .Op Fl p Ar port
     36 .Op Fl o Ar ssh_option
     37 .Op Ar user Ns @ Ns
     38 .Ar hostname
     39 .Nm
     40 .Fl h | Fl ?
     41 .br
     42 .Sh DESCRIPTION
     43 .Nm
     44 is a script that uses
     45 .Xr ssh 1
     46 to log into a remote machine (presumably using a login password,
     47 so password authentication should be enabled, unless you've done some
     48 clever use of multiple identities).  It assembles a list of one or more
     49 fingerprints (as described below) and tries to log in with each key, to
     50 see if any of them are already installed (of course, if you are not using
     51 .Xr ssh-agent 1
     52 this may result in you being repeatedly prompted for pass-phrases).
     53 It then assembles a list of those that failed to log in, and using ssh,
     54 enables logins with those keys on the remote server.  By default it adds
     55 the keys by appending them to the remote user's
     56 .Pa ~/.ssh/authorized_keys
     57 (creating the file, and directory, if necessary).  It is also capable
     58 of detecting if the remote system is a NetScreen, and using its
     59 .Ql set ssh pka-dsa key ...
     60 command instead.
     61 .Pp
     62 The options are as follows:
     63 .Bl -tag -width Ds
     64 .It Fl i Ar identity_file
     65 Use only the key(s) contained in
     66 .Ar identity_file
     67 (rather than looking for identities via
     68 .Xr ssh-add 1
     69 or in the
     70 .Ic default_ID_file ) .
     71 If the filename does not end in
     72 .Pa .pub
     73 this is added.  If the filename is omitted, the 
     74 .Ic default_ID_file
     75 is used.
     76 .Pp
     77 Note that this can be used to ensure that the keys copied have the
     78 comment one prefers and/or extra options applied, by ensuring that the
     79 key file has these set as preferred before the copy is attempted.
     80 .It Fl f
     81 Forced mode: doesn't check if the keys are present on the remote server.
     82 This means that it does not need the private key.  Of course, this can result
     83 in more than one copy of the key being installed on the remote system.
     84 .It Fl n
     85 do a dry-run.  Instead of installing keys on the remote system simply
     86 prints the key(s) that would have been installed.
     87 .It Fl h , Fl ?
     88 Print Usage summary
     89 .It Fl p Ar port , Fl o Ar ssh_option
     90 These two options are simply passed through untouched, along with their
     91 argument, to allow one to set the port or other
     92 .Xr ssh 1
     93 options, respectively.
     94 .Pp
     95 Rather than specifying these as command line options, it is often better to use (per-host) settings in
     96 .Xr ssh 1 Ns 's
     97 configuration file:
     98 .Xr ssh_config 5 .
     99 .El
    100 .Pp
    101 Default behaviour without
    102 .Fl i ,
    103 is to check if
    104 .Ql ssh-add -L
    105 provides any output, and if so those keys are used.  Note that this results in
    106 the comment on the key being the filename that was given to
    107 .Xr ssh-add 1
    108 when the key was loaded into your
    109 .Xr ssh-agent 1
    110 rather than the comment contained in that file, which is a bit of a shame.
    111 Otherwise, if
    112 .Xr ssh-add 1
    113 provides no keys contents of the 
    114 .Ic default_ID_file
    115 will be used.
    116 .Pp
    117 The
    118 .Ic default_ID_file
    119 is the most recent file that matches:
    120 .Pa ~/.ssh/id*.pub ,
    121 (excluding those that match
    122 .Pa ~/.ssh/*-cert.pub )
    123 so if you create a key that is not the one you want
    124 .Nm
    125 to use, just use
    126 .Xr touch 1
    127 on your preferred key's 
    128 .Pa .pub
    129 file to reinstate it as the most recent.
    130 .Pp
    131 .Sh EXAMPLES
    132 If you have already installed keys from one system on a lot of remote
    133 hosts, and you then create a new key, on a new client machine, say,
    134 it can be difficult to keep track of which systems on which you've
    135 installed the new key.  One way of dealing with this is to load both
    136 the new key and old key(s) into your
    137 .Xr ssh-agent 1 .
    138 Load the new key first, without the
    139 .Fl c
    140 option, then load one or more old keys into the agent, possibly by
    141 ssh-ing to the client machine that has that old key, using the
    142 .Fl A
    143 option to allow agent forwarding:
    144 .Pp
    145 .D1 user@newclient$ ssh-add
    146 .D1 user@newclient$ ssh -A old.client
    147 .D1 user@oldl$ ssh-add -c
    148 .D1 No   ... prompt for pass-phrase ...
    149 .D1 user@old$ logoff
    150 .D1 user@newclient$ ssh someserver
    151 .Pp
    152 now, if the new key is installed on the server, you'll be allowed in
    153 unprompted, whereas if you only have the old key(s) enabled, you'll be
    154 asked for confirmation, which is your cue to log back out and run
    155 .Pp
    156 .D1 user@newclient$ ssh-copy-id -i someserver
    157 .Pp
    158 The reason you might want to specify the -i option in this case is to
    159 ensure that the comment on the installed key is the one from the
    160 .Pa .pub
    161 file, rather than just the filename that was loaded into you agent.
    162 It also ensures that only the id you intended is installed, rather than
    163 all the keys that you have in your
    164 .Xr ssh-agent 1 .
    165 Of course, you can specify another id, or use the contents of the
    166 .Xr ssh-agent 1
    167 as you prefer.
    168 .Pp
    169 Having mentioned
    170 .Xr ssh-add 1 Ns 's
    171 .Fl c
    172 option, you might consider using this whenever using agent forwarding
    173 to avoid your key being hijacked, but it is much better to instead use
    174 .Xr ssh 1 Ns 's
    175 .Ar ProxyCommand
    176 and 
    177 .Fl W
    178 option,
    179 to bounce through remote servers while always doing direct end-to-end
    180 authentication. This way the middle hop(s) don't get access to your
    181 .Xr ssh-agent 1 .
    182 A web search for
    183 .Ql ssh proxycommand nc
    184 should prove enlightening (N.B. the modern approach is to use the
    185 .Fl W
    186 option, rather than
    187 .Xr nc 1 ) .
    188 .Sh "SEE ALSO"
    189 .Xr ssh 1 ,
    190 .Xr ssh-agent 1 ,
    191 .Xr sshd 8
    192