1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
OpenSSH for Debian
------------------
Although this package is widely referred to as OpenSSH, it is actually
a branch of an early version of ssh which has been tidied up by the
OpenBSD folks.
It has been decided that this version should have the privilege of
carrying the ``ssh'' name in Debian, since it is the only version of
ssh that is going to make it into Debian proper, being the only one
that complies with the Debian Free Software Guidelines.
If you were expecting to get the non-free version of ssh (1.2.27 or
whatever) when you installed this package, then you're out of luck, as
Debian don't ship it.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Privilege Separation
--------------------
As of 3.3, openssh has employed privilege separation to reduce the
quantity of code that runs as root, thereby reducing the impact of
some security holes in sshd.
Unfortunately, privilege separation interacts badly with PAM. Any PAM
session modules that need to run as root (pam_mkhomedir, for example)
will fail, and PAM keyboard-interactive authentication won't work.
Privilege separation is turned on by default, so if you decide you
want it turned off, you need to add "UsePrivilegeSeparation no" to
/etc/ssh/sshd_config
NB! If you are running a 2.0 series Linux kernel, then privilege
separation will not work at all, and your sshd will fail to start
unless you explicity turn privilege separation off.
PermitRootLogin set to yes
--------------------------
This is now the default setting (in line with upstream), and people
who asked for an automatically-generated configuration file when
upgrading from potato (or on a new install) will have this setting in
their /etc/ssh/sshd_config file.
Should you wish to change this setting, edit /etc/ssh/sshd_config, and
change:
PermitRootLogin yes
to:
PermitRootLogin no
Having PermitRootLogin set to yes means that an attacker that knows
the root password can ssh in directly (without having to go via a user
account). If you set it to no, then they must compromise a normal user
account. In the vast majority of cases, this does not give added
security; remember that any account you su to root from is equivalent
to root - compromising this account gives an attacker access to root
easily. If you only ever log in as root from the physical console,
then you probably want to set this value to no.
As an aside, PermitRootLogin can also be set to "without-password" or
"forced-commands-only" - see sshd(8) for more details.
DO NOT FILE BUG REPORTS SAYING YOU THINK THIS DEFAULT IS INCORRECT!
The argument above is somewhat condensed; I have had this discussion
at great length with many people. If you think the default is
incorrect, and feel strongly enough to want to argue with me about it,
then send me email to matthew@debian.org. I will close bug reports
claiming the default is incorrect.
SSH now uses protocol 2 by default
----------------------------------
This means all your keyfiles you used for protocol version 1 need to
be re-generated. The server keys are done automatically, but for RSA
authentication, please read the ssh-keygen manpage.
If you have an automatically generated configuration file, and decide
at a later stage that you do want to support protocol version 1 (not
recommended, but note that the ssh client shipped with Debian potato
only supported protocol version 1), then you need to do the following:
Change /etc/ssh/sshd_config such that:
Protocol 2
becomes:
Protocol 2,1
Also add the line:
HostKey /etc/ssh/ssh_host_key
(you may need to generate a host key if you do not already have one)
/usr/bin/ssh not SUID:
----------------------
If you have not installed debconf, you'll have missed the chance to
install ssh SUID, which means you won't be able to do Rhosts
authentication. If that upsets you, use:
dpkg-statoverride
or if that's also missing, use this:
chown root.root /usr/bin/ssh
chmod 04755 /usr/bin/ssh
X11 Forwarding:
---------------
ssh's default for ForwardX11 has been changed to ``no'' because it has
been pointed out that logging into remote systems administered by
untrusted people is likely to open you up to X11 attacks, so you
should have to actively decide that you trust the remote machine's
root, before enabling X11. I strongly recommend that you do this on a
machine-by-machine basis, rather than just enabling it in the default
host settings.
In order for X11 forwarding to work, you need to install xauth on the
server. In Debian this is in the xbase-clients package.
Authorization Forwarding:
-------------------------
Similarly, root on a remote server could make use of your ssh-agent
(while you're logged into their machine) to obtain access to machines
which trust your keys. This feature is therefore disabled by default.
You should only re-enable it for those hosts (in your ~/.ssh/config or
/etc/ssh/ssh_config) where you are confident that the remote machine
is not a threat.
Fallback to RSH:
----------------
The default for this setting has been changed from Yes to No, for
security reasons, and to stop the delay attempting to rsh to machines
that don't offer the service. Simply switch it back on in either
/etc/ssh/ssh_config or ~/.ssh/config for those machines that you need
it for.
Problems logging in with RSA authentication:
--------------------------------------------
If you have trouble logging in with RSA authentication then the
problem is probably caused by the fact that you have your home
directory writable by group, as well as user (this is the default on
Debian systems).
Depending upon other settings on your system (i.e. other users being
in your group) this could open a security hole, so you will need to
make your home directory writable only by yourself. Run this command,
as yourself:
chmod g-w ~/
to remove group write permissions. If you use ssh-copy-id to install your
keys, it does this for you.
-L option of ssh nonfree:
-------------------------
non-free ssh supported the usage of the option -L to use a non privileged
port for scp. This option will not be supported by scp from openssh.
Please use instead scp -o "UsePrivilegedPort=no" as documented in the
manpage to scp itself.
Problem logging in because of TCP-Wrappers:
-------------------------------------------
ssh is compiled with support for tcp-wrappers. So if you can no longer
log into your system, please check that /etc/hosts.allow and /etc/hosts.deny
are configured so that ssh is not blocked.
Kerberos Authentication:
------------------------
ssh is compiled without support for kerberos authentication, and there are
no current plans to support this. Thus the KerberosAuthentication and
KerberosTgtPassing options will not be recognised.
--
Matthew Vernon
<matthew@debian.org>
|
