Add a new type, inheriting 'types.str' but checking whether the value
doesn't contain any newline characters.
The motivation comes from a problem with the
'users.users.${u}.openssh.authorizedKeys' option.
It is easy to unintentionally insert a newline character at the end of a
string, or even in the middle, for example:
restricted_ssh_keys = command: keys:
let
prefix = ''
command="${command}",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding
'';
in map (key: "${prefix} ${key}") keys;
The 'prefix' string ends with a newline, which ends up in the middle of
a key entry after a few manipulations.
This is problematic because the key file is built by concatenating all
the keys with 'concatStringsSep "\n"', with result in two entries for
the faulty key:
''
command="...",options...
MY_KEY
''
This is hard to debug and might be dangerous. This is now caught at
build time.
When startWhenNeeded is enabled, a brute force attack on sshd will cause
systemd to shut down the socket, locking out all SSH access to the machine.
Setting TriggerLimitIntervalSec to 0 disables this behavior.
In case of a power loss shortly after first boot,
the host keys gernerated by ssh-keygen could exist
in the file system but have zero size, preventing
sshd from starting up.
This commit changes the behaviour to generate host
keys if the file either does not exist or has zero
size, fixing the problem on the next boot.
Thanks to @SuperSandro2000 for figuring this out.
The previous justification for using "VERBOSE" is incorrect,
because OpenSSH does use level INFO to log "which key was used
to log in" for sccessful logins, see:
6247812c76/auth.c (L323-L328)
Also update description to the wording of the sshd_config man page.
`fail2ban` needs, sshd to be "VERBOSE" to work well, thus
the `fail2ban` module sets it to "VERBOSE" if enabled.
The docs are updated accordingly.
The `curve25519-sha256` key exchange method is defined in RFC 8731 that
is identical to curve25519-sha256@libssh.org. OpenSSH supports the
method since version 7.4, released on 2016-12-19. It is literally a
violation of the "both in Secure Secure Shell and Mozilla guidelines"
rule, but it provides essentially the same but a future-proof default.
Also, links to the Mozilla OpenSSH guidelines are updated to refer to
the current place.
Signed-off-by: Masanori Ogino <167209+omasanori@users.noreply.github.com>
A centralized list for these renames is not good because:
- It breaks disabledModules for modules that have a rename defined
- Adding/removing renames for a module means having to find them in the
central file
- Merge conflicts due to multiple people editing the central file
With `sshd -t` config validation for SSH is possible. Until now, the
config generated by Nix was applied without any validation (which is
especially a problem for advanced config like `Match` blocks).
When deploying broken ssh config with nixops to a remote machine it gets
even harder to fix the problem due to the broken ssh that makes reverts
with nixops impossible.
This change performs the validation in a Nix build environment by
creating a store path with the config and generating a mocked host key
which seems to be needed for the validation. With a broken config, the
deployment already fails during the build of the derivation.
The original attempt was done in #56345 by adding a submodule for Match
groups to make it harder screwing that up, however that made the module
far more complex and config should be described in an easier way as
described in NixOS/rfcs#42.
Release notes are available at https://www.openssh.com/txt/release-7.5.
Mostly a bugfix release, no major backwards-incompatible changes.
Remove deprecated `UsePrivilegeSeparation` option,
which is now mandatory.
AFAICT, this issue only occurs when sshd is socket-activated. It turns
out that the preStart script's stdout and stderr are connected to the
socket, not just the main command's. So explicitly connect stderr to
the journal and redirect stdout to stderr.
This reverts commit 1a74eedd07. It
breaks NixOps, which expects that
rm -f /etc/ssh/ssh_host_ed25519_key*
systemctl restart sshd
cat /etc/ssh/ssh_host_ed25519_key.pub
works.
The configuration { services.openssh.enable = true;
services.openssh.forwardX11 = false; } caused
programs.ssh.setXAuthLocation to be set to false, which was not the
intent. The intent is that programs.ssh.setXAuthLocation should be
automatically enabled if needed or if xauth is already available.
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.)
The man page for ssh-keygen(1) has a section "MODULI GENERATION" that describes
how to generate your own moduli file. The following script might also be helpful:
| #! /usr/bin/env bash
|
| moduliFiles=()
|
| generateModuli()
| {
| ssh-keygen -G "moduli-$1.candidates" -b "$1"
| ssh-keygen -T "moduli-$1" -f "moduli-$1.candidates"
| rm "moduli-$1.candidates"
| }
|
| for (( i=0 ; i <= 16 ; ++i )); do
| let bitSize="2048 + i * 128"
| generateModuli "$bitSize" &
| moduliFiles+=( "moduli-$bitSize" )
| done
| wait
|
| echo >moduli "# Time Type Tests Tries Size Generator Modulus"
| cat >>moduli "${moduliFiles[@]}"
| rm "${moduliFiles[@]}"
Note that generating moduli takes a long time, i.e. several hours on a fast
machine!
This patch resolves https://github.com/NixOS/nixpkgs/pull/5870.
These services don't create files on disk, let alone on a network
filesystem, so they don't really need a fixed uid. And this also gets
rid of a warning coming from <= 14.12 systems.
Generating the file was refactored to be completely in nix.
Functionally it should create the same content as before,
only adding the newlines.
CC recent updaters: @aszlig, @rickynils.
