Previously, there were two copies of telnet; a non-crypto version
that lived in the usual places, and a crypto version that lived in
crypto/telnet/. The latter was built in a broken manner somewhat akin
to other "contribified" sources. This meant that there were 4 telnets
competing with each other at build time - KerberosIV, Kerberos5,
plain-old-secure and base. KerberosIV is no longer in the running, but
the other three took it in turns to jump all over each other during a
"make buildworld".
As the crypto issue has been clarified, and crypto _calls_ are not
a problem, crypto/telnet has been repo-copied to contrib/telnet,
and with this commit, all telnets are now "contribified". The contrib
path was chosen to not destroy history in the repository, and differs
from other contrib/ entries in that it may be worked on as "normal"
BSD code. There is no dangerous crypto in these sources, only a
very weak system less strong than enigma(1).
Kerberos5 telnet and Secure telnet are now selected by using the usual
macros in /etc/make.conf, and the build process is unsurprising and
less treacherous.
etc.) from the application namespace for programs that use pam_ssh(8).
Use #defines to avoid changing the actual source code.
Approved by: re (rwatson)
of conflicting with other, similarly named functions in static
libraries. This is done mostly by renaming the var if it is shared
amongst modules, or making it static otherwise.
OK'ed by: re(scottl)
not respond to challenge, and later successfully authenticated itself
using another method, the kbdint context would never be released,
leaving the PAM child process behind even after the connection ended.
Fix this by automatically releasing the kbdint context if a packet of
type SSH_CMSG_AUTH_TIS is follwed by anything but a packet of type
SSH_CMSG_AUTH_TIS_RESPONSE.
MFC after: 1 week
returns PAM_CONV_ERR; moreover, make sure we always have the right
conversation function installed before calling PAM service functions.
Also unwrap some not-so-long lines.
MFC after: 3 days
pam_conv argument is NULL. OpenPAM doesn't care, but to make things
easier for people porting this code to other systems (or -STABLE), use
a dummy struct pam_conv instead of NULL.
Pointed out by: Damien Miller <djm@mindrot.org>
- The PAM kbdint device sometimes doesn't know authentication succeeded
until you re-query it. The ssh1 kbdint code would never re-query the
device, so authentication would always fail. This patch has been
submitted to the OpenSSH developers.
- The monitor code for PAM sometimes forgot to tell the monitor that
authentication had succeeded. This caused the monitor to veto the
privsep child's decision to allow the connection.
These patches have been tested with OpenSSH clients on -STABLE, NetBSD and
Linux, and with ssh.com's ssh1 on Solaris.
Sponsored by: DARPA, NAI Labs
When libdes was replaced with OpenSSL's libcrypto, there were a few
interfaces that the former implemented but the latter did not. Because
some software in the base system still depended upon these interfaces,
we simply included them in our libcrypto (rnd_keys.c).
Now, finally get around to removing the dependencies on these
interfaces. There were basically two cases:
des_new_random_key -- This is just a wrapper for des_random_key, and
these calls were replaced.
des_init_random_number_generator et. al. -- A few functions were used
by the application to seed libdes's PRNG. These are not necessary
when using libcrypto, as OpenSSL internally seeds the PRNG from
/dev/random. These calls were simply removed.
Again, some of the Kerberos 4 files have been taken off the vendor
branch. I do not expect there to be future imports of KTH Kerberos 4.
des_read_pw_string to break (and thus rather mysteriously
breaking utilities such as kinit).
= Enable the BSD /dev/crypto interface.
(These changes are being imported on the vendor branch, as they have
already been accepted and committed to the OpenSSL CVS repository.)
two basic changes (both of which should be no-ops until OpenSSL 0.9.7
is imported):
= Define OPENSSL_DES_LIBDES_COMPATIBILITY wherever we include
openssl/des.h.
= Spell `struct des_ks_struct []' using the existing
`des_key_schedule' typedef.
When OpenSSL 0.9.7 is imported, `des_key_schedule' (among other
things) will be a macro invocation instead of a typedef, and things
should `just work'.
Yes, this commit does take several files off the vendor branch.
I do not expect there to be future imports of KTH Kerberos 4.
This is particularly important for OpenSSL 0.9.7, as `des_read_pw_string'
is a macro there. (This fix brought in on the vendor branch, because I
already committed it to Heimdal's CVS.)
initialized after the call to pthread_create() instead of before. It just
happened to work with threads enabled because ctxt is shared, but of
course it doesn't work when we use a child process instead of threads.
Reimplement the necessary bits from auth_pam.c and auth2_pam.c so that
they share the PAM context used by the keyboard-interactive thread. If
a child process is used instead, they will (necessarily) use a separate
context.
Constify do_pam_account() and do_pam_session().
Sponsored by: DARPA, NAI Labs
passwords, even when the operation actually succeeded.
% k5passwd
luser@REA.LM's Password: **************
New password: **************
Verifying password - New password: **************
k5passwd: krb5_change_password: unable to reach any changepw server in realm REA.LM
[In reality, the password was changed.]
Obtained from: Heimdal CVS
"Could you do me a favor and fix sys_bsd.c to get the howmany() macro
from <sys/param.h>, instead of <sys/types.h>? This will save me from
having to worry about the unsync'd bits before making the change."
Requested by: mike
and did copy it as long as just size of struct sockaddr. So,
If connection is via IPv6, sshd didn't log hostname into utmp
correctly.
This problem occured only under FreeBSD because of our hack.
However, this is potential problem of OpenSSH-portable, and
they agreed to fix this.
Though, there is no fixed version of OpenSSH-portable available
yet, since this problem is serious for IPv6 users, I commit the
fix.
Reported by: many people
Reviewed by: current@ and stable@ (no objection)
MFC after: 3 days
