2 Copyright (c) 1999-2013 hands.com Ltd. <http://hands.com/>
4 Redistribution and use in source and binary forms, with or without
5 modification, are permitted provided that the following conditions
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.
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.
29 .Nd use locally available keys to authorise logins on a remote machine
33 .Op Fl i Op Ar identity_file
35 .Op Fl o Ar ssh_option
45 to log into a remote machine (presumably using a login password,
46 so password authentication should be enabled, unless you've done some
47 clever use of multiple identities). It assembles a list of one or more
48 fingerprints (as described below) and tries to log in with each key, to
49 see if any of them are already installed (of course, if you are not using
51 this may result in you being repeatedly prompted for pass-phrases).
52 It then assembles a list of those that failed to log in, and using ssh,
53 enables logins with those keys on the remote server. By default it adds
54 the keys by appending them to the remote user's
55 .Pa ~/.ssh/authorized_keys
56 (creating the file, and directory, if necessary). It is also capable
57 of detecting if the remote system is a NetScreen, and using its
58 .Ql set ssh pka-dsa key ...
61 The options are as follows:
63 .It Fl i Ar identity_file
64 Use only the key(s) contained in
66 (rather than looking for identities via
69 .Ic default_ID_file ) .
70 If the filename does not end in
72 this is added. If the filename is omitted, the
76 Note that this can be used to ensure that the keys copied have the
77 comment one prefers and/or extra options applied, by ensuring that the
78 key file has these set as preferred before the copy is attempted.
80 do a dry-run. Instead of installing keys on the remote system simply
81 prints the key(s) that would have been installed.
84 .It Fl p Ar port , Fl o Ar ssh_option
85 These two options are simply passed through untouched, along with their
86 argument, to allow one to set the port or other
88 options, respectively.
90 Rather than specifying these as command line options, it is often better to use (per-host) settings in
96 Default behaviour without
100 provides any output, and if so those keys are used. Note that this results in
101 the comment on the key being the filename that was given to
103 when the key was loaded into your
105 rather than the comment contained in that file, which is a bit of a shame.
108 provides no keys contents of the
114 is the most recent file that matches:
116 (excluding those that match
117 .Pa ~/.ssh/*-cert.pub )
118 so if you create a key that is not the one you want
122 on your preferred key's
124 file to reinstate it as the most recent.
127 If you have already installed keys from one system on a lot of remote
128 hosts, and you then create a new key, on a new client machine, say,
129 it can be difficult to keep track of which systems on which you've
130 installed the new key. One way of dealing with this is to load both
131 the new key and old key(s) into your
133 Load the new key first, without the
135 option, then load one or more old keys into the agent, possibly by
136 ssh-ing to the client machine that has that old key, using the
138 option to allow agent forwarding:
140 .D1 user@newclient$ ssh-add
141 .D1 user@newclient$ ssh -A old.client
142 .D1 user@oldl$ ssh-add -c
143 .D1 No ... prompt for pass-phrase ...
145 .D1 user@newclient$ ssh someserver
147 now, if the new key is installed on the server, you'll be allowed in
148 unprompted, whereas if you only have the old key(s) enabled, you'll be
149 asked for confirmation, which is your cue to log back out and run
151 .D1 user@newclient$ ssh-copy-id -i someserver
153 The reason you might want to specify the -i option in this case is to
154 ensure that the comment on the installed key is the one from the
156 file, rather than just the filename that was loaded into you agent.
157 It also ensures that only the id you intended is installed, rather than
158 all the keys that you have in your
160 Of course, you can specify another id, or use the contents of the
167 option, you might consider using this whenever using agent forwarding
168 to avoid your key being hijacked, but it is much better to instead use
174 to bounce through remote servers while always doing direct end-to-end
175 authentication. This way the middle hop(s) don't get access to your
178 .Ql ssh proxycommand nc
179 should prove enlightening (N.B. the modern approach is to use the