This reverts commit 277080fea0.
I had tested the server on my physical machine before pushing,
but the openssh test got broken so something is clearly wrong.
http://hydra.nixos.org/build/45500080
The two removed patches were for issues that should've been fixed.
Minor vulnerabilities addressed: CVE-2016-{10009,10010,10011,10012}.
https://www.openssh.com/txt/release-7.4
(This is a rewritten version of the reverted commit
a927709a35, that disables the creation of
/var/empty during build so that sandboxed builds also works. For more
context, see https://github.com/NixOS/nixpkgs/pull/16966)
If running NixOS inside a container where the host's root-owned files
and directories have been mapped to some other uid (like nobody), the
ssh daemon fails to start, producing this error message:
fatal: /nix/store/...-openssh-7.2p2/empty must be owned by root and not group or world-writable.
The reason for this is that when openssh is built, we explicitly set
`--with-privsep-path=$out/empty`. This commit removes that flag which
causes the default directory /var/empty to be used instead. Since NixOS'
activation script correctly sets up that directory, the ssh daemon now
also works within containers that have a non-root-owned nix store.
If running NixOS inside a container where the host's root-owned files
and directories have been mapped to some other uid (like nobody), the
ssh daemon fails to start, producing this error message:
fatal: /nix/store/...-openssh-7.2p2/empty must be owned by root and not group or world-writable.
The reason for this is that when openssh is built, we explicitly set
`--with-privsep-path=$out/empty`. This commit removes that flag which
causes the default directory /var/empty to be used instead. Since NixOS'
activation script correctly sets up that directory, the ssh daemon now
also works within containers that have a non-root-owned nix store.
The GSSAPI patch is useful but maintained by Debian, not upstream, and
can be slow to update. To avoid breaking openssh_with_kerberos when
the openssh version is bumped but the GSSAPI patch has not been updated,
don't enable the GSSAPI patch implicitly but require it to be explicitly
enabled.
The following parameters are now available:
* hardeningDisable
To disable specific hardening flags
* hardeningEnable
To enable specific hardening flags
Only the cc-wrapper supports this right now, but these may be reused by
other wrappers, builders or setup hooks.
cc-wrapper supports the following flags:
* fortify
* stackprotector
* pie (disabled by default)
* pic
* strictoverflow
* format
* relro
* bindnow
This patch is borrowed verbatim from Debian, where it is actively
maintained for each openssh update. It's also included in Fedora's
openssh package, in Arch linux as openssh-gssapi in the AUR, in MacOS
X, and presumably various other platforms and linux distros.
The main relevant parts of this patch:
- Adds several ssh_config options:
GSSAPIKeyExchange, GSSAPITrustDNS,
GSSAPIClientIdentity, GSSAPIServerIdentity
GSSAPIRenewalForcesRekey
- Optionally use an in-memory credentials cache api for security
My primary motivation for wanting the patch is the GSSAPIKeyExchange
and GSSAPITrustDNS features. My user ssh_config is shared across
several OSes, and it's a lot easier to manage if they all support the
same options.
The configure script tries to probe whether /var/run exists when
determining the location for the pid file, which is not very nice when
doing chroot builds. Just set it explicitly to avoid the problem.
For reference, the culprit in configure.ac:
````
piddir=/var/run
if test ! -d $piddir ; then
piddir=`eval echo ${sysconfdir}`
case $piddir in
NONE/*) piddir=`echo $piddir | sed "s~NONE~$ac_default_prefix~"` ;;
esac
fi
AC_ARG_WITH([pid-dir],
[ --with-pid-dir=PATH Specify location of ssh.pid file],
...
````
Also, use the `install-nokeys` target in installPhase so we avoid
installing useless host keys into $out/etc/ssh and improve built purity
as well.
This reverts commit a8eb2a6a81. OpenSSH
7.0 is causing too many interoperability problems so soon before the
15.08 release.
For instance, it causes NixOps EC2 initial deployments to fail with
"REMOTE HOST IDENTIFICATION HAS CHANGED". This is because the client
knows the server's ssh-dss host key, but this key is no longer
accepted by default. Setting "HostKeyAlgorithms" to "+ssh-dss" does
not work because it causes ssh-dss to be ordered after
"ecdsa-sha2-nistp521", which the server also offers. (Normally, ssh
prioritizes host key algorithms for which the client has a known host
key, but not if you set HostKeyAlgorithms.)
