summaryrefslogtreecommitdiff
path: root/debian/README.Debian
diff options
context:
space:
mode:
Diffstat (limited to 'debian/README.Debian')
-rw-r--r--debian/README.Debian227
1 files changed, 227 insertions, 0 deletions
diff --git a/debian/README.Debian b/debian/README.Debian
new file mode 100644
index 000000000..6e6bf9dc8
--- /dev/null
+++ b/debian/README.Debian
@@ -0,0 +1,227 @@
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 set to yes
19--------------------------
20
21This is now the default setting (in line with upstream), and people
22who asked for an automatically-generated configuration file when
23upgrading from potato (or on a new install) will have this setting in
24their /etc/ssh/sshd_config file.
25
26Should you wish to change this setting, edit /etc/ssh/sshd_config, and
27change:
28PermitRootLogin yes
29to:
30PermitRootLogin no
31
32Having PermitRootLogin set to yes means that an attacker that knows
33the root password can ssh in directly (without having to go via a user
34account). If you set it to no, then they must compromise a normal user
35account. In the vast majority of cases, this does not give added
36security; remember that any account you su to root from is equivalent
37to root - compromising this account gives an attacker access to root
38easily. If you only ever log in as root from the physical console,
39then you probably want to set this value to no.
40
41As an aside, PermitRootLogin can also be set to "without-password" or
42"forced-commands-only" - see sshd(8) for more details.
43
44DO NOT FILE BUG REPORTS SAYING YOU THINK THIS DEFAULT IS INCORRECT!
45
46The argument above is somewhat condensed; I have had this discussion
47at great length with many people. If you think the default is
48incorrect, and feel strongly enough to want to argue about it, then
49send email to debian-ssh@lists.debian.org. I will close bug reports
50claiming the default is incorrect.
51
52X11 Forwarding
53--------------
54
55ssh's default for ForwardX11 has been changed to ``no'' because it has
56been pointed out that logging into remote systems administered by
57untrusted people is likely to open you up to X11 attacks, so you
58should have to actively decide that you trust the remote machine's
59root, before enabling X11. I strongly recommend that you do this on a
60machine-by-machine basis, rather than just enabling it in the default
61host settings.
62
63In order for X11 forwarding to work, you need to install xauth on the
64server. In Debian this is in the xbase-clients package.
65
66As of OpenSSH 3.1, the remote $DISPLAY uses localhost by default to reduce
67the security risks of X11 forwarding. Look up X11UseLocalhost in
68sshd_config(8) if this is a problem.
69
70OpenSSH 3.8 invented ForwardX11Trusted, which when set to no causes the
71ssh client to create an untrusted X cookie so that attacks on the
72forwarded X11 connection can't become attacks on X clients on the remote
73machine. However, this has some problems in implementation - notably a
74very short timeout of the untrusted cookie - breaks large numbers of
75existing setups, and generally seems immature. The Debian package
76therefore sets the default for this option to "yes" (in ssh itself,
77rather than in ssh_config).
78
79Fallback to RSH
80---------------
81
82The default for this setting has been changed from Yes to No, for
83security reasons, and to stop the delay attempting to rsh to machines
84that don't offer the service. Simply switch it back on in either
85/etc/ssh/ssh_config or ~/.ssh/config for those machines that you need
86it for.
87
88Setgid ssh-agent and environment variables
89------------------------------------------
90
91As of version 1:3.5p1-1, ssh-agent is installed setgid to prevent ptrace()
92attacks retrieving private key material. This has the side-effect of causing
93glibc to remove certain environment variables which might have security
94implications for set-id programs, including LD_PRELOAD, LD_LIBRARY_PATH, and
95TMPDIR.
96
97If you need to set any of these environment variables, you will need to do
98so in the program exec()ed by ssh-agent. This may involve creating a small
99wrapper script.
100
101Symlink Hostname invocation
102---------------------------
103
104This version of ssh no longer includes support for invoking ssh with the
105hostname as the name of the file run. People wanting this support should
106use the ssh-argv0 script.
107
108=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
109
110OTHER ISSUES
111============
112
113/usr/bin/ssh not SUID
114---------------------
115
116Due to Debian bug #164325, RhostsRSAAuthentication can only be used if ssh
117is SUID. Until this is fixed, if that is a problem, use:
118
119 dpkg-statoverride
120
121or if that's also missing, use this:
122
123 chown root.root /usr/bin/ssh
124 chmod 04755 /usr/bin/ssh
125
126Authorization Forwarding
127------------------------
128
129Similarly, root on a remote server could make use of your ssh-agent
130(while you're logged into their machine) to obtain access to machines
131which trust your keys. This feature is therefore disabled by default.
132You should only re-enable it for those hosts (in your ~/.ssh/config or
133/etc/ssh/ssh_config) where you are confident that the remote machine
134is not a threat.
135
136Problems logging in with RSA authentication
137-------------------------------------------
138
139If you have trouble logging in with RSA authentication then the
140problem is probably caused by the fact that you have your home
141directory writable by group, as well as user (this is the default on
142Debian systems).
143
144Depending upon other settings on your system (i.e. other users being
145in your group) this could open a security hole, so you will need to
146make your home directory writable only by yourself. Run this command,
147as yourself:
148
149 chmod g-w ~/
150
151to remove group write permissions. If you use ssh-copy-id to install your
152keys, it does this for you.
153
154-L option of ssh nonfree
155------------------------
156
157non-free ssh supported the usage of the option -L to use a non privileged
158port for scp. This option will not be supported by scp from openssh.
159
160Please use instead scp -o "UsePrivilegedPort=no" as documented in the
161manpage to scp itself.
162
163Problem logging in because of TCP-Wrappers
164------------------------------------------
165
166ssh is compiled with support for tcp-wrappers. So if you can no longer
167log into your system, please check that /etc/hosts.allow and /etc/hosts.deny
168are configured so that ssh is not blocked.
169
170Kerberos support
171----------------
172
173ssh is now compiled with Kerberos support. Unfortunately, privilege
174separation is incompatible with Kerberos support for SSH protocol 1 and
175parts of the support for protocol 2; you may need to run kinit after logging
176in.
177
178Interoperability between scp and the ssh.com SSH server
179-------------------------------------------------------
180
181In version 2 and greater of the commercial SSH server produced by SSH
182Communications Security, scp was changed to use SFTP (SSH2's file transfer
183protocol) instead of the traditional rcp-over-ssh, thereby breaking
184compatibility. The OpenSSH developers regard this as a bug in the ssh.com
185server, and do not currently intend to change OpenSSH's scp to match.
186
187Workarounds for this problem are to install scp1 on the server (scp2 will
188fall back to it), to use sftp, or to use some other transfer mechanism such
189as rsync-over-ssh or tar-over-ssh.
190
191Running sshd from inittab
192-------------------------
193
194Some people find it useful to run the sshd server from inittab, to make sure
195that it always stays running. To do this, stop sshd ('/etc/init.d/ssh
196stop'), add the following line to /etc/inittab, and run 'telinit q':
197
198 ss:2345:respawn:/usr/sbin/sshd -D
199
200If you do this, note that you will need to stop sshd being started in the
201normal way ('update-rc.d ssh disable') and that you will need to restart
202this sshd manually on upgrades.
203
204Per-connection sshd instances with systemd
205------------------------------------------
206
207If you want to reconfigure systemd to listen on port 22 itself and launch an
208instance of sshd for each connection (inetd-style socket activation), then
209you can run:
210
211 systemctl stop ssh.service
212 systemctl start ssh.socket
213
214To make this permanent:
215
216 systemctl disable ssh.service
217 systemctl enable ssh.socket
218
219This may be appropriate in environments where minimal footprint is critical
220(e.g. cloud guests). Be aware that this bypasses MaxStartups, and systemd's
221MaxConnections cannot quite replace this as it cannot distinguish between
222authenticated and unauthenticated connections; see
223https://bugzilla.redhat.com/show_bug.cgi?id=963268 for more discussion.
224
225--
226Matthew Vernon <matthew@debian.org>
227Colin Watson <cjwatson@debian.org>