I wonder how this will affect ssh. OpenSSH recently restricted more characters for valid usernames: https://github.com/openssh/openssh-portable/commit/7ef3787c8...
In Debian opens a can of username wormsopenssh
openssh-portable
C2015–2026
openssh / openssh-portable
openssh-portable
Portable OpenSSH
64Distinct people
73Mentions
0Explicit recommenders
4.1KGitHub stars
What to know before exploring
What it is
Portable OpenSSH
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 6:01:32 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year73 dated mentions
Observed mentions: 2015-07-22 02:59:34 UTC to 2026-10-10 07:48:53 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 10 | 4 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 9 | 0 | 9 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 18 | 0 | 18 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 6 | 0 | 6 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Portable OpenSSH
OpenSSH is a complete implementation of the SSH protocol (version 2) for secure remote login, command execution and file transfer. It includes a client ssh and server sshd, file transfer utilities scp and sftp as well as tools for key generation (ssh-keygen), run-time key storage (ssh-agent) and a number of supporting programs.
This is a port of OpenBSD's OpenSSH to most Unix-like operating systems, including Linux, OS X and Cygwin. Portable OpenSSH polyfills OpenBSD APIs that are not available elsewhere, adds sshd sandboxing for more operating systems and includes support for OS-native authentication and auditing (e.g. using PAM).
Documentation
The official documentation for OpenSSH are the man pages for each tool:
ssh(1)
sshd(8)
ssh-keygen(1)
ssh-agent(1)
scp(1)
sftp(1)
ssh-keyscan(8)
sftp-server(8)
Stable Releases
Stable release tarballs are available from a number of download mirrors. We recommend the use of a stable release for most users. Please read the release notes for details of recent changes and potential incompatibilities.
Building Portable OpenSSH
Dependencies
Portable OpenSSH is built using autoconf and make. It requires a working C compiler, standard library and headers.
libcrypto from one of LibreSSL, OpenSSL, AWS-LC or BoringSSL may also be used. OpenSSH may be built without any of these, but the resulting binaries will have only a subset of the cryptographic algorithms normally available.
zlib is optional; without it transport compression is not supported.
FIDO security token support needs libfido2 and its dependencies and will be enabled automatically if they are found.
In addition, certain platforms and build-time options may require additional dependencies; see README.platform for details about your platform.
Building a release
Release tarballs and release branches in git include a pre-built copy of the configure script and may be built using:
tar zxvf openssh-X.YpZ.tar.gz
cd openssh
./configure # [options]
make && make tests
See the Build-time Customisation section below for configure options. If you plan on installing OpenSSH to your system, then you will usually want to specify destination paths.
Building from git
If building from the git master branch, you'll need autoconf installed to build the configure script. The following commands will check out and build portable OpenSSH from git:
git clone https://github.com/openssh/openssh-portable # or https://anongit.mindrot.org/openssh.git
cd openssh-portable
autoreconf
./configure
make && make tests
Build-time Customisation
There are many build-time customisation options available. All Autoconf destination path flags (e.g. --prefix) are supported (and are usually required if you want to install OpenSSH).
For a full list of available flags, run ./configure --help but a few of the more frequently-used ones are described below. Some of these flags will require additional libraries and/or headers be installed.
Flag
Meaning
--with-pam
Enable PAM support. OpenPAM, Linux PAM and Solaris PAM are supported.
--with-libedit
Enable libedit support for sftp.
--with-kerberos5
Enable Kerberos/GSSAPI support. Both Heimdal and MIT Kerberos implementations are supported.
--with-selinux
Enable SELinux support.
Development
Portable OpenSSH development is discussed on the openssh-unix-dev mailing list (archive mirror). Bugs and feature requests are tracked on our Bugzilla.
Reporting bugs
Non-security bugs may be reported to the developers via Bugzilla or via the mailing list above. Security bugs should be reported to openssh@openssh.com.
Read the full README on GitHubWhat Hacker News says
18 sourcesSoftware sandboxing has a relatively good cost-to-benefit ratio at reducing the consequences of software bugs, which is why it's already implemented in a lot of software we all use every day. For example, it exists in Android apps, iOS apps, Flatpak apps (Linux), Firefox[1][2], Chromium browsers[3][4][5], SELinux-enabled distributions such as Fedora and Hardened Gentoo[6], OpenSSH (Linux)[7], postfix's multi-process architecture with use of ACLs, etc.
Kubernetes, Docker and systemd folk will be familiar with the idea of sandboxing for containers too, and they're able to do so using much higher level controls, e.g. turn on Kubernetes "Restricted pod security standard" for much stricter sandboxing defaults. Even if containerisation and daemon sandboxing aren't used, architects will understand the concept of sandboxing by just specifying mor
Read the rest
e servers, each one ideally performing a separate job with the number of external interfaces minimised as much as possible. In all of these situations, the use of more granular controls such as detailed seccomp-bpf filters is most useful to mitigate the risks introduced by (ironically) security agent software that is typically installed alongside a database server daemon, web server daemon, etc within the same container.
Tweaking some Kubernetes, Docker or systemd config is _much_ cheaper and quicker to implement rather than waiting to rewrite software in a safer language such as Rust (a noble end goal). Even if software were rewritten in Rust, you'd _still_ want to implement some form of external sandboxing (e.g. systemd-nspawn applying seccomp-bpf filters based on some basic systemd service configuration) to mitigate supply chain attacks against Rust software which cause the software to perform functions it shouldn't be doing.
[1] Firefox Linux: https://searchfox.org/mozilla-central/source/security/sandbo...
[2] Firefox Windows: https://searchfox.org/mozilla-central/source/security/sandbo...
[3] Chromium multi-platform: https://github.com/chromium/chromium/blob/main/docs/security...
[4] Chromium Linux: https://chromium.googlesource.com/chromium/src/+/0e94f26e8/d... (seemingly Linux sandboxing is experiencing significant changes as this document or one similar to it does not appear to exist anymore)
[5] Chromium Windows: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...
[6] https://gitweb.gentoo.org/proj/hardened-refpolicy.git/tree/p...
[7] https://github.com/openssh/openssh-portable/blob/master/sand...
> You are acknowledging my point - in this case they ARE the same thing. If it looks like a duck, quacks like a duck, and walks like a duck - it's a duck.
Ok, so two programs with different code that perform the same task are identical to you. There are never any merits or drawbacks on implementation according to you.
All the extra features that SFTP has but SCP doesn't don't exist, because "looks like a duck, quacks like a duck." SCP being faster but not allowing resuming interrupted transfers doesn't matter, because "looks like a duck, quacks like a duck."
If this is the level of thought you put into your tech, you don't seem worth arguing with, but you also don't seem like someone who should be "teaching" anything to anyone in your own comments.
> Who is using a pre-2022 distro reading this comment?
Plenty of enterprises. That's only t
Read the rest
wo years ago. People still use systems far older than that.
This does include Ubuntu 22.04 LTS, which shipped OpenSSH 8.9. It would also include RHEL 9, which shipped OpenSSH 8.7, if Red Hat hadn't specifically patched it with the updated behavior.
Here's Red Hat talking about SCP being deprecated in RHEL 9, specifically: https://www.redhat.com/en/blog/openssh-scp-deprecation-rhel-... Interesting how much they have to say about the topic since there's apparently no difference, according to you.
> And I have been using scp (with SSH, SFTP) for a lot longer than since 2022. Like over a decade.
You probably weren't, you were probably using SCP. Optional SFTP support wasn't even added to the SCP command until 2020, committed in 2021, so "over a decade" is just factually impossible: https://github.com/openssh/openssh-portable/commit/197e29f1c...
This is why you need to know these things, because now you kind of look like an idiot for not even knowing the tools you use.
>As mentioned elsewhere here, is -D sufficient to avoid exploitation, or is -e necessary as well?
https://github.com/openssh/openssh-portable/blob/V_9_8_P1/ss...
sshd.c handles no_daemon (-D) and log_stderr (-e) independently. log_stderr is what is given to log_init in log.c that gates the call to syslog functions. There is a special case to set log_stderr to true if debug_flag (-d) is set, but nothing for no_daemon.
I can't test it right now though so I may be missing something.
In RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systemsFrom the diff introducing the bug [1], the issue according to the analysis is that the function was refactored from this:
void
sigdie(const char *fmt,...)
{
#ifdef DO_LOG_SAFE_IN_SIGHAND
va_list args;
va_start(args, fmt);
do_log(SYSLOG_LEVEL_FATAL, fmt, args);
va_end(args);
#endif
_exit(1);
}
to this:
void
sshsigdie(const char *file, const char *func, int line, const char *fmt, ...)
{
va_list args;
va_start(args, fmt);
sshlogv(file, func, line, 0, SYSLOG_LEVEL_FATAL, fmt, args);
va_end(args);
_exit(1);
}
which lacks the #ifdef.
What could have prevented this? More eyes on the pull request? It's wild that software nearly the entire world relies on for secure access is maintained by seemingly just two people [2].
[1] https://github.com/openssh/openssh-portable/commit/752250caa...
[2]
In RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systemsDefault is 100: https://github.com/openssh/openssh-portable/blob/master/serv...
In RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systemsSame here. It's caused by the sshd daemon being split into multiple binaries. In fact, the commit which introduced the change mentions this explicitly:
> NB. if you're updating via source, please restart sshd after installing, otherwise you run the risk of locking yourself out.
https://github.com/openssh/openssh-portable/commit/03e3de416...
Edit: Already reported at https://gitlab.archlinux.org/archlinux/packaging/packages/op...
In RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systemsThe ones you link are the "minimal patches for those can't/don't want to upgrade". The commit I am linking to is taken straight from the advisory.
On June 6, 2024, this signal handler race condition was fixed by commit
81c1099 ("Add a facility to sshd(8) to penalise particular problematic
client behaviours"), which moved the async-signal-unsafe code from
sshd's SIGALRM handler to sshd's listener process, where it can be
handled synchronously:
https://github.com/openssh/openssh-portable/commit/81c1099d22b81ebfd20a334ce986c4f…
Because this fix is part of a large commit (81c1099), on top of an even
larger defense-in-depth commit (03e3de4, "Start the process of splitting
sshd into separate binaries"), it might prove difficult to backport. In
that case, the signal handler race condition itsel
Read the rest
f can be fixed by
removing or commenting out the async-signal-unsafe code from the
sshsigdie() function
The cleverness here is that this commit is both "a previously-announced feature for dealing with junk connections", and a mitigation for the exploit class against similar but unknown vulnerabilities, and a patch for the specific vulnerability because it "moved the async-signal-unsafe code from sshd's SIGALRM handler to sshd's listener process, where it can be handled synchronously".
The cleverness is that it fixes the vulnerability as part of doing something that makes sense on its own, so you wouldn't know it's the patch even looking at it.
Interestingly, the RCE fix was "smuggled" in public almost a month ago.
When PerSourcePenalties are enabled, sshd(8) will monitor the exit
status of its child pre-auth session processes. Through the exit
status, it can observe situations where the session did not
authenticate as expected. These conditions include when the client
repeatedly attempted authentication unsucessfully (possibly indicating
an attack against one or more accounts, e.g. password guessing), or
when client behaviour caused sshd to crash (possibly indicating
attempts to exploit sshd).
When such a condition is observed, sshd will record a penalty of some
duration (e.g. 30 seconds) against the client's address.
https://github.com/openssh/openssh-portable/commit/81c1099d2...
It's not really a reversable patch that gives anything a
Read the rest
way to attackers: it changes the binary architecture in a way that has the side-effect of removing the specific vulnerability and also mitigates the whole exploit class, if I understand it correctly. Very clever.
The OpenBSD project provides a CVSWeb interface[1] and a GitHub mirror[2]. The portable OpenSSH project[2] that most of the world gets their OpenSSH from uses a Git repo[4] that also has a Web interface (at the same address) and a GitHub mirror[5]. Per the code there[6], the default configuration seems to be
PerSourcePenalties crash:90 authfail:5 noauth:1 grace-exceeded:20 max:600 min:15 max-sources:65536 overflow:permissive
[1] https://cvsweb.openbsd.org/
[2] https://github.com/openbsd/src
[3] https://www.openssh.com/portable.html
[4] https://anongit.mindrot.org/openssh.git
[5] https://github.com/openssh/openssh-portable
[6] https://anongit.mindrot.org/openssh.git/tree/servconf.c?id=0...
In OpenSSH introduces options to penalize undesirable behavior> This is a port of OpenBSD's OpenSSH to most Unix-like operating systems, including Linux, OS X and Cygwin. Portable OpenSSH polyfills OpenBSD APIs that are not available elsewhere, adds sshd sandboxing for more operating systems and includes support for OS-native authentication and auditing (e.g. using PAM).
* https://github.com/openssh/openssh-portable
Perhaps see specifically the "openbsd-compat" directory, otherwise I think the source tree is very close the the 'OpenBSD version':
* https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/
In OpenBSD – sshd(8) split into multiple binariesDefault for the last 24 years according to https://github.com/openssh/openssh-portable/blame/385ecb31e1...
In New startup sells coffee through SSHShowing the 15 most recent of 18 sources. Enable JavaScript to search and browse every indexed mention.