Bug 3461 - General observations
Summary: General observations
Status: CLOSED WORKSFORME
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: Miscellaneous (show other bugs)
Version: 9.0p1
Hardware: Other Linux
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords: help-wanted
Depends on:
Blocks:
 
Reported: 2022-07-13 22:27 AEST by ricky.tigg
Modified: 2023-03-17 13:41 AEDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ricky.tigg 2022-07-13 22:27:21 AEST
**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.
Comment 1 Darren Tucker 2022-07-14 09:55:41 AEST
(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?
Comment 2 ricky.tigg 2022-07-14 23:03:59 AEST
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.
Comment 3 Damien Miller 2022-11-17 14:12:16 AEDT
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.
Comment 4 ricky.tigg 2022-11-17 22:32:03 AEDT
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.
Comment 5 ricky.tigg 2022-11-17 22:34:57 AEDT
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.
Comment 6 Darren Tucker 2022-12-16 15:47:23 AEDT
(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.
Comment 7 Damien Miller 2023-03-17 13:41:52 AEDT
OpenSSH 9.3 has been released. Close resolved bugs