3c1d80a77075bb90153d16ca501db316124bb1fb
[blog.git] / _posts / 2007-12-29-ssh_triggers.html
1 ---
2 layout: post
3 title: SSH "triggers"
4 date: '2007-12-29 14:24:00 +0000'
5 mt_id: 115
6 blog_id: 1
7 post_id: 115
8 basename: ssh_triggers
9 categories:
10 - tech
11 ---
12
13 <p>
14 Following my <a href="http://blog.ganneff.de/blog/2007/12/15/using-a-ssh-jumphost.html">post
15 about SSH jumphosts,</a> I have another SSH feature to share with
16 you, which IMO isn't known or used enough.
17 </p>
18
19 <p>
20 Imagine you have some data on one host which gets regenerated every now
21 and then and you also need this data on other hosts too. There are
22 multiple ways to sync the data to other machines. You can
23 <ul>
24 <li>make them available via http/ftp and cron a wget run</li>
25 <li>use some rsync or ftp daemon on the target host(s) and write data to
26 them (brrrrr)</li>
27 <li>simply use limited SSH keys to signal the target host(s) when
28 there is something new to fetch</li>
29 </ul>
30 The problem of the first option is that you need to make the data
31 available via http/ftp, which needs an extra daemon to run. And then you
32 need to cron a script fetching it, which wastes resources if the data is
33 updated infrequently.
34 </p>
35
36 <p>
37 The problem of the second option is that you need some daemon available which
38 allows you to write to the host. Depending on what you chose that might
39 be with passwords transferred unencrypted. Or you aren't able to set it
40 up yourself, as you are not the admin of the machine.
41 </p>
42
43 <p>
44 So, lets take the third solution. Its safe to assume that SSH is
45 available on the hosts you login to (don't tell me you still use
46 telnet/rlogin on remote machines), so lets use SSH features. I assume
47 that usage of basic SSH public key authentication is known, if not you
48 first want to google for it and learn about that.
49 </p>
50
51 <p>
52 Using SSH keys to trigger actions on remote hosts is basically the same
53 as a login to the machine and manually running a command - except you
54 don't need to do it yourself, a script is doing it. Which leads to one
55 big difference for a "trigger" key compared to a "login" key: You <b>do not</b>
56 set a passphrase for that SSH key! As a consequence of that you use such
57 a key <b>only for exactly one</b> purpose, nothing else. Generate a new key for
58 another trigger. <b>Never, ever, use such a passphrase-less SSH key for normal
59 logins to other machines</b>...
60 </p>
61
62 <p>
63 Having generated a passphrase-less key on host a (let it have IP
64 1.2.3.4) we copy the .pub file over to the target host b and put it into
65 the authorized_keys file (usually in ~/.ssh/). The difference to normal
66 login keys is the large line of options we put in front of it:
67 </p>
68
69 <pre>
70 command="rsync --server -vlHogDtprz --delete --delete-after --ignore-errors . /org/backup/something",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,from="1.2.3.4" ssh-key-here
71 </pre>
72
73 <p>
74 or
75 </p>
76
77 <pre>
78 command="/var/mirror/ftpsync &",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,from="1.2.3.4" ssh-key-here
79 </pre>
80
81 <p>
82 Both commands allow to use the SSH key from host a with its IP 1.2.3.4
83 and will run the command thats defined here. No matter what command or
84 options are are specified on the commandline on host a, host b will only
85 do the above. There wont be any port, X11 or agent forwarding and due to
86 the forced command there also wont ever open a shell.
87 </p>
88
89 <p>
90 With the first command we trigger the remote hosts rsync to write the
91 data we send into that path, using the given options. Of course that
92 means we send data using rsync from our host. The SSH connection stays
93 available for the whole time the command runs.
94 </p>
95
96 <p>
97 The second command instead runs the given binary, a shell script in this
98 case, in background. As we also forbid tty allocation the SSH connection
99 is closed right after the script is started. To avoid DOSing the remote
100 machine such a script should have some kind of lockfile check and abort
101 if a second copy is already running.
102 </p>
103
104 <p>
105 SSH also allows to use such limited SSH keys for the root user, while
106 disallowing normal root logins: Change <i>PermitRootLogin</i> in sshd_config
107 from <i>no</i> to <i>forced-commands-only</i> and you wont be able to
108 login to the remote host as root but you can trigger actions that should
109 be run as root.
110 </p>
111
112 <p>
113 If you want to know what else you can do using options specified in the
114 authorized_keys file then read its man-page, it has some details how you
115 can use it to limit port forward requests, use more than just one IP in
116 the from= parameter, ...
117 </p>
118
119 <p>
120 Some users of the above way of automating tasks on remote machines are
121 <ul>
122 <li>The Debian mirror network. About all tier-1/2 mirrors are pushed
123 using the described technique, making updates to Debian available as
124 soon as possible.</li>
125
126 <p>
127 <li>da-backup, the Debian Admin Backup tool, used by Debian and
128 DebConf to backup their hosts to central backup servers.</li>
129
130 <p>
131 <li><a href="http://packages.debian.org/">packages.debian.org</a>
132 updates his data way faster than in the past, thanks to this.</li>
133
134 <p>
135 <li>Possibly many many more, its a useful feature.</li>
136 </ul>