Age | Commit message (Collapse) | Author |
|
this version, check whether sysvinit is still managing sshd; if so,
manually stop it so that it can be restarted under upstart. We do this
near the end of the postinst, so it shouldn't result in any appreciable
extra window where sshd is not running during upgrade.
|
|
years ago, and everyone should have upgraded through a version that
applied these checks by now. The ssh-vulnkey tool and the blacklisting
support in sshd are still here, at least for the moment.
* This removes the last of our uses of debconf (closes: #221531).
|
|
https://wiki.ubuntu.com/UpstartCompatibleInitScripts: the init script
checks for a running Upstart, and we now let dh_installinit handle most
of the heavy lifting in maintainer scripts. Ubuntu users should be
essentially unaffected except that sshd may no longer start
automatically in chroots if the running Upstart predates 0.9.0; but the
main goal is simply not to break when openssh-server is installed in a
chroot.
|
|
being primary there.
|
|
|
|
installations or if you manually add 'HostKey
/etc/ssh/ssh_host_ecdsa_key' to /etc/ssh/sshd_config.
|
|
which is intentionally no longer shipped in the openssh-server package
due to /var/run often being a temporary directory, is not removed on
upgrade (closes: #575582).
|
|
textual changes in error output, it's only relevant for direct upgrades
from truly ancient versions, and it breaks upgrades if
/etc/ssh/ssh_host_key can't be loaded (closes: #579570).
|
|
introduced to match the behaviour of non-free SSH, in which -q does not
suppress fatal errors, but matching the behaviour of OpenSSH upstream is
much more important nowadays. We no longer document that -q does not
suppress fatal errors (closes: #280609). Migrate "LogLevel SILENT" to
"LogLevel QUIET" in sshd_config on upgrade.
|
|
/etc/ssh/sshd_config, and add UsePAM commentary from upstream-shipped
configuration file (closes: #415008, although unfortunately this will
only be conveniently visible on new installations).
|
|
|
|
|
|
are no longer particularly feasible anyway (closes: #420682).
|
|
|
|
- Add key blacklisting support. Keys listed in
/etc/ssh/blacklist.TYPE-LENGTH will be rejected for authentication by
sshd, unless "PermitBlacklistedKeys yes" is set in
/etc/ssh/sshd_config.
- Add a new program, ssh-vulnkey, which can be used to check keys
against these blacklists.
- Depend on openssh-blacklist.
- Force dependencies on libssl0.9.8 / libcrypto0.9.8-udeb to at least
0.9.8g-9.
- Automatically regenerate known-compromised host keys, with a
critical-priority debconf note. (I regret that there was no time to
gather translations.)
|
|
configurations (LP: #211400).
|
|
SSHD_PAM_SERVICE (closes: #255870).
|
|
|
|
|
|
(closes: #122188).
|
|
|
|
GSSAPICleanupCredentials. Mark GSSUseSessionCCache and
GSSAPIUseSessionCredCache as known-but-unsupported options, and migrate
away from them on upgrade.
|
|
any unchanged conffiles from the pre-split ssh package to work around a
bug in sarge's dpkg (thanks, Justin Pryzby and others; closes: #335276).
|
|
in sshd_config.
* Default client to attempting GSSAPI authentication.
* Remove obsolete GSSAPINoMICAuthentication from sshd_config if it's
found.
|
|
fail if the sshd user is not local (closes: #398436).
|
|
|
|
Introduces dependency on passwd for usermod.
|
|
(closes: #349896).
|
|
|
|
At least when X11UseLocalhost is turned on, which is the default, the
security risks of using X11 forwarding are risks to the client, not to
the server (closes: #320104).
|
|
/etc/ssh/ssh_host_key itself (closes: #312312).
|
|
|
|
/usr/share/doc/openssh-client.
|
|
- Added SELinux capability, and turned it on be default. Added
restorecon calls in preinst and postinst (should not matter if the
machine is not SELinux aware). By and large, the changes made should
have no effect unless the rules file calls --with-selinux; and even
then there should be no performance hit for machines not actively
running SELinux.
- Modified the preinst and postinst to call restorecon to set the
security context for the generated public key files.
- Added a comment to /etc/pam.d/ssh to indicate that an SELinux system
may want to also include pam_selinux.so.
|
|
has not been the default since openssh 1:3.0.1p1-1. Users who need this
should edit sshd_config instead (closes: #147212).
|
|
(closes: #141979).
|
|
configuration files to match (closes: #87900, #151321).
|
|
PasswordAuthentication by default, since it now supports PAM and apparently
works better with a non-threaded sshd.
|
|
installs (closes: #289573).
|
|
accept them to the server by default in new installs, although not on
upgrade (closes: #264024).
|
|
* Preserve /etc/ssh/sshd_config ownership/permissions (closes: #276754).
* Shorten the version string from the form "OpenSSH_3.8.1p1 Debian
1:3.8.1p1-8.sarge.1" to "OpenSSH_3.8.1p1 Debian-8.sarge.1", as some SSH
implementations apparently have problems with the long version string.
This is of course a bug in those implementations, but since the extent
of the problem is unknown it's best to play safe (closes: #275731).
* debconf template translations:
- Add Finnish (thanks, Matti Pöllä; closes: #265339).
- Update Danish (thanks, Morten Brix Pedersen; closes: #275895).
- Update French (thanks, Denis Barbier; closes: #276703).
- Update Japanese (thanks, Kenshi Muto; closes: #277438).
|
|
* If PasswordAuthentication is disabled, then offer to disable
ChallengeResponseAuthentication too. The current PAM code will attempt
password-style authentication if ChallengeResponseAuthentication is
enabled (closes: #250369).
* This will ask a question of anyone who installed fresh with 1:3.8p1-2 or
later and then upgraded. Sorry about that ... for this reason, the
default answer is to leave ChallengeResponseAuthentication enabled.
|
|
happens even though we don't know what version we're upgrading from.
|
|
(closes: #39741). openssh-server depends on openssh-client for some
common functionality; it didn't seem worth creating yet another package
for this.
* New transitional ssh package, depending on openssh-client and
openssh-server. May be removed once nothing depends on it.
* When upgrading from ssh to openssh-{client,server}, it's very difficult
for the maintainer scripts to find out what version we're upgrading from
without dodgy dpkg hackery. I've therefore taken the opportunity to move
a couple of debconf notes into NEWS files, namely ssh/ssh2_keys_merged
and ssh/user_environment_tell.
* In general, upgrading to this version directly from woody without first
upgrading to the version in sarge is not currently guaranteed to work
very smoothly due to the aforementioned version discovery problems.
|