|
|
Subscribe / Log in / New account

OpenSSH 8.0 released

OpenSSH 8.0 has been released with a bunch of new features and some bug fixes, including one for a security problem: "This release contains mitigation for a weakness in the scp(1) tool and protocol (CVE-2019-6111): when copying files from a remote system to a local directory, scp(1) did not verify that the filenames that the server sent matched those requested by the client. This could allow a hostile server to create or clobber unexpected local files with attacker-controlled content. This release adds client-side checking that the filenames sent from the server match the command-line request, The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead."


From:  Damien Miller <djm-AT-openbsd.org>
To:  lwn-AT-lwn.net
Subject:  Announce: OpenSSH 8.0 released
Date:  Wed, 17 Apr 2019 18:32:01 -0600 (MDT)
Message-ID:  <ab3251975c795ebf@openbsd.org>
Archive-link:  Article

OpenSSH 8.0 has just been released. It will be available from the
mirrors listed at http://www.openssh.com/ shortly.

OpenSSH is a 100% complete SSH protocol 2.0 implementation and
includes sftp client and server support.

Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots or donated to the
project. More information on donations may be found at:
http://www.openssh.com/donations.html

Security
========

This release contains mitigation for a weakness in the scp(1) tool
and protocol (CVE-2019-6111): when copying files from a remote system
to a local directory, scp(1) did not verify that the filenames that
the server sent matched those requested by the client. This could
allow a hostile server to create or clobber unexpected local files
with attacker-controlled content.

This release adds client-side checking that the filenames sent from
the server match the command-line request,

The scp protocol is outdated, inflexible and not readily fixed. We
recommend the use of more modern protocols like sftp and rsync for
file transfer instead.

Potentially-incompatible changes
================================

This release includes a number of changes that may affect existing
configurations:

 * scp(1): Relating to the above changes to scp(1); the scp protocol
   relies on the remote shell for wildcard expansion, so there is no
   infallible way for the client's wildcard matching to perfectly
   reflect the server's. If there is a difference between client and
   server wildcard expansion, the client may refuse files from the
   server. For this reason, we have provided a new "-T" flag to scp
   that disables these client-side checks at the risk of
   reintroducing the attack described above.

 * sshd(8): Remove support for obsolete "host/port" syntax. Slash-
   separated host/port was added in 2001 as an alternative to
   host:port syntax for the benefit of IPv6 users. These days there
   are establised standards for this like [::1]:22 and the slash
   syntax is easily mistaken for CIDR notation, which OpenSSH
   supports for some things. Remove the slash notation from
   ListenAddress and PermitOpen; bz#2335

Changes since OpenSSH 7.9
=========================

This release is focused on new features and internal refactoring.

New Features
------------

 * ssh(1), ssh-agent(1), ssh-add(1): Add support for ECDSA keys in
   PKCS#11 tokens.

 * ssh(1), sshd(8): Add experimental quantum-computing resistant
   key exchange method, based on a combination of Streamlined NTRU
   Prime 4591^761 and X25519.

 * ssh-keygen(1): Increase the default RSA key size to 3072 bits,
   following NIST Special Publication 800-57's guidance for a
   128-bit equivalent symmetric security level.

 * ssh(1): Allow "PKCS11Provider=none" to override later instances of
   the PKCS11Provider directive in ssh_config; bz#2974

 * sshd(8): Add a log message for situations where a connection is
   dropped for attempting to run a command but a sshd_config
   ForceCommand=internal-sftp restriction is in effect; bz#2960

 * ssh(1): When prompting whether to record a new host key, accept
   the key fingerprint as a synonym for "yes". This allows the user
   to paste a fingerprint obtained out of band at the prompt and
   have the client do the comparison for you.

 * ssh-keygen(1): When signing multiple certificates on a single
   command-line invocation, allow automatically incrementing the
   certificate serial number.

 * scp(1), sftp(1): Accept -J option as an alias to ProxyJump on
   the scp and sftp command-lines.

 * ssh-agent(1), ssh-pkcs11-helper(8), ssh-add(1): Accept "-v"
   command-line flags to increase the verbosity of output; pass
   verbose flags though to subprocesses, such as ssh-pkcs11-helper
   started from ssh-agent.

 * ssh-add(1): Add a "-T" option to allowing testing whether keys in
   an agent are usable by performing a signature and a verification.

 * sftp-server(8): Add a "lsetstat@openssh.com" protocol extension
   that replicates the functionality of the existing SSH2_FXP_SETSTAT
   operation but does not follow symlinks. bz#2067

 * sftp(1): Add "-h" flag to chown/chgrp/chmod commands to request
   they do not follow symlinks.

 * sshd(8): Expose $SSH_CONNECTION in the PAM environment. This makes
   the connection 4-tuple available to PAM modules that wish to use
   it in decision-making. bz#2741

 * sshd(8): Add a ssh_config "Match final" predicate Matches in same
   pass as "Match canonical" but doesn't require hostname
   canonicalisation be enabled. bz#2906

 * sftp(1): Support a prefix of '@' to suppress echo of sftp batch
   commands; bz#2926

 * ssh-keygen(1): When printing certificate contents using
   "ssh-keygen -Lf /path/certificate", include the algorithm that
   the CA used to sign the cert.

