diff options
Diffstat (limited to 'debian/README.Debian')
-rw-r--r-- | debian/README.Debian | 295 |
1 files changed, 295 insertions, 0 deletions
diff --git a/debian/README.Debian b/debian/README.Debian new file mode 100644 index 000000000..dbe6c2958 --- /dev/null +++ b/debian/README.Debian | |||
@@ -0,0 +1,295 @@ | |||
1 | OpenSSH for Debian | ||
2 | ------------------ | ||
3 | |||
4 | UPGRADE ISSUES | ||
5 | ============== | ||
6 | |||
7 | PermitRootLogin | ||
8 | --------------- | ||
9 | |||
10 | As of 1:6.6p1-1, new installations will be set to "PermitRootLogin | ||
11 | without-password" (or the synonymous "PermitRootLogin prohibit-password" as | ||
12 | of 1:7.1p1-1). This disables password authentication for root, foiling | ||
13 | password dictionary attacks on the root user. Some sites may wish to use | ||
14 | the stronger "PermitRootLogin forced-commands-only" or "PermitRootLogin no", | ||
15 | but note that "PermitRootLogin no" will break setups that SSH to root with a | ||
16 | forced command to take full-system backups. You can use PermitRootLogin in | ||
17 | a Match block if you want finer-grained control here. | ||
18 | |||
19 | For many years Debian's OpenSSH packaging used "PermitRootLogin yes", in | ||
20 | line with upstream. To avoid breaking local setups, this is still true for | ||
21 | installations upgraded from before 1:6.6p1-1. If you wish to change this, | ||
22 | you should edit /etc/ssh/sshd_config, change it manually, and run "service | ||
23 | ssh restart" as root. | ||
24 | |||
25 | Disabling PermitRootLogin means that an attacker possessing credentials for | ||
26 | the root account (any credentials in the case of "yes", or private key | ||
27 | material in the case of "prohibit-password") must compromise a normal user | ||
28 | account rather than being able to SSH directly to root. Be careful to avoid | ||
29 | a false illusion of security if you change this setting; any account you | ||
30 | escalate to root from should be considered equivalent to root for the | ||
31 | purposes of security against external attack. You might for example disable | ||
32 | it if you know you will only ever log in as root from the physical console. | ||
33 | |||
34 | Since the root account does not generally have non-password credentials | ||
35 | unless you explicitly install an SSH public key in its | ||
36 | ~/.ssh/authorized_keys, which you presumably only do if you want to SSH to | ||
37 | it, "prohibit-password" should be a reasonable default for most sites. | ||
38 | |||
39 | As of OpenSSH 7.0, this is the upstream default. | ||
40 | |||
41 | For further discussion, see: | ||
42 | |||
43 | https://bugs.debian.org/298138 | ||
44 | https://bugzilla.mindrot.org/show_bug.cgi?id=2164 | ||
45 | |||
46 | X11 Forwarding | ||
47 | -------------- | ||
48 | |||
49 | ssh's default for ForwardX11 has been changed to ``no'' because it has | ||
50 | been pointed out that logging into remote systems administered by | ||
51 | untrusted people is likely to open you up to X11 attacks, so you | ||
52 | should have to actively decide that you trust the remote machine's | ||
53 | root, before enabling X11. I strongly recommend that you do this on a | ||
54 | machine-by-machine basis, rather than just enabling it in the default | ||
55 | host settings. | ||
56 | |||
57 | In order for X11 forwarding to work, you need to install xauth on the | ||
58 | server. In Debian this is in the xbase-clients package. | ||
59 | |||
60 | As of OpenSSH 3.1, the remote $DISPLAY uses localhost by default to reduce | ||
61 | the security risks of X11 forwarding. Look up X11UseLocalhost in | ||
62 | sshd_config(8) if this is a problem. | ||
63 | |||
64 | OpenSSH 3.8 invented ForwardX11Trusted, which when set to no causes the | ||
65 | ssh client to create an untrusted X cookie so that attacks on the | ||
66 | forwarded X11 connection can't become attacks on X clients on the remote | ||
67 | machine. However, this has some problems in implementation - notably a | ||
68 | very short timeout of the untrusted cookie - breaks large numbers of | ||
69 | existing setups, and generally seems immature. The Debian package | ||
70 | therefore sets the default for this option to "yes" (in ssh itself, | ||
71 | rather than in ssh_config). | ||
72 | |||
73 | Fallback to RSH | ||
74 | --------------- | ||
75 | |||
76 | The default for this setting has been changed from Yes to No, for | ||
77 | security reasons, and to stop the delay attempting to rsh to machines | ||
78 | that don't offer the service. Simply switch it back on in either | ||
79 | /etc/ssh/ssh_config or ~/.ssh/config for those machines that you need | ||
80 | it for. | ||
81 | |||
82 | Setgid ssh-agent and environment variables | ||
83 | ------------------------------------------ | ||
84 | |||
85 | As of version 1:3.5p1-1, ssh-agent is installed setgid to prevent ptrace() | ||
86 | attacks retrieving private key material. This has the side-effect of causing | ||
87 | glibc to remove certain environment variables which might have security | ||
88 | implications for set-id programs, including LD_PRELOAD, LD_LIBRARY_PATH, and | ||
89 | TMPDIR. | ||
90 | |||
91 | If you need to set any of these environment variables, you will need to do | ||
92 | so in the program exec()ed by ssh-agent. This may involve creating a small | ||
93 | wrapper script. | ||
94 | |||
95 | Symlink Hostname invocation | ||
96 | --------------------------- | ||
97 | |||
98 | This version of ssh no longer includes support for invoking ssh with the | ||
99 | hostname as the name of the file run. People wanting this support should | ||
100 | use the ssh-argv0 script. | ||
101 | |||
102 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | ||
103 | |||
104 | OTHER ISSUES | ||
105 | ============ | ||
106 | |||
107 | Authorization Forwarding | ||
108 | ------------------------ | ||
109 | |||
110 | Similarly, root on a remote server could make use of your ssh-agent | ||
111 | (while you're logged into their machine) to obtain access to machines | ||
112 | which trust your keys. This feature is therefore disabled by default. | ||
113 | You should only re-enable it for those hosts (in your ~/.ssh/config or | ||
114 | /etc/ssh/ssh_config) where you are confident that the remote machine | ||
115 | is not a threat. | ||
116 | |||
117 | Problems logging in with RSA authentication | ||
118 | ------------------------------------------- | ||
119 | |||
120 | If you have trouble logging in with RSA authentication then the | ||
121 | problem is probably caused by the fact that you have your home | ||
122 | directory writable by group, as well as user (this is the default on | ||
123 | Debian systems). | ||
124 | |||
125 | Depending upon other settings on your system (i.e. other users being | ||
126 | in your group) this could open a security hole, so you will need to | ||
127 | make your home directory writable only by yourself. Run this command, | ||
128 | as yourself: | ||
129 | |||
130 | chmod g-w ~/ | ||
131 | |||
132 | to remove group write permissions. If you use ssh-copy-id to install your | ||
133 | keys, it does this for you. | ||
134 | |||
135 | -L option of ssh nonfree | ||
136 | ------------------------ | ||
137 | |||
138 | non-free ssh supported the usage of the option -L to use a non privileged | ||
139 | port for scp. This option will not be supported by scp from openssh. | ||
140 | |||
141 | Please use instead scp -o "UsePrivilegedPort=no" as documented in the | ||
142 | manpage to scp itself. | ||
143 | |||
144 | Problem logging in because of TCP-Wrappers | ||
145 | ------------------------------------------ | ||
146 | |||
147 | ssh is compiled with support for tcp-wrappers. So if you can no longer | ||
148 | log into your system, please check that /etc/hosts.allow and /etc/hosts.deny | ||
149 | are configured so that ssh is not blocked. | ||
150 | |||
151 | Kerberos support | ||
152 | ---------------- | ||
153 | |||
154 | ssh is now compiled with Kerberos support. Unfortunately, privilege | ||
155 | separation is incompatible with parts of Kerberos support for protocol 2; | ||
156 | you may need to run kinit after logging in. | ||
157 | |||
158 | Interoperability between scp and the ssh.com SSH server | ||
159 | ------------------------------------------------------- | ||
160 | |||
161 | In version 2 and greater of the commercial SSH server produced by SSH | ||
162 | Communications Security, scp was changed to use SFTP (SSH2's file transfer | ||
163 | protocol) instead of the traditional rcp-over-ssh, thereby breaking | ||
164 | compatibility. The OpenSSH developers regard this as a bug in the ssh.com | ||
165 | server, and do not currently intend to change OpenSSH's scp to match. | ||
166 | |||
167 | Workarounds for this problem are to install scp1 on the server (scp2 will | ||
168 | fall back to it), to use sftp, or to use some other transfer mechanism such | ||
169 | as rsync-over-ssh or tar-over-ssh. | ||
170 | |||
171 | Running sshd from inittab | ||
172 | ------------------------- | ||
173 | |||
174 | Some people find it useful to run the sshd server from inittab, to make sure | ||
175 | that it always stays running. To do this, stop sshd ('service ssh stop'), | ||
176 | add the following line to /etc/inittab, and run 'telinit q': | ||
177 | |||
178 | ss:2345:respawn:/usr/sbin/sshd -D | ||
179 | |||
180 | If you do this, note that you will need to stop sshd being started in the | ||
181 | normal way ('update-rc.d ssh disable') and that you will need to restart | ||
182 | this sshd manually on upgrades. | ||
183 | |||
184 | Per-connection sshd instances with systemd | ||
185 | ------------------------------------------ | ||
186 | |||
187 | If you want to reconfigure systemd to listen on port 22 itself and launch an | ||
188 | instance of sshd for each connection (inetd-style socket activation), then | ||
189 | you can run: | ||
190 | |||
191 | systemctl stop ssh.service | ||
192 | systemctl start ssh.socket | ||
193 | |||
194 | To make this permanent: | ||
195 | |||
196 | systemctl disable ssh.service | ||
197 | systemctl enable ssh.socket | ||
198 | |||
199 | This may be appropriate in environments where minimal footprint is critical | ||
200 | (e.g. cloud guests). Be aware that this bypasses MaxStartups, and systemd's | ||
201 | MaxConnections cannot quite replace this as it cannot distinguish between | ||
202 | authenticated and unauthenticated connections; see | ||
203 | https://bugzilla.redhat.com/show_bug.cgi?id=963268 for more discussion. | ||
204 | |||
205 | The provided ssh.socket unit file sets ListenStream=22. If you need to have | ||
206 | it listen on a different address or port, then you will need to do this as | ||
207 | follows (modifying ListenStream to match your requirements): | ||
208 | |||
209 | mkdir -p /etc/systemd/system/ssh.socket.d | ||
210 | cat >/etc/systemd/system/ssh.socket.d/listen.conf <<EOF | ||
211 | [Socket] | ||
212 | ListenStream=2222 | ||
213 | EOF | ||
214 | systemctl daemon-reload | ||
215 | |||
216 | See systemd.socket(5) for details. | ||
217 | |||
218 | Terminating SSH sessions cleanly on shutdown/reboot with systemd | ||
219 | ---------------------------------------------------------------- | ||
220 | |||
221 | If you have libpam-systemd >= 230 installed (following openssh-server's | ||
222 | Recommends) and "UsePAM yes" in sshd_config (the default configuration | ||
223 | shipped by this package), then SSH sessions will be terminated cleanly when | ||
224 | the server is shut down or rebooted. | ||
225 | |||
226 | If either of these conditions does not hold, then you may find that SSH | ||
227 | sessions hang silently when the server is shut down or rebooted. If you do | ||
228 | not want to use PAM or configure it properly for whatever reason, then you | ||
229 | can instead copy | ||
230 | /usr/share/doc/openssh-server/examples/ssh-session-cleanup.service to | ||
231 | /etc/systemd/system/ and run "systemctl enable ssh-session-cleanup.service". | ||
232 | |||
233 | Non-systemd users may find /usr/lib/openssh/ssh-session-cleanup helpful if | ||
234 | they have a similar problem, although at present there is no system | ||
235 | integration for this for anything other than systemd. | ||
236 | |||
237 | SSH protocol 1 server support removed | ||
238 | ------------------------------------- | ||
239 | |||
240 | sshd(8) no longer supports the old SSH protocol 1, so all the configuration | ||
241 | options related to it are now deprecated and should be removed from | ||
242 | /etc/ssh/sshd_config. These are: | ||
243 | |||
244 | KeyRegenerationInterval | ||
245 | RSAAuthentication | ||
246 | RhostsRSAAuthentication | ||
247 | ServerKeyBits | ||
248 | |||
249 | The Protocol option is also no longer needed, although it is silently | ||
250 | ignored rather than deprecated. | ||
251 | |||
252 | if-up hook removed | ||
253 | ------------------ | ||
254 | |||
255 | openssh-server previously shipped an if-up hook that restarted sshd when a | ||
256 | network interface came up. This generally caused more problems than it | ||
257 | solved: for instance, it means that sshd stops listening briefly while being | ||
258 | restarted, which can cause problems in some environments, particularly | ||
259 | automated tests. | ||
260 | |||
261 | The only known situation where the if-up hook was useful was when | ||
262 | sshd_config was changed to add ListenAddress entries for particular IP | ||
263 | addresses, overriding the default of listening on all addresses, and the | ||
264 | system is one that often roams between networks. In such a situation, it is | ||
265 | better to remove ListenAddress entries from sshd_config (restoring it to the | ||
266 | default behaviour) and instead use firewall rules to restrict incoming SSH | ||
267 | connections to only the desired interfaces or addresses. | ||
268 | |||
269 | For further discussion, see: | ||
270 | |||
271 | https://bugs.launchpad.net/bugs/1674330 | ||
272 | |||
273 | IPQoS defaults reverted to pre-7.8 values | ||
274 | ----------------------------------------- | ||
275 | |||
276 | OpenSSH 7.8 changed the default IPQoS settings to use DSCP AF21 for | ||
277 | interactive traffic and CS1 for bulk. This caused some problems with other | ||
278 | software ("iptables -m tos" and VMware), so Debian's OpenSSH reverts this | ||
279 | change for the time being. | ||
280 | |||
281 | This is *temporary*, and we expect to come back into sync with upstream | ||
282 | OpenSSH once those other issues have been fixed. If you want to restore the | ||
283 | upstream default, add this to ssh_config and sshd_config: | ||
284 | |||
285 | IPQoS af21 cs1 | ||
286 | |||
287 | For further discussion, see: | ||
288 | |||
289 | https://bugs.debian.org/923879 | ||
290 | https://bugs.debian.org/926229 | ||
291 | https://bugs.launchpad.net/1822370 | ||
292 | |||
293 | -- | ||
294 | Matthew Vernon <matthew@debian.org> | ||
295 | Colin Watson <cjwatson@debian.org> | ||