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