[Touch-packages] [Bug 2009230] Re: AppArmor denials for rsyslog
Hey Georgia! Sorry for the delay in writing back to you, I've been on a mix of PTO and sick leave the last couple of weeks... I've prepared a MP to actually add the relevant config snippet (`/dev/console rw,`) into `/etc/apparmor.d/usr.sbin.rsyslogd` in our cloud bootstrap, tested it and it all seems well. However, John (on our team) made a good point that the AppArmor profile may not have this snippet by design - I understand you guys in Security would probably have the most oversight into this currently so before I merge the code do you see any issues with us forcing the profile to accept rw access to /dev/console? If so that's cool, I just want to check seeing as this profile is only now being enabled in Lunar :) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/2009230 Title: AppArmor denials for rsyslog Status in gce-compute-image-packages package in Ubuntu: New Status in rsyslog package in Ubuntu: New Status in gce-compute-image-packages source package in Lunar: New Status in rsyslog source package in Lunar: New Bug description: The AppArmor profile for rsyslog, which had been disabled on previous Ubuntu versions, was enabled in lunar. The package google-compute-engine added a config file to rsyslog which requires rw access to /dev/console google:ubuntu-23.04-64 /root# cat /etc/rsyslog.d/90-google.conf # Google Compute Engine default console logging. # # daemon: logging from Google provided daemons. # kern: logging information in case of an unexpected crash during boot. # daemon,kern.* /dev/console google:ubuntu-23.04-64 /root# apt-file search /etc/rsyslog.d/90-google.conf google-compute-engine: /etc/rsyslog.d/90-google.conf So in gce cloud images, we are getting the following denials: [ 1500.302082] audit: type=1400 audit(1677876883.728:495): apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/dev/console" pid=603 comm=72733A6D61696E20513A526567 requested_mask="ac" denied_mask="ac" fsuid=101 ouid=0 To fix it, we just need to add /dev/console rw, to /etc/apparmor.d/usr.sbin.rsyslogd or the same permission should be added to a file in /etc/apparmor.d/rsyslog.d/ by the google-compute-engine package To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gce-compute-image-packages/+bug/2009230/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2009230] Re: AppArmor denials for rsyslog
Hey Georgia! Thank you for the report - this is certainly something we could do on our end in the cloud image. Let us do some testing to ensure no regressions are introduced doing this. I'll come back with more information soon. All the best, Chlo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/2009230 Title: AppArmor denials for rsyslog Status in gce-compute-image-packages package in Ubuntu: New Status in rsyslog package in Ubuntu: New Status in gce-compute-image-packages source package in Lunar: New Status in rsyslog source package in Lunar: New Bug description: The AppArmor profile for rsyslog, which had been disabled on previous Ubuntu versions, was enabled in lunar. The package google-compute-engine added a config file to rsyslog which requires rw access to /dev/console google:ubuntu-23.04-64 /root# cat /etc/rsyslog.d/90-google.conf # Google Compute Engine default console logging. # # daemon: logging from Google provided daemons. # kern: logging information in case of an unexpected crash during boot. # daemon,kern.* /dev/console google:ubuntu-23.04-64 /root# apt-file search /etc/rsyslog.d/90-google.conf google-compute-engine: /etc/rsyslog.d/90-google.conf So in gce cloud images, we are getting the following denials: [ 1500.302082] audit: type=1400 audit(1677876883.728:495): apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/dev/console" pid=603 comm=72733A6D61696E20513A526567 requested_mask="ac" denied_mask="ac" fsuid=101 ouid=0 To fix it, we just need to add /dev/console rw, to /etc/apparmor.d/usr.sbin.rsyslogd or the same permission should be added to a file in /etc/apparmor.d/rsyslog.d/ by the google-compute-engine package To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gce-compute-image-packages/+bug/2009230/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1981109] Re: server image pulls in ModemManager via fwupd, consumes 25MiB RAM in every container
Tested by building a GCE Jammy image using livecd-rootfs from the proposed pocket. I checked the package manifest of the build and can confirm that fwupd, modemmanager, and udisks2 are not installed. I won't change the "verification-needed-jammy" tag yet as the other clouds will be checked too. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1981109 Title: server image pulls in ModemManager via fwupd, consumes 25MiB RAM in every container Status in fwupd package in Ubuntu: Invalid Status in livecd-rootfs package in Ubuntu: Fix Released Status in modemmanager package in Ubuntu: Triaged Status in ubuntu-meta package in Ubuntu: New Status in fwupd source package in Jammy: Invalid Status in livecd-rootfs source package in Jammy: Fix Committed Status in modemmanager source package in Jammy: New Status in ubuntu-meta source package in Jammy: New Bug description: [Impact] Cloud images should not have fwupd, modemmanager, and udisks2 installed as those are not needed and only taking up memory. [Test Case] Build cloud images with livecd-rootfs and confirm that fwupd, modemmanager, and udisks2 are not present and not running. [Regression Potential] Only thing that might happen is for any of the 3 listed packages getting removed from images where they might be used. So possibly double-checking if this will affect preinstalled server images and if they care about this or not. [Original Description] Looking at memory utilization in a pristine Ubuntu lxd container (top -o RES), I see that ModemManager is running, which I was surprised to see is present at all in the stock image. Tracking this I find that fwupd depends on libmm-glib0, which in turn Recommends: modemmanager. Libraries in general should not recommend daemons, so it's possible this should be fixed by libmm-glib0 dropping this Recommends. It certainly doesn't seem to be a deliberate decision by the Server Team to have modemmanager installed and running by default on all systems. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1981109/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1952421] Re: Issue on sshd finds correct private key for a certificate when using ssh-agent
Apologies, I changed the tags *after* posting all the comments just to
make it more confusing...
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1952421
Title:
Issue on sshd finds correct private key for a certificate when using
ssh-agent
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Focal:
Fix Committed
Status in openssh source package in Hirsute:
Fix Committed
Status in openssh source package in Impish:
Fix Committed
Bug description:
Reported as https://bugzilla.mindrot.org/show_bug.cgi?id=3254 upstream
[Impact]
* HostCertificate and HostKeyAgent are not working together in sshd due
to a mismatched certificate's public key and private key. The function `
`sshkey_equal_public()`` incorrectly compares the certificate's public
key with a private key, never finding a match. The impact is that sshd
cannot use said certificate *even though* its private key is indeed in
ssh-agent.
* What it should do is compare the certificate's public key with a
public key in `sensitive_data`.
* Having this SRU-ed is a direct ask from one of the major cloud partners.
They are currently using a customised version of the package to work
around this issue, and we would like them to use a package directly from
our own archive.
* Looping through sensitive_data.host_pubkeys[j] *instead* of
sensitive_data.host_keys[j] fixes the issue
[https://github.com/openssh/openssh-portable/blob/V_8_4/sshd.c#L1936]
/* Find matching private key */
for (j = 0; j < options.num_host_key_files; j++) {
if (sshkey_equal_public(key,
sensitive_data.host_keys[j])) {
sensitive_data.host_certificates[j] = key;
break;
}
}
vs.
/* Find matching private key */
for (j = 0; j < options.num_host_key_files; j++) {
if (sshkey_equal_public(key,
sensitive_data.host_pubkeys[j])) {
sensitive_data.host_certificates[j] = key;
break;
}
}
[Test Plan]
* Due to the empirical nature of this bug, the test is quite straight
forward. *Without* the fix, one cannot use certificates to authenticate
successfully (e.g. ``sshd -c /path/to/certificate.pem``)
whereas with the fix (assuming the certificate matches a host key) you
can create a channel.
[Where problems could occur]
* This has already been fixed both upstream and in Jammy without issue.
However, if a regression where to happen it would probably be in one of
two ways:
* A dependency/reverse-dependency issue stemming from the version
bump that will happen if this fix is ported. We mitigate this risk
by testing for these exact types of regression,
and by selecting carefully what to label this new version.
* Accidentally breaking a set up that was made to work around this
bug in the first place. The risk of this is lower, as the most
likely fix is the one being implemented here anyway. Though
to mitigate this more we can describe exactly what is happening
with the fix in the changelog.
This affects every version of openssh back until Focal, at least.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1952421/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1952421] Re: Issue on sshd finds correct private key for a certificate when using ssh-agent
Impish verification
[INSTALLED PKG VERSION]
kajiya@chloe-HAL:~$ apt-cache policy openssh-server
openssh-server:
Installed: 1:8.4p1-6ubuntu2.1
Candidate: 1:8.4p1-6ubuntu2.1
Version table:
*** 1:8.4p1-6ubuntu2.1 400
400 http://gb.archive.ubuntu.com/ubuntu impish-proposed/main amd64
Packages
400 http://archive.ubuntu.com/ubuntu impish-proposed/main amd64 Packages
100 /var/lib/dpkg/status
1:8.4p1-6ubuntu2 500
500 http://gb.archive.ubuntu.com/ubuntu impish/main amd64 Packages
[PROCEDURE]
Create the keys/certs needed
``ssh-keygen -t rsa -b 4096 -f host_ca -C host_ca`` (no passphrase)
``ssh-keygen -f ssh_host_rsa_key -N '' -b 4096 -t rsa``
``ssh-keygen -s host_ca -I localhost -h -n localhost -V +52w
ssh_host_rsa_key.pub``
Copied ssh_host_rsa_key* files over to /etc/ssh and added the following to
/etc/ssh/sshd_config
``HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub``
Restarted sshd using systemctl and added ``@cert-authority localhost
ssh-rsa abcdefg`` (ssh-rsa abcdefg is the contents of host_ca.pub) to
~/.ssh/known_hosts
Finally, running
ssh -vv kajiya@localhost 2>&1 | grep "Server host certificate" gives
debug1: Server host certificate: ssh-rsa-cert-...@openssh.com
SHA256:pprTqBvT2oazgTsfPF+RD47ca/W1U4JCgq5fl7m1LkA, serial 0 ID "localhost" CA
ssh-rsa SHA256:l3PYuQBJMLruGeASt+BKEDGLDlk5NHx59cwW6/Qgzs4 valid from
2022-01-05T22:11:00 to 2023-01-04T22:12:07
debug2: Server host certificate hostname: localhost
which tells us the certificate was seen and used
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1952421
Title:
Issue on sshd finds correct private key for a certificate when using
ssh-agent
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Focal:
Fix Committed
Status in openssh source package in Hirsute:
Fix Committed
Status in openssh source package in Impish:
Fix Committed
Bug description:
Reported as https://bugzilla.mindrot.org/show_bug.cgi?id=3254 upstream
[Impact]
* HostCertificate and HostKeyAgent are not working together in sshd due
to a mismatched certificate's public key and private key. The function `
`sshkey_equal_public()`` incorrectly compares the certificate's public
key with a private key, never finding a match. The impact is that sshd
cannot use said certificate *even though* its private key is indeed in
ssh-agent.
* What it should do is compare the certificate's public key with a
public key in `sensitive_data`.
* Having this SRU-ed is a direct ask from one of the major cloud partners.
They are currently using a customised version of the package to work
around this issue, and we would like them to use a package directly from
our own archive.
* Looping through sensitive_data.host_pubkeys[j] *instead* of
sensitive_data.host_keys[j] fixes the issue
[https://github.com/openssh/openssh-portable/blob/V_8_4/sshd.c#L1936]
/* Find matching private key */
for (j = 0; j < options.num_host_key_files; j++) {
if (sshkey_equal_public(key,
sensitive_data.host_keys[j])) {
sensitive_data.host_certificates[j] = key;
break;
}
}
vs.
/* Find matching private key */
for (j = 0; j < options.num_host_key_files; j++) {
if (sshkey_equal_public(key,
sensitive_data.host_pubkeys[j])) {
sensitive_data.host_certificates[j] = key;
break;
}
}
[Test Plan]
* Due to the empirical nature of this bug, the test is quite straight
forward. *Without* the fix, one cannot use certificates to authenticate
successfully (e.g. ``sshd -c /path/to/certificate.pem``)
whereas with the fix (assuming the certificate matches a host key) you
can create a channel.
[Where problems could occur]
* This has already been fixed both upstream and in Jammy without issue.
However, if a regression where to happen it would probably be in one of
two ways:
* A dependency/reverse-dependency issue stemming from the version
bump that will happen if this fix is ported. We mitigate this risk
by testing for these exact types of regression,
and by selecting carefully what to label this new version.
* Accidentally breaking a set up that was made to work around this
bug in the first place. The risk of this is lower, as the most
likely fix is the one being implemented here anyway. Though
to mitigate this more we can describe exactly what is happening
with the fix in the changelog.
This affects every version of openssh back until Focal, at least.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1952421/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to :
[Touch-packages] [Bug 1952421] Re: Issue on sshd finds correct private key for a certificate when using ssh-agent
Focal verification
[INSTALLED PKG VERSION]
chlo@BIG-HAL:~$ apt-cache policy openssh-server
openssh-server:
Installed: 1:8.2p1-4ubuntu0.4
Candidate: 1:8.2p1-4ubuntu0.4
Version table:
*** 1:8.2p1-4ubuntu0.4 400
400 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages
100 /var/lib/dpkg/status
1:8.2p1-4ubuntu0.3 500
500 http://gb.archive.ubuntu.com/ubuntu focal-updates/main amd64
Packages
1:8.2p1-4ubuntu0.2 500
500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
1:8.2p1-4 500
500 http://gb.archive.ubuntu.com/ubuntu focal/main amd64 Packages
[PROCEDURE]
Create the keys/certs needed
``ssh-keygen -t rsa -b 4096 -f host_ca -C host_ca`` (no passphrase)
``ssh-keygen -f ssh_host_rsa_key -N '' -b 4096 -t rsa``
``ssh-keygen -s host_ca -I localhost -h -n localhost -V +52w
ssh_host_rsa_key.pub``
Copied ssh_host_rsa_key* files over to /etc/ssh and added the following to
/etc/ssh/sshd_config
``HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub``
Restarted sshd using systemctl and added ``@cert-authority localhost
ssh-rsa abcdefg`` (ssh-rsa abcdefg is the contents of host_ca.pub) to
~/.ssh/known_hosts
Finally, running
ssh -vv chlo@localhost 2>&1 | grep "Server"
debug1: Server host certificate: ssh-rsa-cert-...@openssh.com
SHA256:s2gq1xBSdetCarwElgQd0NbjJbiE3iLDxFtJqDhBFF4, serial 0 ID "localhost" CA
ssh-rsa SHA256:v8ZgezKD9Zw/Ns8I0W6mfvxCAo9jv3WznUYAFhfPfCU valid from
2022-01-05T22:46:00 to 2023-01-04T22:47:11
debug2: Server host certificate hostname: localhost
which tells us the certificate was seen and used
** Tags removed: verification-needed-hirsute verification-needed-impish
** Tags added: verification-done-hirsute verification-done-impish
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1952421
Title:
Issue on sshd finds correct private key for a certificate when using
ssh-agent
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Focal:
Fix Committed
Status in openssh source package in Hirsute:
Fix Committed
Status in openssh source package in Impish:
Fix Committed
Bug description:
Reported as https://bugzilla.mindrot.org/show_bug.cgi?id=3254 upstream
[Impact]
* HostCertificate and HostKeyAgent are not working together in sshd due
to a mismatched certificate's public key and private key. The function `
`sshkey_equal_public()`` incorrectly compares the certificate's public
key with a private key, never finding a match. The impact is that sshd
cannot use said certificate *even though* its private key is indeed in
ssh-agent.
* What it should do is compare the certificate's public key with a
public key in `sensitive_data`.
* Having this SRU-ed is a direct ask from one of the major cloud partners.
They are currently using a customised version of the package to work
around this issue, and we would like them to use a package directly from
our own archive.
* Looping through sensitive_data.host_pubkeys[j] *instead* of
sensitive_data.host_keys[j] fixes the issue
[https://github.com/openssh/openssh-portable/blob/V_8_4/sshd.c#L1936]
/* Find matching private key */
for (j = 0; j < options.num_host_key_files; j++) {
if (sshkey_equal_public(key,
sensitive_data.host_keys[j])) {
sensitive_data.host_certificates[j] = key;
break;
}
}
vs.
/* Find matching private key */
for (j = 0; j < options.num_host_key_files; j++) {
if (sshkey_equal_public(key,
sensitive_data.host_pubkeys[j])) {
sensitive_data.host_certificates[j] = key;
break;
}
}
[Test Plan]
* Due to the empirical nature of this bug, the test is quite straight
forward. *Without* the fix, one cannot use certificates to authenticate
successfully (e.g. ``sshd -c /path/to/certificate.pem``)
whereas with the fix (assuming the certificate matches a host key) you
can create a channel.
[Where problems could occur]
* This has already been fixed both upstream and in Jammy without issue.
However, if a regression where to happen it would probably be in one of
two ways:
* A dependency/reverse-dependency issue stemming from the version
bump that will happen if this fix is ported. We mitigate this risk
by testing for these exact types of regression,
and by selecting carefully what to label this new version.
* Accidentally breaking a set up that was made to work around this
bug in the first place. The risk of this is lower, as the most
likely fix is the one being implemented here anyway. Though
to mitigate this more we can describe exactly what is happening
with the fix in the changelog.
This affects every version of
[Touch-packages] [Bug 1952421] Re: Issue on sshd finds correct private key for a certificate when using ssh-agent
Hirsute verification
[INSTALLED PKG VERSION]
kajiya@chloe-HAL:~/Documents/work$ apt-cache policy openssh-server
openssh-server:
Installed: 1:8.4p1-5ubuntu1.2
Candidate: 1:8.4p1-5ubuntu1.2
Version table:
*** 1:8.4p1-5ubuntu1.2 500
500 http://gb.archive.ubuntu.com/ubuntu hirsute-proposed/main amd64
Packages
500 http://archive.ubuntu.com/ubuntu hirsute-proposed/main amd64
Packages
100 /var/lib/dpkg/status
1:8.4p1-5ubuntu1.1 500
500 http://gb.archive.ubuntu.com/ubuntu hirsute-updates/main amd64
Packages
1:8.4p1-5ubuntu1 500
500 http://gb.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages
[PROCEDURE]
Create the keys/certs needed
``ssh-keygen -t rsa -b 4096 -f host_ca -C host_ca`` (no passphrase)
``ssh-keygen -f ssh_host_rsa_key -N '' -b 4096 -t rsa``
``ssh-keygen -s host_ca -I localhost -h -n localhost -V +52w
ssh_host_rsa_key.pub``
Copied ssh_host_rsa_key* files over to /etc/ssh and added the following to
/etc/ssh/sshd_config
``HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub``
Restarted sshd using systemctl and added ``@cert-authority localhost
ssh-rsa abcdefg`` (ssh-rsa abcdefg is the contents of host_ca.pub) to
~/.ssh/known_hosts
Finally, running
``ssh -vv localhost 2>&1 | grep "Server host certificate"`` gives
ssh -vv kajiya@localhost 2>&1 | grep "Server host certificate"
debug1: Server host certificate: ssh-rsa-cert-...@openssh.com
SHA256:ufStWAPad1IQ08xMPM1iF4u4JHEaeAuQcD3qoe8yJ9A, serial 0 ID "localhost" CA
ssh-rsa SHA256:3iVQ6wcBeoRO3S12jO8K34Do8HbVTPxiBp3rNzCngGc valid from
2022-01-05T17:20:00 to 2023-01-04T17:21:17
debug2: Server host certificate hostname: localhost
which tells us the certificate was seen and used
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1952421
Title:
Issue on sshd finds correct private key for a certificate when using
ssh-agent
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Focal:
Fix Committed
Status in openssh source package in Hirsute:
Fix Committed
Status in openssh source package in Impish:
Fix Committed
Bug description:
Reported as https://bugzilla.mindrot.org/show_bug.cgi?id=3254 upstream
[Impact]
* HostCertificate and HostKeyAgent are not working together in sshd due
to a mismatched certificate's public key and private key. The function `
`sshkey_equal_public()`` incorrectly compares the certificate's public
key with a private key, never finding a match. The impact is that sshd
cannot use said certificate *even though* its private key is indeed in
ssh-agent.
* What it should do is compare the certificate's public key with a
public key in `sensitive_data`.
* Having this SRU-ed is a direct ask from one of the major cloud partners.
They are currently using a customised version of the package to work
around this issue, and we would like them to use a package directly from
our own archive.
* Looping through sensitive_data.host_pubkeys[j] *instead* of
sensitive_data.host_keys[j] fixes the issue
[https://github.com/openssh/openssh-portable/blob/V_8_4/sshd.c#L1936]
/* Find matching private key */
for (j = 0; j < options.num_host_key_files; j++) {
if (sshkey_equal_public(key,
sensitive_data.host_keys[j])) {
sensitive_data.host_certificates[j] = key;
break;
}
}
vs.
/* Find matching private key */
for (j = 0; j < options.num_host_key_files; j++) {
if (sshkey_equal_public(key,
sensitive_data.host_pubkeys[j])) {
sensitive_data.host_certificates[j] = key;
break;
}
}
[Test Plan]
* Due to the empirical nature of this bug, the test is quite straight
forward. *Without* the fix, one cannot use certificates to authenticate
successfully (e.g. ``sshd -c /path/to/certificate.pem``)
whereas with the fix (assuming the certificate matches a host key) you
can create a channel.
[Where problems could occur]
* This has already been fixed both upstream and in Jammy without issue.
However, if a regression where to happen it would probably be in one of
two ways:
* A dependency/reverse-dependency issue stemming from the version
bump that will happen if this fix is ported. We mitigate this risk
by testing for these exact types of regression,
and by selecting carefully what to label this new version.
* Accidentally breaking a set up that was made to work around this
bug in the first place. The risk of this is lower, as the most
likely fix is the one being implemented here anyway. Though
to mitigate this more we can describe exactly what is happening
with the fix in the changelog.
This affects every version of openssh back until Focal, at least.
To
[Touch-packages] [Bug 1952421] Re: Issue on sshd finds correct private key for a certificate when using ssh-agent
Hey everyone,
I can confirm the fix has been tested by our friends at Google (Anthos) for
Focal 20.04, using the same patch used in 1:8.2p1-4ubuntu0.4 but *not* by using
the package from focal-proposed itself.
Hopefully this still suffices? Please let me know if not and I'll re-run the
verification again using an instance pulling from focal-proposed.
[RATIONALE]
Need SSH to authenticate a ``HostCertificate`` and an SSH agent that
holds the corresponding host private key.
The sshd_config has the following directives:
-- HostCertificate the public host certificate whose public key matches
the private key stored in the ssh agent
-- HostKey the public key of the host keypair
-- HostKeyAgent the socket of the ssh agent that holds the host private
key
Before the patch, this combination didn't work - even though it
authenticated successfully the setup behaved as if ``HostCertificate``
was never configured (i.e. it authenticated using only the public key
and the private key in the ssh agent).
[VERIFICATION OF FIX]
sh-agent -a /path/agent-socket
SSH_AUTH_SOCK=/path/agent-socket ssh-add -k /path/hostkey
Then ran ``sshd`` with:
HostCertificate /path/hostkey-cert.pub
HostKey /path/hostkey.pub
HostKeyAgent /path/agent-socket
Then configured the CA trust anchor on the client's side.
(localhost was used, but it would be the same if a second host is used as a
client)
ssh -vv localhost
shows the host certificate was seen and used.
** Tags removed: verification-needed-focal
** Tags added: verification-done-focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1952421
Title:
Issue on sshd finds correct private key for a certificate when using
ssh-agent
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Focal:
Fix Committed
Status in openssh source package in Hirsute:
Fix Committed
Status in openssh source package in Impish:
Fix Committed
Bug description:
Reported as https://bugzilla.mindrot.org/show_bug.cgi?id=3254 upstream
[Impact]
* HostCertificate and HostKeyAgent are not working together in sshd due
to a mismatched certificate's public key and private key. The function `
`sshkey_equal_public()`` incorrectly compares the certificate's public
key with a private key, never finding a match. The impact is that sshd
cannot use said certificate *even though* its private key is indeed in
ssh-agent.
* What it should do is compare the certificate's public key with a
public key in `sensitive_data`.
* Having this SRU-ed is a direct ask from one of the major cloud partners.
They are currently using a customised version of the package to work
around this issue, and we would like them to use a package directly from
our own archive.
* Looping through sensitive_data.host_pubkeys[j] *instead* of
sensitive_data.host_keys[j] fixes the issue
[https://github.com/openssh/openssh-portable/blob/V_8_4/sshd.c#L1936]
/* Find matching private key */
for (j = 0; j < options.num_host_key_files; j++) {
if (sshkey_equal_public(key,
sensitive_data.host_keys[j])) {
sensitive_data.host_certificates[j] = key;
break;
}
}
vs.
/* Find matching private key */
for (j = 0; j < options.num_host_key_files; j++) {
if (sshkey_equal_public(key,
sensitive_data.host_pubkeys[j])) {
sensitive_data.host_certificates[j] = key;
break;
}
}
[Test Plan]
* Due to the empirical nature of this bug, the test is quite straight
forward. *Without* the fix, one cannot use certificates to authenticate
successfully (e.g. ``sshd -c /path/to/certificate.pem``)
whereas with the fix (assuming the certificate matches a host key) you
can create a channel.
[Where problems could occur]
* This has already been fixed both upstream and in Jammy without issue.
However, if a regression where to happen it would probably be in one of
two ways:
* A dependency/reverse-dependency issue stemming from the version
bump that will happen if this fix is ported. We mitigate this risk
by testing for these exact types of regression,
and by selecting carefully what to label this new version.
* Accidentally breaking a set up that was made to work around this
bug in the first place. The risk of this is lower, as the most
likely fix is the one being implemented here anyway. Though
to mitigate this more we can describe exactly what is happening
with the fix in the changelog.
This affects every version of openssh back until Focal, at least.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1952421/+subscriptions
--
Mailing list:
[Touch-packages] [Bug 1952421] Re: Issue on sshd finds correct private key for a certificate when using ssh-agent
** Description changed:
- Reported as https://bugzilla.mindrot.org/show_bug.cgi?id=3254 upstream:
+ Reported as https://bugzilla.mindrot.org/show_bug.cgi?id=3254 upstream
- Please take a look at line 1936 in main() function in sshd.c.
+ [Impact]
+
+ * HostCertificate and HostKeyAgent are not working together in sshd due
+to a mismatched certificate's public key and private key. The function `
`sshkey_equal_public()`` incorrectly compares the certificate's public
+ key with a private key, never finding a match. The impact is that sshd
+ cannot use said certificate *even though* its private key is indeed in
+ ssh-agent.
+
+ * What it should do is compare the certificate's public key with a
+ public key in `sensitive_data`.
+
+ * Having this SRU-ed is a direct ask from one of the major cloud partners.
+ They are currently using a customised version of the package to work
+ around this issue, and we would like them to use a package directly from
+ our own archive.
+
+ * Looping through sensitive_data.host_pubkeys[j] *instead* of
+sensitive_data.host_keys[j] fixes the issue
+
+ [https://github.com/openssh/openssh-portable/blob/V_8_4/sshd.c#L1936]
/* Find matching private key */
- for (j = 0; j < options.num_host_key_files; j++) {
- if (sshkey_equal_public(key,
- sensitive_data.host_keys[j])) {
- sensitive_data.host_certificates[j] = key;
- break;
- }
- }
+ for (j = 0; j < options.num_host_key_files; j++) {
+ if (sshkey_equal_public(key,
+ sensitive_data.host_keys[j])) {
+ sensitive_data.host_certificates[j] = key;
+ break;
+ }
+ }
- the sshkey_equal_public() is trying to compare a cert's pub with a private
key, and it never find a match which makes sshd cannot use this certificate
even though its private key is in ssh-agent.
- I believe it should be comparing a cert's public key with a public key in
sensitive_data as follow.
+ vs.
/* Find matching private key */
- for (j = 0; j < options.num_host_key_files; j++) {
- if (sshkey_equal_public(key,
- sensitive_data.host_pubkeys[j])) {
- sensitive_data.host_certificates[j] = key;
- break;
- }
- }
+ for (j = 0; j < options.num_host_key_files; j++) {
+ if (sshkey_equal_public(key,
+ sensitive_data.host_pubkeys[j])) {
+ sensitive_data.host_certificates[j] = key;
+ break;
+ }
+ }
+
- https://github.com/openssh/openssh-portable/blob/V_8_4/sshd.c#L1936
+ [Test Plan]
- Due to this HostCertificate and HostKeyAgent not working together in
- sshd and this affects every version of openssh back till Focal, at
- least.
+ * Due to the empirical nature of this bug, the test is quite straight
+forward. *Without* the fix, one cannot use certificates to authenticate
+successfully (e.g. ``sshd -c /path/to/certificate.pem``)
+whereas with the fix (assuming the certificate matches a host key) you
+can create a channel.
+
+ [Where problems could occur]
+
+ * This has already been fixed both upstream and in Jammy without issue.
+However, if a regression where to happen it would probably be in one of
+two ways:
+
+ * A dependency/reverse-dependency issue stemming from the version
+bump that will happen if this fix is ported. We mitigate this risk
+by testing for these exact types of regression,
+and by selecting carefully what to label this new version.
+
+ * Accidentally breaking a set up that was made to work around this
+bug in the first place. The risk of this is lower, as the most
+likely fix is the one being implemented here anyway. Though
+to mitigate this more we can describe exactly what is happening
+with the fix in the changelog.
+
+
+ This affects every version of openssh back until Focal, at least.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1952421
Title:
Issue on sshd finds correct private key for a certificate when using
ssh-agent
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Focal:
New
Status in openssh source package in Hirsute:
New
Status in openssh source package in Impish:
New
Bug description:
Reported as https://bugzilla.mindrot.org/show_bug.cgi?id=3254 upstream
[Impact]
* HostCertificate and HostKeyAgent are not working together in sshd due
to a mismatched certificate's public key and private key. The function `
`sshkey_equal_public()`` incorrectly compares the certificate's public
key with a private key, never finding a match. The impact is that sshd
cannot use said certificate *even though* its