Bugfixes
--------

 * sshd(8): Fix authentication failures when sshd_config contains
   "AuthenticationMethods any" inside a Match block that overrides
   a more restrictive default.

 * sshd(8): Avoid sending duplicate keepalives when ClientAliveCount
   is enabled.

 * sshd(8): Fix two race conditions related to SIGHUP daemon restart.
   Remnant file descriptors in recently-forked child processes could
   block the parent sshd's attempt to listen(2) to the configured
   addresses. Also, the restarting parent sshd could exit before any
   child processes that were awaiting their re-execution state had
   completed reading it, leaving them in a fallback path.

 * ssh(1): Fix stdout potentially being redirected to /dev/null when
   ProxyCommand=- was in use.

 * sshd(8): Avoid sending SIGPIPE to child processes if they attempt
   to write to stderr after their parent processes have exited;
   bz#2071

 * ssh(1): Fix bad interaction between the ssh_config ConnectTimeout
   and ConnectionAttempts directives - connection attempts after the
   first were ignoring the requested timeout; bz#2918

 * ssh-keyscan(1): Return a non-zero exit status if no keys were
   found; bz#2903

 * scp(1): Sanitize scp filenames to allow UTF-8 characters without
   terminal control sequences;  bz#2434

 * sshd(8): Fix confusion between ClientAliveInterval and time-based
   RekeyLimit that could cause connections to be incorrectly closed.
   bz#2757

 * ssh(1), ssh-add(1): Correct some bugs in PKCS#11 token PIN
   handling at initial token login. The attempt to read the PIN
   could be skipped in some cases, particularly on devices with
   integrated PIN readers. This would lead to an inability to
   retrieve keys from these tokens. bz#2652

 * ssh(1), ssh-add(1): Support keys on PKCS#11 tokens that set the
   CKA_ALWAYS_AUTHENTICATE flag by requring a fresh login after the
   C_SignInit operation. bz#2638

 * ssh(1): Improve documentation for ProxyJump/-J, clarifying that
   local configuration does not apply to jump hosts.

 * ssh-keygen(1): Clarify manual - ssh-keygen -e only writes
   public keys, not private.

 * ssh(1), sshd(8): be more strict in processing protocol banners,
   allowing \r characters only immediately before \n.

 * Various: fix a number of memory leaks, including bz#2942 and
   bz#2938

 * scp(1), sftp(1): fix calculation of initial bandwidth limits.
   Account for bytes written before the timer starts and adjust the
   schedule on which recalculations are performed. Avoids an initial
   burst of traffic and yields more accurate bandwidth limits;
   bz#2927

 * sshd(8): Only consider the ext-info-c extension during the initial
   key eschange. It shouldn't be sent in subsequent ones, but if it
   is present we should ignore it. This prevents sshd from sending a
   SSH_MSG_EXT_INFO for REKEX for buggy these clients. bz#2929

 * ssh-keygen(1): Clarify manual that ssh-keygen -F (find host in 
   authorized_keys) and -R (remove host from authorized_keys) options
   may accept either a bare hostname or a [hostname]:port combo.
   bz#2935

 * ssh(1): Don't attempt to connect to empty SSH_AUTH_SOCK; bz#2936

 * sshd(8): Silence error messages when sshd fails to load some of
   the default host keys. Failure to load an explicitly-configured
   hostkey is still an error, and failure to load any host key is
   still fatal. pr/103

 * ssh(1): Redirect stderr of ProxyCommands to /dev/null when ssh is
   started with ControlPersist; prevents random ProxyCommand output
   from interfering with session output.

 * ssh(1): The ssh client was keeping a redundant ssh-agent socket
   (leftover from authentication) around for the life of the
   connection; bz#2912

 * sshd(8): Fix bug in HostbasedAcceptedKeyTypes and
   PubkeyAcceptedKeyTypes options. If only RSA-SHA2 siganture types
   were specified, then authentication would always fail for RSA keys
   as the monitor checks only the base key (not the signature
   algorithm) type against *AcceptedKeyTypes. bz#2746

 * ssh(1): Request correct signature types from ssh-agent when
   certificate keys and RSA-SHA2 signatures are in use.

