The order of files within /etc/ssh/sshd_config.d/ directly impacts how OpenSSH's sshd daemon interprets its configuration. The daemon reads files alphabetically, applying settings sequentially. This means later files can override earlier ones, leading to unexpected behavior if not carefully managed. A common example is setting PasswordAuthentication no in a later file, negating an earlier file's Match block intended to allow password logins for specific users or groups. Therefore, understanding and controlling file order in this directory is crucial for predictable and reliable SSH configuration.
Cloudflare has open-sourced OPKSSH, a tool that integrates single sign-on (SSO) with SSH, eliminating the need for managing individual SSH keys. OPKSSH achieves this by leveraging OpenID Connect (OIDC) and issuing short-lived SSH certificates signed by a central Certificate Authority (CA). This allows users to authenticate with their existing SSO credentials, simplifying access management and improving security by eliminating static, long-lived SSH keys. The project aims to standardize SSH certificate issuance and validation through a simple, open protocol, contributing to a more secure and user-friendly SSH experience.
HN commenters generally express interest in OpenPubkey but also significant skepticism and concerns. Several raise security implications around trusting a third party for SSH access and the potential for vendor lock-in. Some question the actual benefits over existing solutions like SSH certificates, agent forwarding, or using configuration management tools. Others see potential value in simplifying SSH key management, particularly for less technical users or in specific scenarios like ephemeral cloud instances. There's discussion around key discovery, revocation speed, and the complexities of supporting different identity providers. The closed-source nature of the server-side component is a common concern, limiting self-hosting options and requiring trust in Cloudflare. Several users also mention existing open-source projects with similar goals and question the need for another solution.
OpenBSD has contributed significantly to operating system security and development through proactive approaches. These include innovations like memory safety mitigations such as W^X (preventing simultaneous write and execute permissions on memory pages) and pledge() (restricting system calls available to a process), advanced cryptography and randomization techniques, and extensive code auditing practices. The project also champions portable and reusable code, evident in the creation of OpenSSH, OpenNTPD, and other tools, which are now widely used across various platforms. Furthermore, OpenBSD emphasizes careful documentation and user-friendly features like the package management system, highlighting a commitment to both security and usability.
Hacker News users discuss OpenBSD's historical focus on proactive security, praising its influence on other operating systems. Several commenters highlight OpenBSD's pledge ("secure by default") and the depth of its code audits, contrasting it favorably with Linux's reactive approach. Some debate the practicality of OpenBSD for everyday use, citing hardware compatibility challenges and a smaller software ecosystem. Others acknowledge these limitations but emphasize OpenBSD's value as a learning resource and a model for secure coding practices. The maintainability of its codebase and the project's commitment to simplicity are also lauded. A few users mention specific innovations like OpenSSH and CARP, while others appreciate the project's consistent philosophy and long-term vision.
Summary of Comments ( 83 )
https://news.ycombinator.com/item?id=43573507
Hacker News users discuss the implications of sshd_config.d file ordering, mostly agreeing it's a surprising but important detail. Several commenters highlight the potential for misconfigurations and debugging difficulties due to this behavior. One user shares a personal anecdote of troubleshooting an issue caused by this very problem, emphasizing the practical impact. Others point out the lack of clear documentation on this behavior in the man pages, suggesting it's a common pitfall. The discussion also touches upon alternative configuration approaches, like using a single file or employing tools like Puppet or Ansible to manage configurations more predictably. Some users express surprise that later files override earlier ones, contrary to their expectations. The overall sentiment reinforces the importance of awareness and careful management of sshd configuration files.
The Hacker News post discussing the importance of file order in
/etc/ssh/sshd_config.d/has generated several insightful comments. Many users shared their experiences and perspectives on how this seemingly minor detail can lead to significant configuration issues.One of the most compelling comments highlights the often-overlooked fact that this directory functions similarly to how
/etc/profile.d/and/etc/apache2/conf-enabled/(and similar directories) operate. It emphasizes that the order matters because later files can override settings from earlier ones. This comment served as a good reminder for users familiar with these other directory structures, connecting the concept across different system configurations.Another interesting point raised by a commenter is the importance of documentation and explicit ordering within the
sshd_config.ddirectory. They suggested using numbered prefixes, similar to systemd's approach, to ensure predictable and maintainable configuration loading. This proposition sparked further discussion about the best practices for managing configuration snippets in this directory, with some users advocating for explicitIncludedirectives within the mainsshd_configfile for maximum clarity and control.Several commenters shared anecdotal experiences where an unexpected file order in
sshd_config.dcaused problems in their SSH configurations. These stories provided practical examples of how seemingly minor ordering issues can lead to debugging headaches, reinforcing the blog post's central argument.One user mentioned the potential benefits and drawbacks of using an include directory like this. While acknowledging the potential for order-related issues, they pointed out that it allows for more modular and manageable configuration, especially when dealing with multiple contributors or automated configuration management tools.
The discussion also briefly touched upon the use of configuration management tools like Ansible, Puppet, Chef, or Salt. A commenter suggested that these tools could further complicate the ordering issue if not handled carefully, adding another layer of complexity to the configuration management process.
Finally, there was a comment acknowledging that while the blog post's information isn't entirely new, it serves as a valuable reminder of a potential pitfall that can easily be overlooked. This reinforces the importance of such discussions in raising awareness and promoting best practices within the system administration community.