o Because of export controls, TELNET ENCRYPT option is not supported outside
of the United States and Canada.
o Because of export controls, data encryption
is not supported outside of the United States and Canada.
src/crypto/README revision 1.5 commit log says:
> Crypto sources are no longer export controlled:
> Explain, why crypto sources are still in crypto/.
and actually telnet encryption is used outside of US and Canada now.
Pointed out by: OHSAWA Chitoshi <ohsawa@catv1.ccn-net.ne.jp>
Reviewed by: no objection on doc
to do what they are supposed to: under some circumstances output data would
be truncated, or the buffer would not actually be flushed (possibly leading
to overflows when the caller assumes the operation succeeded). Change the
semantics so that these functions ensure they complete the operation before
returning.
Comment out diagnostic code enabled by '-D reports' which causes an
infinite recursion and an eventual crash.
Patch developed with assistance from ru and assar.
o Fixed `nfrontp' calculations in output_data(). If `remaining' is
initially zero, it was possible for `nfrontp' to be decremented.
Noticed by: dillon
o Replaced leaking writenet() with output_datalen():
: * writenet
: *
: * Just a handy little function to write a bit of raw data to the net.
: * It will force a transmit of the buffer if necessary
: *
: * arguments
: * ptr - A pointer to a character string to write
: * len - How many bytes to write
: */
: void
: writenet(ptr, len)
: register unsigned char *ptr;
: register int len;
: {
: /* flush buffer if no room for new data) */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: if ((&netobuf[BUFSIZ] - nfrontp) < len) {
: /* if this fails, don't worry, buffer is a little big */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: netflush();
: }
:
: memmove(nfrontp, ptr, len);
: nfrontp += len;
:
: } /* end of writenet */
What an irony! :-)
o Optimized output_datalen() a bit.
authentication is enabled, the client effectively ignores any error
from krb5_rd_rep due to a missing branch.
In theory this could result in an ssh client using Kerberos 5
authentication accepting a spoofed AP-REP. I doubt this is a real
possiblity, however, because the AP-REP is passed from the server to
the client via the SSH encrypted channel. Any tampering should cause
the decryption or MAC to fail.
Approved by: green
MFC after: 1 week
non-crypto version)
Also update the crypto telnet's man page to reflect other options
ported from the non-crypto version.
Obtained from: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
references global variables from telnetd, but is also linked into
telnet as well. I was tempted to back out the last sra.c change
as it is 100% bogus and should be taken out and shot, but for now
this bandaid should get world working again. :-(
that were never registered. At the same time handle a failure from
pam_setcreds with a bit more paranioa than the previous fix.
Sync a bit with the "Portable OpenSSH" work to make comparisons a easier.
anyone to easily change the part of the OpenSSH version after the main
version number. The FreeBSD-specific version banner could be disabled
that way, for example:
# Call ourselves plain OpenSSH
VersionAddendum
now the default, so ignore the arguments that turn it on. Add a new -y
argument to turn off encryption in case someone wants to do that. Sync
these changes with the man page (including removing the now obsolete
statement about availability only in the US and Canada).
"non-echoed" characters are still echoed back in a null packet, as well
as pad passwords sent to not give hints to the length otherwise.
Obtained from: OpenBSD
This file is already off the vendorbranch, nonetheless it needs to be
submitted back to the OpenSSH people.
PR: 25743
Submitted by: David Wolfskill <dhw@whistle.com>
It is done by using the same ssh messages for v4 and v5 authentication
(since the ssh.com does not now anything about v4) and looking at the
contents after unpacking it to see if it is v4 or v5.
Based on code from Björn Grönvall <bg@sics.se>
PR: misc/20504
(instead of just mitigating through connection limits) the Bleichenbacher
attack which can lead to guessing of the server key (not host key) by
regenerating it when an RSA failure is detected.
Reviewed by: rwatson