Portability
-----------

 * sshd(8): On Cygwin, run as SYSTEM where possible, using S4U for
   token creation if it supports MsV1_0 S4U Logon.

 * sshd(8): On Cygwin, use custom user/group matching code that
   respects the OS' behaviour of case-insensitive matching.

 * sshd(8): Don't set $MAIL if UsePAM=yes as PAM typically specifies
   the user environment if it's enabled; bz#2937

 * sshd(8) Cygwin: Change service name to cygsshd to avoid collision
   with Microsoft's OpenSSH port.

 * Allow building against OpenSSL -dev (3.x)

 * Fix a number of build problems against version configurations and
   versions of OpenSSL. Including bz#2931 and bz#2921

 * Improve warnings in cygwin service setup. bz#2922

 * Remove hardcoded service name in cygwin setup. bz#2922

Checksums:
==========

 - SHA1 (openssh-8.0.tar.gz) = 8aaa99091fc7e5a92a4a320e1e5521046b3f95f0
 - SHA256 (openssh-8.0.tar.gz) = 1xvSJk1KYSnOLPYEUzyCVwTEQ7MHOaCO65DzeNuuLdo=

 - SHA1 (openssh-8.0p1.tar.gz) = 756dbb99193f9541c9206a667eaa27b0fa184a4f
 - SHA256 (openssh-8.0p1.tar.gz) = vZQ4eeaUmOgDHra39E0IzcN9WaeraJqgtDcyDDSB/Wg=

Please note that the SHA256 signatures are base64 encoded and not
hexadecimal (which is the default for most checksum tools). The PGP
key used to sign the releases is available as RELEASE_KEY.asc from
the mirror sites.

Reporting Bugs:
===============

- Please read http://www.openssh.com/report.html
  Security bugs should be reported directly to openssh@openssh.com



to post comments

OpenSSH 8.0 released

