Mostly correct. The majority of work in both is currently done by Damien and myself, who work on both.
There are a couple of people who have done significant work on OpenBSD's ssh (eg Markus, Theo) and various OpenBSD folks who add a feature or fix a bug and move on.
There is one person who currently works exclusively on -Portable (Tim Rice, who is still around although not very active these days) and at least one other in the past (Andre Lucas, who wrote the multi-platform login recording code). You can see the current set here: https://github.com/openssh/openssh-portable/blob/master/.git...
In OpenSSH 10.6openssh
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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 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
73 sources> sshd(8): On OS X SDK >= 27, sandboxing is no longer supported as the API we depended upon has been removed and no obvious alternative provided.
https://github.com/openssh/openssh-portable/commit/d4b4c304a...
In OpenSSH 10.6If I understand the code correctly, OpenSSH only injects delays and chaff when you're actively typing data through an interactive session directly to the ssh client itself (i.e. it's reading your key strokes from the TTY, as opposed to keystrokes being sent as opaque data over the X11 channel). There would be no disruption to X11 forwarding while you're not actively typing, and even then there's no delay if it can bundle key presses with non-interactive data. See https://github.com/openssh/openssh-portable/blob/088ca00/cli...
For a full desktop session, X11 over TCP should be much faster just because each X11 client app has it's own TCP connection, whereas for SSH X11 forwarding every app is tunneled over a single TCP connection.
In Sharing an X11 Server Across Hosts with FamilyWildIt's very difficult to reason about, for instance compare the OpenSSH sshd sandbox implementations.
https://github.com/openssh/openssh-portable/blob/master/sshd...
https://github.com/openssh/openssh-portable/blob/master/sand...
https://github.com/openssh/openssh-portable/blob/master/sand...
https://github.com/openssh/openssh-portable/blob/master/sand...
w/ Capsicum, beyond faffing around with some file descriptors, it's unclear what security cap_enter() adds:
https://github.com/openssh/openssh-portable/blob/master/sand...
In FreeBSD Capsicum vs. Linux Seccomp Process SandboxingIt looks like it is only applied for PTY sessions, which most computer-computer connections wouldn't be using.
https://github.com/openssh/openssh-portable/blob/d7950aca8ea...
In Why does SSH send 100 packets per keystroke?It's an artefact of OpenSSH braindamage, like a WiFi device spraying probe requests OpenSSH sprays all of your keys to any server it connects to and then takes whatever the server responds with as the one to auth. There's a CVE for this, CVE-2016-20012, but the OpenSSH maintainers rejected it as by-design, https://github.com/openssh/openssh-portable/pull/270.
In A ssh server that knows who you are. $ ssh whoami.filippo.ioUpstream is either OpenBSD itself or https://github.com/openssh/openssh-portable , not the FreeBSD port. I'm... not sure why nix is pulling the patch from FreeBSD, that's odd.
In High Performance SSH/SCPOh yeah, SSH signing is incredible. I've also migrated to it and didn't look back.
A couple of differences:
- it's possible to specify signing keys in a file inside the repository, and configure git to verify on merge (https://github.com/wiktor-k/ssh-signing/). I'm using that for my dot config repo to make sure I'm pulling only stuff I committed on my machines.
- SSH has TPM key support via PKCS11 or external agents, this makes it possible to easily roll out hardware backed keys
- SSH signatures have context separation, that is it's not possible to take your SSH commit signature and repurpose it (unlike OpenPGP)
- due to SSH keys being small the policy file is also small and readable, compare https://github.com/openssh/openssh-portable/blob/master/.git... with equivalent OpenPGP https://gitlab.com/sequoia-pgp/sequoia/-/blob/main/openpgp-p
Read the rest
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 wormsSoftware 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 systemsShowing the 15 most recent of 73 sources. Enable JavaScript to search and browse every indexed mention.