os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Regen from errata/article.sgml 1.1.2.50.

Browse source
This commit is contained in:
Bruce A. Mah 2002-02-06 17:27:24 +00:00
parent 140a3fe4e9
commit 1289a4d7b8
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=12105
1 changed files with 60 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

70
en/releases/4.5R/errata.html
View file

@ -22,7 +22,7 @@
<p class="PUBDATE">$FreeBSD:
src/release/doc/en_US.ISO8859-1/errata/article.sgml,v
1.1.2.48 2002/02/05 18:59:23 bmah Exp $<br>
1.1.2.50 2002/02/06 17:04:41 bmah Exp $<br>
</p>
<hr>
</div>
@ -83,13 +83,29 @@
<h1 class="SECT1"><a name="AEN25">2 Security
Advisories</a></h1>
<p>No active security advisories.</p>
<p>A race condition existed whereby a file could be removed
between a <a href=
"http://www.FreeBSD.org/cgi/man.cgi?query=fstatfs&sektion=2&manpath=FreeBSD+4.5-stable">
<span class="CITEREFENTRY"><span class=
"REFENTRYTITLE">fstatfs</span>(2)</span></a> call and the
point where the file is accessed, causing a kernel panic.
Only the <a href=
"http://www.FreeBSD.org/cgi/man.cgi?query=procfs&sektion=5&manpath=FreeBSD+4.5-stable">
<span class="CITEREFENTRY"><span class=
"REFENTRYTITLE">procfs</span>(5)</span></a> filesystem was
known to be vulnerable to this attack. This bug was fixed
in FreeBSD 4.5-RELEASE, but the security advisory
describing the bug was issued after the release. For more
information, including a workaround and bug fix, see
security advisory <a href=
"ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:09.fstatfs.asc"
target="_top">FreeBSD-SA-02:09</a>.</p>
</div>
<div class="SECT1">
<hr>
<h1 class="SECT1"><a name="AEN28">3 System Update
<h1 class="SECT1"><a name="AEN35">3 System Update
Information</a></h1>
<p>Certain SSH clients, when attempting to connect to a
@ -98,13 +114,47 @@
"http://www.FreeBSD.org/cgi/man.cgi?query=sshd&sektion=8&manpath=FreeBSD+4.5-stable">
<span class="CITEREFENTRY"><span class=
"REFENTRYTITLE">sshd</span>(8)</span></a> on the server has
not been configured for <b class="APPLICATION">S/Key</b>
authentication. As a workaround, uncomment the <tt class=
"LITERAL">ChallengeResponseAuthentication no</tt> line in
<tt class="FILENAME">/etc/ssh/sshd_config</tt> (on the
server host). This behavior has been observed with the <b
class="APPLICATION">OpenSSH</b> 3.0.1 and 3.0.2 clients, as
well as with PuTTY.</p>
not been later explicitly configured for <b class=
"APPLICATION">S/Key</b> authentication. This is due to the
default settings of clients having changed (e.g. use of SSH
protocol version 2 where it was not used before), or from a
change from the client's old default authentication
sequence. There are a number of ways to disable this
behavior:</p>
<ul>
<li>
<p>On newer <b class="APPLICATION">OpenSSH</b> clients,
add the following line to your <tt class=
"FILENAME">~/.ssh/config</tt> file:</p>
<pre class="PROGRAMLISTING">
PreferredAuthentications publickey,password,keyboard-interactive
</pre>
<br>
<br>
</li>
<li>
<p>For <b class="APPLICATION">PuTTY</b> clients, the
authentication sequence order cannot be changed, but
keyboard-interactive authentication can be disabled in
the settings.</p>
</li>
<li>
<p>To disable keyboard-interactive authentication in
the server, uncomment the following line in the <tt
class="FILENAME">/etc/ssh/sshd_config</tt> file (on the
server host):</p>
<pre class="PROGRAMLISTING">
ChallengeResponseAuthentication no
</pre>
<br>
<br>
</li>
</ul>
<br>
<br>
<p>The release notes mentioned the new sbni device driver,
but gave an incorrect reference to the program in the