Posted Apr 18, 2019 22:26 UTC (Thu) by epa (subscriber, #39769) [Link] (6 responses)

So can scp(1) use the rsync or ftp protocols instead, but with the same command line syntax as before?

OpenSSH 8.0 released

Posted Apr 18, 2019 22:51 UTC (Thu) by k8to (guest, #15413) [Link] (1 responses)

Rhetorical? I don't think scp has these capabilities.

OpenSSH 8.0 released

Posted Apr 19, 2019 1:33 UTC (Fri) by epa (subscriber, #39769) [Link]

It seems like the obvious step if the old scp protocol is to be killed off. Nobody uses scp because they particularly love the protocol -- it's just for convenience, a familiar command line syntax, or because there are old shell scripts that call it.

OpenSSH 8.0 released

Posted Apr 19, 2019 0:01 UTC (Fri) by perennialmind (guest, #45817) [Link] (3 responses)

Putty's PSCP does what you describe: it has a -sftp and a -scp, defaulting to the former and falling back to the latter. I might have switched to it by now if it consulted ~/.ssh. I rather like the idea of a one-shot command with support for those and a -rsync as well. scp's behavior is trivial to internalize, but what I've internalized for rsync is that it's subtle and that I need to consult the man page every time.

This

Posted Apr 21, 2019 0:49 UTC (Sun) by scientes (guest, #83068) [Link] (2 responses)

This is exactly the behavior scp should have. I actually long though they were the same protocol, because I had such good experience using sftp mounted via gvfs in nautilus (although it mounts to POSIX/FUSE with a space in the mount location under ~/.gvfs which is really stupid....)

This

Posted Apr 21, 2019 5:17 UTC (Sun) by lkundrak (subscriber, #43452) [Link]

> although it mounts to POSIX/FUSE with a space in the mount location under ~/.gvfs which is really stupid....)

Why is it stupid?

This

Posted Apr 21, 2019 9:15 UTC (Sun) by Darkmere (subscriber, #53695) [Link]

I thought it mounted them in /run/$USER/ these days for all mounts?

And, I rather like that behavior of Gnome these days, it means I can do basic exploration in the GUI, and if I want to muck around with my command line tools or services that don't speak that layer, I can just access them as normal filesystems.

Very convenient.

OpenSSH 8.0 released

Posted Apr 18, 2019 22:57 UTC (Thu) by k8to (guest, #15413) [Link] (1 responses)

That vulnerability is a bit odd.
In scp, I can do

scp server:/path/to/a/file.txt target.txt

and this should open and write to target.txt. I would be surprised if the server knew about that at all. Though I don't know.

Since that's implemented somehow, you would expect

scp server:/path/to/a/file.txt .

to just be client shorthand for

scp server:/path/to/a/file.txt ./file.txt

It seems seriously weird that it would not.

But there is also functionality like this:

scp server:/path/to/* .

where you just trust the remote server won't send you evil filenames that will destroy your world. And I don't see how you can solve that problem.

So it seems that the specific-file codepaths lazily used the known-file filepaths. Which is unfortunate, but not shocking, since scp -r is commonly enough used.

OpenSSH 8.0 released

Posted Apr 19, 2019 1:12 UTC (Fri) by epa (subscriber, #39769) [Link]

When you get back a filename from the server you check that it is a relative path (does not begin /) and is canonical (does not contain ..). And you check that it is a possible expansion of the glob pattern you gave (which is effectively the same as doing a regular expression match, just with different syntax). That should be enough.

OpenSSH 8.0 released

Posted Apr 20, 2019 1:53 UTC (Sat) by bmur (guest, #52954) [Link] (20 responses)

Like k8to above, moving files with scp is built into my muscle memory.

As long as "scp file.tgz user@host:" continues to work, I really don't care one bit if it's handled by the scp, sftp, or some other secure protocol under the covers.

For version 9, keep the same exact scp command line syntax and make the underlying protocol sftp by default. Add a command line option to explicitly request the scp protocol for anyone who really must have it. I would bet most people don't care how the bits travel the wire.

OpenSSH 8.0 released

Posted Apr 20, 2019 7:05 UTC (Sat) by marcH (subscriber, #57642) [Link] (8 responses)

You can transfer your muscle memory "as is" to rsync which has the same basic syntax; then start enjoying the additional features.

I don't remember the last time I used "cp" to perform a recursive copy... locally.

OpenSSH 8.0 released

Posted Apr 20, 2019 7:16 UTC (Sat) by marcH (subscriber, #57642) [Link] (7 responses)

Just remembered one of the reasons I stopped using "cp -r". Assuming dst/ doesn't exist yet, then running this twice:

cp -r src/ dst/
cp -r src/ dst/

... does something different the second time on Linux (not on macOS).

Running the same rsync command twice never does something different the second time, that's crazy.

OpenSSH 8.0 released

Posted Apr 20, 2019 11:06 UTC (Sat) by dw (subscriber, #12017) [Link] (5 responses)

I'm not sure that's true. Some combination of 'with slash' or 'without slash' on either the source or dest changes behaviour if the target already exists as a directory. I never stop to figure out what went wrong, so can't be more specific than "something to do with slashes". I hate this aspect of rsync's UI

OpenSSH 8.0 released

Posted Apr 20, 2019 17:47 UTC (Sat) by marcH (subscriber, #57642) [Link]

> I'm not sure that's true

Why didn't you just try it? It's not like this requires a complex setup.

Yes, a trailing slash "src/" in the rsync source means "src/*". It's not the most intuitive syntax but it's a useful feature.

That wasn't the point though, the point was: run the same "cp -r" command twice and it can give different results the second time on Linux. Run the same command on macOS and it can behave differently again. None of that craziness with rsync.

OpenSSH 8.0 released

Posted Apr 20, 2019 22:11 UTC (Sat) by karkhaz (subscriber, #99844) [Link] (3 responses)

So first of all, I don't think a slash on the destination ever matters.

A slash on the source directory does change rsync's behaviour, but that has nothing to do with whether the destination exists. The behaviours are orthogonal, here is a matrix:

when dst doesn't exist
rsync -a src/ dst --> creates dst, copies contents of src into dst
rsync -a src dst --> creates dst, copies src into dst

when dst exists
rsync -a src/ dst --> copies contents of src into dst
rsync -a src dst --> copies src into dst

I do remember being surprised by this when I first used rsync, but the man page is fairly clear about it; I'm curious to hear if what behaviour you might find less surprising, while retaining the ability to copy either a directory or its contents (without using shell wildcards or the like)?

OpenSSH 8.0 released

Posted Apr 22, 2019 9:12 UTC (Mon) by oldtomas (guest, #72579) [Link]

Quoth the man page:

"A trailing slash on the source changes this behavior to avoid creating an additional directory level at the destination. You can think of a trailing / on a source as meaning 'copy the contents of this directory' as opposed to 'copy the directory by name', but in both cases the attributes of the containing directory are transferred to the containing directory on the destination"

(And for the reverse: just searching for "trailing" or "trailing slash" clears that part up pretty quickly).

Rsync's man page may be daunting, but it is extremely well written.

"If all else fails, read the instructions"

rsync mnemonic

Posted Apr 26, 2019 21:43 UTC (Fri) by naptastic (guest, #60139) [Link] (1 responses)

The choice seemed arbitrary to me until I came up with a mnemonic for it: Trailing slash means "the contents of the directory," and no trailing slash means "the directory as a single thing." Somehow my brain also maps that to pointers versus values:
rsync(src, dest);  /* one item, named 'src', will be created in dest */
rsync(*src, dest); /* everything under 'src' will be created in dest */
I don't know if that helps or even makes sense to anyone else.

rsync mnemonic

Posted Apr 26, 2019 23:49 UTC (Fri) by karkhaz (subscriber, #99844) [Link]

That's a beautiful analogy :-)

OpenSSH 8.0 released

Posted Apr 22, 2019 22:09 UTC (Mon) by Pc5Y9sbv (guest, #41328) [Link]

Along the same lines, I eventually started using the -R (--relative) flag to rsync in my most confident idempotent transfer mode:

rsync -avRP host:/prefix1/./rel1 host:/prefix2/./rel2 /prefix3/.

This creates /prefix3/rel1 and /prefix3/rel2 hierarchies with the easy to understand semantics that it splices the trees at the '.' point. Also, for me the --excludes/--includes patterns are easier to understand when I know they will be rooted at the '.' as well.

OpenSSH 8.0 released

Posted Apr 24, 2019 10:44 UTC (Wed) by nilsmeyer (guest, #122604) [Link] (10 responses)

Very often I find myself piping tar through SSH, especially when I need to use sudo.

OpenSSH 8.0 released

Posted Apr 24, 2019 11:39 UTC (Wed) by gevaerts (subscriber, #21521) [Link]

I would never do that. My fingers know cpio much better for that usecase :)

OpenSSH 8.0 released

Posted Apr 27, 2019 22:49 UTC (Sat) by naptastic (guest, #60139) [Link] (8 responses)

I've wondered for a long time how people do things like rsync to root-owned destinations when their systems don't allow direct root SSH. I'm almost scared to ask, but can you elaborate on how it's done?

The top result via Google is from Ask Ubuntu [1], and--don't do this--it recommends adding "ALL=NOPASSWD:<path to rsync>" to sudoers, which is terrifying on so many levels.

(In case it's unclear, really, DO NOT EVER DO THIS. Running rsync as root means arbitrary file operations as root. It will let any program on your system to get root for free: just drop in a malicious shared library, steal the nearest Bitcoin wallet, and eat all the cheese in the house.)

[1] https://askubuntu.com/questions/719439/using-rsync-with-sudo-on-the-destination-machine

OpenSSH 8.0 released

Posted Apr 28, 2019 20:34 UTC (Sun) by muwlgr (guest, #35359) [Link]

You are supposed to have the most of control you wish by using authorized_keys under ~/.ssh/

OpenSSH 8.0 released

Posted Apr 29, 2019 22:04 UTC (Mon) by ScottMinster (subscriber, #67541) [Link] (6 responses)

I don't think the sudoers suggestion is as bad as you make it out to be, at least in the particular case where the user in question is presumed to be the system admin. The post recommends adding that line to sudoers for a specific user, and a specific rsync path, as in "naptastic ALL=NOPASSWD:/usr/bin/rsync". Then that user account could "sudo rsync" to run the rsync command as root without a password.

You're right, of course, that when running rsync as root can be disastrous if misused. And leaving that configuration does allow someone who has gotten access to that admin's user account to much more easily get root access, which would be very bad. As a temporary solution to preserve multiple UIDs/GIDs in a transfer, it's not awful. Eventually, those writes have to be done as root. I would probably prefer to do the operation the other direction -- run rsync as root on the destination machine. That way, no permanent sudoers changes would be required, which one might forget to remove.

OpenSSH 8.0 released

Posted Apr 30, 2019 7:01 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (5 responses)

As soon as you grant a user sudo without a password to any program that can write to arbitrary files (rsync, tar, cp, sed, awk, tee, bash, Perl, Python, whatever), that account becomes root for all intents and purposes. It's trivial to gain real root in such a scenario, simply by using your "write to any file" program to create a new sudoers file with passwordless access to everything (among many, many other scenarios).

If you're disallowing root login via ssh, you're doing it for security purposes, and by allowing passwordless sudo to such commands you completely counteract those security purposes. You'd have to handle the security for that account the same way you're handling it for root: disallow login via ssh completely. Or to frame it differently: if you enable passwordless sudo rsync, you could just as well re-enable root login via ssh (with public keys, please!) as it would be less hassle and no less secure.

For my own machines I generally disable ssh root login for unknown addresses and often allow it for known-good addresses using "Match" blocks in sshd_config, e.g.

PermitRootLogin no

Match Address 2001:db8::/64
PermitRootLogin prohibit-password

OpenSSH 8.0 released

Posted Apr 30, 2019 12:45 UTC (Tue) by ScottMinster (subscriber, #67541) [Link] (2 responses)

I completely agree with what you wrote, which is why I suggested that the sudoers modification (if used at all) be temporary.

But is there a better way to solve the original problem? If you have a directory tree with files with varying user and group IDs that you want to sync to a remote server, what is the best way to do it?

Using tar (something like "tar -c . | ssh server2 sudo tar -C /path/to/dest -x") would work if you didn't care about transferring all the data. If the destination is empty, you'd have to do that anyway. But suppose you just needed to update the copy?

I would expect that running 'rsync' as root on the destination machine would work, as in "rsync -a server1:/path/to/source /path/to/dest". But that assume that you can ssh from server2 to server1, which isn't always the case.

Is there some more obvious method I'm missing?

OpenSSH 8.0 released

Posted Apr 30, 2019 14:46 UTC (Tue) by excors (subscriber, #95769) [Link]

I think you can just provide the password to the remote sudo, like:

rsync -e 'ssh -X' --rsync-path='SUDO_ASKPASS=/usr/bin/ssh-askpass /usr/bin/sudo -A /usr/bin/rsync' -a server1:/path server2:/path

OpenSSH 8.0 released

Posted Apr 30, 2019 14:59 UTC (Tue) by mbunkus (subscriber, #87248) [Link]

You could try what excors wrote about using sudo-rsync with a password.

Another thing you can try if your source machine allows root-login-via-ssh is reversing the direction of the transfer: instead of running rsync on "source" ssh'ing to "destination", ssh from "source" to "destination" with a reverse port forwarding to "source:22" and run rsync on "destination" with "localhost:<forwardedPort>" as the source address.

OpenSSH 8.0 released

Posted Apr 30, 2019 15:07 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

As soon as you grant a user sudo without a password to any program that can write to arbitrary files (rsync, tar, cp, sed, awk, tee, bash, Perl, Python, whatever), that account becomes root for all intents and purposes.
Not for all: the user is still protected from typos and accidents -- just not from malicious attackers executing code as the user.

OpenSSH 8.0 released

Posted Apr 30, 2019 15:14 UTC (Tue) by mbunkus (subscriber, #87248) [Link]

Sure, my statement was a bit too general. The original question was how to rsync root-owned stuff while root login via ssh is prohibited, and you do that in order to increase security, not in order to in order to make typos less dangerous. My comment was therefore meant that the two accounts are almost equivalent wrt. to security, especially regarding access from untrusted sources.


Copyright © 2019, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds