https://bugzilla.mindrot.org/show_bug.cgi?id=3461 Bug ID: 3461 Summary: General observations Product: Portable OpenSSH Version: v9.0p1 Hardware: Other OS: Linux Status: NEW Keywords: help-wanted Severity: enhancement Priority: P5 Component: Miscellaneous Assignee: unassigned-bugs at mindrot.org Reporter: ricky.tigg at gmail.com **General information** ``` $ cat /etc/redhat-release Fedora release 36 (Thirty Six) $ uname -ro 5.18.10-200.fc36.x86_64 GNU/Linux ``` Hello. Having noticed, somehow lately, the version of component OpenSSH ported on my system, which is served via the main repository of my current distribution, not being up-to-date, as this state has been lasting long enough,i get at last motivated to decide to start the project to get installed by my own an up-to-date stable component. Prior to the required removal of the actually installed OpenSSH component, i felt wiser to investigate the possibilities made available to user while compiling an installation, for instance in respect to the allowance of the public-key authentication alone, thus excluding password and host-based authentications. ``` $ ssh -V OpenSSH_8.8p1, OpenSSL 3.0.5 5 Jul 2022 ``` Source | https://github.com/openssh/openssh-portable "libcrypto from either LibreSSL or OpenSSL may also be used, but OpenSSH may be built without it supporting a subset of crypto algorithms. **Installed components** ``` $ dnf --installed list '*crypto*' | sed 1d crypto-policies.noarch 20220428-1.gitdfb10ea.fc36 @updates crypto-policies-scripts.noarch 20220428-1.gitdfb10ea.fc36 @updates libblockdev-crypto.x86_64 2.27-1.fc36 @updates python3-crypto.x86_64 2.6.1-39.fc36 @anaconda python3-cryptography.x86_64 36.0.0-3.fc36 @anaconda $ dnf --available list '*libcrypto*' | sed 1d Error: No matching Packages to list ``` Above outputs indicate LibreSSL and OpenSSL as being not installed which is attested as well. Unknown is the object "supporting a subset of crypto algorithms" refers to. _Note_: In `configure --help`,as we can notice it, the syntax of the command is invalid; I guess that the correct syntax was intended instead, as it is elsewhere there, which is then `./configure --help`, otherwise as expected the following would be produced: ``` $ configure --help bash: configure: command not found... ``` In `./configure --disable-FEATURE` the obvious is noticeable; the lack of mention of such features or link to them. No mentions at https://www.openssh.com/features.html neither. -- You are receiving this mail because: You are watching the assignee of the bug.
https://bugzilla.mindrot.org/show_bug.cgi?id=3461 Darren Tucker <dtucker at dtucker.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dtucker at dtucker.net --- Comment #1 from Darren Tucker <dtucker at dtucker.net> --- (In reply to ricky.tigg from comment #0) [...]> Source | https://github.com/openssh/openssh-portable > > "libcrypto from either LibreSSL or OpenSSL may also be used, but > OpenSSH may be built without it supporting a subset of crypto > algorithms. > > **Installed components**libcrypto is the file. Depending on the platform and library type it can end in .so, .a, .sl or maybe something else. On Linuxes, the name of the package it's in varies with the distro. In Redhat-derived distros it's usually "openssl-libs": $ rpm -qf /usr/lib/libcrypto.so.3 openssl-libs-3.0.5-1.fc36.i686 To build software against it, you'll also need to install its headers. Again, the name of the package varies with distro. Quoting from README.platform: """ Some Linux distributions (including Red Hat/Fedora/CentOS) include headers and library links in the -devel RPMs rather than the main binary RPMs. If you get an error about headers, or complaining about a missing prerequisite then you may need to install the equivalent development packages. On Redhat based distros these may be openssl-devel, zlib-devel and pam-devel, on Debian based distros these may be libssl-dev, libz-dev and libpam-dev. """> Above outputs indicate LibreSSL and OpenSSL as being not installed > which is attested as well.That is not the case.> Unknown is the object "supporting a subset of crypto algorithms" refers to.It means an OpenSSH built --without-openssl will support only a subset of the public-key and symmetric cryptographic algorithms (basically just ed25519 and AES) that one built with OpenSSL would. I'll try to clarify the text.> _Note_: In `configure --help`,as we can notice it, the syntax of the > command is invalid; I guess that the correct syntax was intended > instead, as it is elsewhere there, which is then `./configure > --help`, otherwise as expected the following would be produced:Whether you need "configure" or "./configure" is a function of your shell and its paths. That said, in the help output generated by the current versions of autoconf include the "./": $ ./configure --help | head -3 `configure' configures OpenSSH Portable to adapt to many kinds of systems. Usage: ./configure [OPTION]... [VAR=VALUE]... I did find one instance of "configure --help" without the ./ in README.md which I'll change.> In `./configure --disable-FEATURE` the obvious is noticeable; the > lack of mention of such features or link to them. No mentions at > https://www.openssh.com/features.html neither.I'm not sure what you're referring to here. Could you please elaborate? -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug.
https://bugzilla.mindrot.org/show_bug.cgi?id=3461 --- Comment #2 from ricky.tigg at gmail.com --- Note | the syntax applied in my previous message leads to an effective text formatting on GitLab and GitHub platforms, as user. However as it appears here, on the present platform it is not supported, at least as user. Thus from now writing accordingly. Nevertheless as it appears in your message, that does not apply to you since there are formatted expressions that are present in it. I realised that my very mention 'OpenSSH_8.8p1, OpenSSL 3.0.5 (...)' exhibited 'OpenSSL 3.0.5 5', implying then that an OpenSSL component must be installed. So as i just learned here 'libcrypto' was not as package. I have to figure out what it is then. It might be a library, as the prefix 'lib' suggests it. Who knows who can guess whether it is intended to be interpreted as a package or something else. By principle i avoid guessing when instruction provided as documentation are not self explicit. $ locate *libcrypto* | grep '3.0.5$' /usr/lib64/libcrypto.so.3.0.5 $ rpm -qf `locate *libcrypto* | grep '3.0.5$'` openssl-libs-3.0.5-1.fc36.x86_64 $ dnf -q provides /usr/lib64/libcrypto.so.3.0.5 openssl-libs-1:3.0.5-1.fc36.x86_64 : A general purpose cryptography library with TLS : implementation Repo : @System Matched from: Filename : /usr/lib64/libcrypto.so.3.0.5 So that is a library it was referred to in 'libcrypto from either LibreSSL or OpenSSL (...)' and it was installed along with installation of component from openssl-libs package. Suggestion of complete statement instead: 'libcrypto library from either LibreSSL or OpenSSL (...)'. Using an existing example, "password and host-based authentications", i can formulate those features: - password authentication - host-based authentication In `./configure --disable-FEATURE` 'FEATURE' in order to make sense, has to refer to static definitions, which are likely to be one-word expressions. Thus most probably, neither "password authentication" nor "'password authentication'" as FEATURE would be valid. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug.
https://bugzilla.mindrot.org/show_bug.cgi?id=3461 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |djm at mindrot.org --- Comment #3 from Damien Miller <djm at mindrot.org> --- The configure script is only used when building OpenSSH from source. It is never included in OS packages, like the Fedora ones you seem to be using. If you want to make compile-time changes, then you need to be working with the source and not your compiled OS packages. Fortunately, you don't need to do this to achieve your stated goal of disabling particular authentication methods. These are fully controllable via the run-time configuration. See the various *authentication options in your ssh_config and sshd_config manpages. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug.
https://bugzilla.mindrot.org/show_bug.cgi?id=3461 --- Comment #4 from ricky.tigg at gmail.com --- I ended to doubt that my original intention to install OpenSSH from code source is even a suitable practise. A new evaluation made me consider that the attempt might be risky. My original motivation to get the latest OpenSSH version within my system was solely conducted by having issues addressed ?among them the ones security-related. Functionalities newly added were not part of my motivation. I realised - that changes related to fixes are back-ported by the distribution i use. - that the 'configure' script may point to /usr by default, which as result would overwrite the core SSH implementation bundled with my distribution. If it does, that would not be a recommended way to start off. - that executing 'make install' as root would likely overwrite the Fedora supplied packaged versions of those files. In that context it certainly appears wiser to leave my project undone. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug.
https://bugzilla.mindrot.org/show_bug.cgi?id=3461 --- Comment #5 from ricky.tigg at gmail.com --- I ended to doubt that my original intention to install OpenSSH from code source is even a suitable practise. A new evaluation made me consider that the attempt might be risky. My original motivation to get the latest OpenSSH version within my system was solely conducted by having issues addressed ?among them the ones security-related. Functionalities newly added were not part of my motivation. I realised - that changes related to fixes are back-ported by the distribution i use. - that the 'configure' script may point to /usr by default, which as result would overwrite the core SSH implementation bundled with my distribution. If it does, that would not be a recommended way to start off. - that executing 'make install' as root would likely overwrite the Fedora supplied packaged versions of those files. In that context it certainly appears wiser to leave my project undone. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug.
https://bugzilla.mindrot.org/show_bug.cgi?id=3461 Darren Tucker <dtucker at dtucker.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #6 from Darren Tucker <dtucker at dtucker.net> --- (In reply to ricky.tigg from comment #5)> - that the 'configure' script may point to /usr by default,configure defaults to putting everything under /usr/local.> - that executing 'make install' as root would likely overwrite the > Fedora supplied packaged versions of those files."make install" will not overwrite Fedora's files unless you explicitly specified a non-default path when running configure (eg --prefix). Anyway, I think we've clarified the docs as much as possible so closing this bug. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug.
https://bugzilla.mindrot.org/show_bug.cgi?id=3461 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #7 from Damien Miller <djm at mindrot.org> --- OpenSSH 9.3 has been released. Close resolved bugs -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug.