[Touch-packages] [Bug 1847902] Re: pam_nologin should optionally exclude users of the "wheel" group from its access restrictions
Just locked out of an AWS machine again due to this bug. Any news on a fix? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1847902 Title: pam_nologin should optionally exclude users of the "wheel" group from its access restrictions Status in pam package in Ubuntu: Confirmed Bug description: During a remote system upgrade (18.04 to 19.04) something went south and after reboot the machine is stuck at some place in its boot sequence. SSH works, but trying to log-in with a sudo-capable user results in: "System is booting up. Unprivileged users are not permitted to log in yet. Please come back later. For technical details, see pam_nologin(8)." As Ubuntu has moved away from full root users with passwords + allowing root logins over SSH, I'm totally locked out from my remote system. There is a bug reported for pam_nologin requesting to provide separate exclusion mechanism but in the meantime it is possible to implement a workaround to exclude administrative users from nologin restriction. Here's the bug: https://github.com/linux-pam/linux-pam/issues/42 And here is the workaround that should be implemented in Ubuntu: https://github.com/linux-pam/linux-pam/issues/42#issuecomment-367450193 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1847902/+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 1668944] Re: The _apt user ignores group membership.
Dictating to people what their PKI policy should be is outside the scope of apt. Apt must behave properly as per standard unix behaviour, with a proper working user and a proper working group. Trying to dictate directory permissions to people breaks automation, breaks orchestration, and makes it really hard to convince people to do security properly. Please fix this. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1668944 Title: The _apt user ignores group membership. Status in apt package in Ubuntu: Invalid Bug description: Actually I had the same problem described in http://askubuntu.com/questions/773955/apt-get-ssl-client-certificate-not-working-on-16-04-error-while-reading-file I want to use client certificates with apt. But I don't want to make them world readable in order to make apt working. So I created a group 'ssl-cert' and changed the group ownership of the ssl cert files to match this group. I also added the _apt user to the ssl-cert group. Then I tried to open these files as user '_apt' in bash (su -s /bin/bash _apt) which works well. But if I run: "apt-get -o "Debug::Acquire::https=true" update" I still get the following error: * error reading ca cert file /etc/certs/mycert/ca.pem (Error while reading file.) * Closing connection 26 So my guess is that apt somehow ignores the ssl-cert membership. Possible workarounds: - make ssl client cert world readable - change owner ssl client cert to _apt - change main group of _apt user from 'nogroup' to 'ssl-cert' - set APT::Sandbox::User "root"; in apt.conf.d Neither of them is pretty. Maybe this is a wanted behavior, then just suggest how to fix the issue in nice way. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1668944/+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 815562] Re: Difficult to know why we can't find signing_key_fingerprint for a PPA
9 years later and this bug is still unfixed when building from Bionic. The error Error: signing key fingerprint does not exist Failed to add key. might be a statement of fact, but it doesn't tell me what I must do, or whether my system is broken or not, or what action I must take. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/815562 Title: Difficult to know why we can't find signing_key_fingerprint for a PPA Status in software-properties package in Ubuntu: Confirmed Bug description: I've created a PPA, but I haven't uploaded anything yet. On my development machine I tried to add the PPA using apt-apt-repository and I got the following error message: «Error: can't find signing_key_fingerprint at https://launchpad.net/api/1.0/~joerlend.schinstad/+archive/testing» I thought I'd done something wrong, so I asked in #Launchpad where it was explained to me that keys aren't generated until the first upload. That sounds reasonable, but I think it should be easier to know why add-apt-repository fails. I also think it should be explained in pages like this one: https://help.launchpad.net/Packaging/PPA/InstallingSoftware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/815562/+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 1650634] Re: when installing systemd, it creates /run/nologin preventing all users from logging in.
Deploy Ubuntu Bionic machine from AWS, try and log in: "System is booting up. See pam_nologin(8)" Given it is impossible to log in, it's impossible to see what's wrong, or fix it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1650634 Title: when installing systemd, it creates /run/nologin preventing all users from logging in. Status in systemd: New Status in systemd package in Ubuntu: Confirmed Status in systemd package in Suse: Unknown Bug description: How to replicate: sudo apt-get install systemd wait for 5 minutes check to see if /run/nologin appears. If it does the bug is present. See https://ubuntuforums.org/showthread.php?t=2327330 I ran this command via ansible on all of my servers. Then I could no longer log into any of them. Pretty big bug in my opinion. Please fix. -Tim ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: systemd 204-5ubuntu20.20 ProcVersionSignature: Ubuntu 3.13.0-105.152-generic 3.13.11-ckt39 Uname: Linux 3.13.0-105-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.23 Architecture: amd64 CurrentDesktop: KDE Date: Fri Dec 16 12:03:55 2016 InstallationDate: Installed on 2014-04-21 (970 days ago) InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1650634/+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 1762766] Re: apt-get update hangs when apt-transport-https is not installed
In our case it burned a number of days of dev time, so this is definitely causing pain. We've never seen this before because until docker, we have not encountered a system where apt-transport-https wasn't installed by default. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1762766 Title: apt-get update hangs when apt-transport-https is not installed Status in apt package in Ubuntu: Fix Released Status in apt source package in Trusty: Triaged Status in apt source package in Xenial: Triaged Status in apt package in Debian: Fix Released Bug description: When "apt-get update" is run on a docker container running Ubuntu v16.04 and containing an additional apt source repository hosted on an https webserver, the "apt-get update" command hangs. The hang happens after connections to http ubuntu hosts are complete, and apt-get remains stuck on "Working" at 0%. Removing the sources file for the https repo causes apt-get to complete normally. The source file contains 4 separate entries to 4 different repos on the same https server. When the source file is modified so that just *one* entry exists to one repo on the https server, we suddenly get a sensible error message that tells us that apt-transport-https needs to be installed. Installing apt-transport-https into the docker container before adding the sources list to the https servers works around the problem and sanity returns. Key notes: - The use of docker isn't related to the bug, except that the docker image doesn't contain the apt-transport-https package whereas our cloud images do contain this package by default. This can give the impression that this is a docker bug when it's not. - The hang in "apt-get update" seems to occur when the sources file contains more than one entry in the file. When just one entry exists in the file (and all other entries are commented out) a sensible error messages appears. - We encountered this on a host that didn't support cut and paste, sorry :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1762766/+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 1762766] Re: apt-get update hangs when apt-transport-https is not installed
Is it possible to backport this to trusty too? This bit us hard, and there are a lot of people out there posting this problem but with no solution. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1762766 Title: apt-get update hangs when apt-transport-https is not installed Status in apt package in Ubuntu: Fix Released Status in apt source package in Xenial: Triaged Status in apt package in Debian: Fix Released Bug description: When "apt-get update" is run on a docker container running Ubuntu v16.04 and containing an additional apt source repository hosted on an https webserver, the "apt-get update" command hangs. The hang happens after connections to http ubuntu hosts are complete, and apt-get remains stuck on "Working" at 0%. Removing the sources file for the https repo causes apt-get to complete normally. The source file contains 4 separate entries to 4 different repos on the same https server. When the source file is modified so that just *one* entry exists to one repo on the https server, we suddenly get a sensible error message that tells us that apt-transport-https needs to be installed. Installing apt-transport-https into the docker container before adding the sources list to the https servers works around the problem and sanity returns. Key notes: - The use of docker isn't related to the bug, except that the docker image doesn't contain the apt-transport-https package whereas our cloud images do contain this package by default. This can give the impression that this is a docker bug when it's not. - The hang in "apt-get update" seems to occur when the sources file contains more than one entry in the file. When just one entry exists in the file (and all other entries are commented out) a sensible error messages appears. - We encountered this on a host that didn't support cut and paste, sorry :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1762766/+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 1762766] [NEW] apt-get update hangs when apt-transport-https is not installed
Public bug reported: When "apt-get update" is run on a docker container running Ubuntu v16.04 and containing an additional apt source repository hosted on an https webserver, the "apt-get update" command hangs. The hang happens after connections to http ubuntu hosts are complete, and apt-get remains stuck on "Working" at 0%. Removing the sources file for the https repo causes apt-get to complete normally. The source file contains 4 separate entries to 4 different repos on the same https server. When the source file is modified so that just *one* entry exists to one repo on the https server, we suddenly get a sensible error message that tells us that apt-transport-https needs to be installed. Installing apt-transport-https into the docker container before adding the sources list to the https servers works around the problem and sanity returns. Key notes: - The use of docker isn't related to the bug, except that the docker image doesn't contain the apt-transport-https package whereas our cloud images do contain this package by default. This can give the impression that this is a docker bug when it's not. - The hang in "apt-get update" seems to occur when the sources file contains more than one entry in the file. When just one entry exists in the file (and all other entries are commented out) a sensible error messages appears. - We encountered this on a host that didn't support cut and paste, sorry :( ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Summary changed: - apt-get update hangs when apt-transport-https is no installed + apt-get update hangs when apt-transport-https is not installed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1762766 Title: apt-get update hangs when apt-transport-https is not installed Status in apt package in Ubuntu: New Bug description: When "apt-get update" is run on a docker container running Ubuntu v16.04 and containing an additional apt source repository hosted on an https webserver, the "apt-get update" command hangs. The hang happens after connections to http ubuntu hosts are complete, and apt-get remains stuck on "Working" at 0%. Removing the sources file for the https repo causes apt-get to complete normally. The source file contains 4 separate entries to 4 different repos on the same https server. When the source file is modified so that just *one* entry exists to one repo on the https server, we suddenly get a sensible error message that tells us that apt-transport-https needs to be installed. Installing apt-transport-https into the docker container before adding the sources list to the https servers works around the problem and sanity returns. Key notes: - The use of docker isn't related to the bug, except that the docker image doesn't contain the apt-transport-https package whereas our cloud images do contain this package by default. This can give the impression that this is a docker bug when it's not. - The hang in "apt-get update" seems to occur when the sources file contains more than one entry in the file. When just one entry exists in the file (and all other entries are commented out) a sensible error messages appears. - We encountered this on a host that didn't support cut and paste, sorry :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1762766/+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 1612711] Re: TLS negation fails
More details. The ClientHello packet in this case is larger than 255 bytes, and is triggering the handshake failure in one of two ways. When psql linked to openssl v1.0.1f attempts to connect to postgresql linked to openssl v1.0.1f, the client side sends 8 bytes, then 1 byte, then 305 bytes in my case: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 11:51:45.113996 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [S], seq 3580373978, win 26883, options [mss 8961,sackOK,TS val 12226525 ecr 0,nop,wscale 7], length 0 11:51:45.114035 IP 172.29.228.240.5432 > 172.29.231.43.40454: Flags [S.], seq 3310545722, ack 3580373979, win 26847, options [mss 8961,sackOK,TS val 12327573 ecr 12226525,nop,wscale 7], length 0 11:51:45.114243 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [.], ack 1, win 211, options [nop,nop,TS val 12226525 ecr 12327573], length 0 11:51:45.114271 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [P.], seq 1:9, ack 1, win 211, options [nop,nop,TS val 12226525 ecr 12327573], length 8 11:51:45.114277 IP 172.29.228.240.5432 > 172.29.231.43.40454: Flags [.], ack 9, win 210, options [nop,nop,TS val 12327573 ecr 12226525], length 0 11:51:45.114934 IP 172.29.228.240.5432 > 172.29.231.43.40454: Flags [P.], seq 1:2, ack 9, win 210, options [nop,nop,TS val 12327574 ecr 12226525], length 1 11:51:45.115132 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [.], ack 2, win 211, options [nop,nop,TS val 12226525 ecr 12327574], length 0 11:51:45.117703 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [P.], seq 9:314, ack 2, win 211, options [nop,nop,TS val 12226526 ecr 12327574], length 305 11:51:45.119459 IP 172.29.228.240.5432 > 172.29.231.43.40454: Flags [P.], seq 2:3941, ack 314, win 219, options [nop,nop,TS val 12327575 ecr 12226526], length 3939 11:51:45.120234 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [P.], seq 314:321, ack 3941, win 350, options [nop,nop,TS val 12226526 ecr 12327575], length 7 11:51:45.120324 IP 172.29.231.43.40454 > 172.29.228.240.5432: Flags [R.], seq 321, ack 3941, win 350, options [nop,nop,TS val 12226526 ecr 12327575], length 0 The openssl v1.0.1f server side responds with a ServerHello, however the client side rejects the ServerHello saying "unknown ca", even though this same set of certificates works fine in Ubuntu Trusty. In a second test, if I use openssl v1.0.2m compiled from source to connect to the same server, the client side sends 308 bytes in one go: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 11:53:02.032126 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [S], seq 1471313029, win 26883, options [mss 8961,sackOK,TS val 645036074 ecr 0,nop,wscale 7], length 0 11:53:02.032165 IP 172.29.228.240.5432 > 172.29.228.7.54912: Flags [S.], seq 126514461, ack 1471313030, win 26847, options [mss 8961,sackOK,TS val 12346803 ecr 645036074,nop,wscale 7], length 0 11:53:02.032490 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [.], ack 1, win 211, options [nop,nop,TS val 645036074 ecr 12346803], length 0 11:53:02.039507 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [P.], seq 1:309, ack 1, win 211, options [nop,nop,TS val 645036076 ecr 12346803], length 308 11:53:02.039521 IP 172.29.228.240.5432 > 172.29.228.7.54912: Flags [.], ack 309, win 219, options [nop,nop,TS val 12346805 ecr 645036076], length 0 11:53:02.040625 IP 172.29.228.240.5432 > 172.29.228.7.54912: Flags [F.], seq 1, ack 309, win 219, options [nop,nop,TS val 12346805 ecr 645036076], length 0 11:53:02.041682 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [.], ack 2, win 211, options [nop,nop,TS val 645036077 ecr 12346805], length 0 11:53:02.049476 IP 172.29.228.7.54912 > 172.29.228.240.5432: Flags [F.], seq 309, ack 2, win 211, options [nop,nop,TS val 645036078 ecr 12346805], length 0 11:53:02.049492 IP 172.29.228.240.5432 > 172.29.228.7.54912: Flags [.], ack 310, win 219, options [nop,nop,TS val 12346807 ecr 645036078], length 0 In this case the postgresql linked to openssl v1.0.1f immediately slams the phone down after the initial ClientHello, leading to the "SSL handshake has read 0 bytes" in the openssl client side. It appears openssl v1.0.1f has a bug where ClientHello greater than 255 bytes causes the handshake to fail without accurately logging the cause. In my case this is a regression from Ubuntu Trusty, where the identical setup and certificates work fine. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1612711 Title: TLS negation fails Status in openssl package in Ubuntu: Confirmed Bug description: This seems like a duplicate of #965371, however that is marked fixed, so I don't know. I'm running 16.04.1. I'm setting up OpenLDAP with TLS. I've followed the instructions at https://help.ubuntu.com/lts/serverguide/openldap-
[Touch-packages] [Bug 1305175] Re: openssl 1.0.1f 'ssl handshake failure' connection failure
I've also slammed headlong into this one. The clue is "SSL handshake has read 0 bytes and written 317 bytes" What the openssl v1.0.1f client side is doing is sending a clienthello packet larger than 255 bytes to a broken SSL implementation, which slams the phone down on you, thus "read 0 bytes". The openssl client side errors handling is currently broken, and does not clearly indicate that the connection was dropped, just the vague message that a handshake failure occurred (I've logged this bug here: https://github.com/openssl/openssl/issues/4706) The suggestion to limit the list of ciphers to just two works around the problem because the clienthello is vastly reduced in size. Obviously this works where your chosen ciphers are accepted by the server, but won't work with the same confusingly identical error message when the ciphers are not supported by the server. The tangent about MD5 above, while true, has nothing whatsoever to do with this bug. It looks like the default cipher list on the client side has grown way too long, and when an application offers no control over the cipher list this breaks connections to buggy SSL servers. Turns out one such buggy SSL server implementation is openssl v1.0.1f as supplied by Ubuntu Xenial, that is covered here: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1612711 As to this client side bug, we need to figure out how to ensure the default cipher list stays well below the 255 byte limit, especially since the SNI header has to fit inside 255 bytes too. ** Bug watch added: github.com/openssl/openssl/issues #4706 https://github.com/openssl/openssl/issues/4706 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1305175 Title: openssl 1.0.1f 'ssl handshake failure' connection failure Status in openssl package in Ubuntu: Confirmed Bug description: When attempting 'curl' or 'openssl s_client' I have been getting "error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure" openssl version OpenSSL 1.0.1f 6 Jan 2014 examples: ```Normal connect # openssl s_client -connect centinel1000.cardinalcommerce.com:443 -showcerts CONNECTED(0003) 140148901013152:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 317 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- ```Explicit SSLv3 # openssl s_client -connect centinel1000.cardinalcommerce.com:443 -showcerts -ssl3 CONNECTED(0003) depth=2 C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=US/ST=Ohio/L=Mentor/O=CardinalCommerce Corporation/CN=*.cardinalcommerce.com i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA -BEGIN CERTIFICATE- MIIEqjCCA5KgAwIBAgIQfI2U+db8heb8kd3m/BmmITANBgkqhkiG9w0BAQUFADA8 MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMVGhhd3RlLCBJbmMuMRYwFAYDVQQDEw1U aGF3dGUgU1NMIENBMB4XDTEzMDMxOTAwMDAwMFoXDTE1MDQxODIzNTk1OVowdTEL MAkGA1UEBhMCVVMxDTALBgNVBAgTBE9oaW8xDzANBgNVBAcUBk1lbnRvcjElMCMG A1UEChQcQ2FyZGluYWxDb21tZXJjZSBDb3Jwb3JhdGlvbjEfMB0GA1UEAxQWKi5j YXJkaW5hbGNvbW1lcmNlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMUnIwZ0yEJa80hN4sta/wbr04ogq9XwlY7V7iWiLlfoP/wfpccPt/282+AN oySwuxMWE5EPHC54WXjCowoj3Kdq7fuH11R6DBoXGfuhIJ9l9L187hEPPk6bLq3H F1diHFxGYT0zCNshm7w7Qe/LmQ8N0WSUs21KuB/WZxEts7sIYi4xY/Ig1Mbt6dVV z3w3mfSqpXmdZa5ht7/QUEy3/04uGlSXAN01BVmxHbZeM5epocUCt/TwhtUzRb+N 9S4VEe3kzP8Oz8Wphg1CueP5yH9nRQTzLct5wCBC5+N+RjdadhuRm4FPgbsO+sX4 LHQ1jgE6CTqYquyYAeXuvdOqz6kCAwEAAaOCAW0wggFpMCEGA1UdEQQaMBiCFiou Y2FyZGluYWxjb21tZXJjZS5jb20wCQYDVR0TBAIwADBCBgNVHSAEOzA5MDcGCmCG SAGG+EUBBzYwKTAnBggrBgEFBQcCARYbaHR0cHM6Ly93d3cudGhhd3RlLmNvbS9j cHMvMA4GA1UdDwEB/wQEAwIFoDAfBgNVHSMEGDAWgBSnooO7NEVAPfzVME8SuT6h AZ/22zA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vc3ZyLW92LWNybC50aGF3dGUu Y29tL1RoYXd0ZU9WLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIw aQYIKwYBBQUHAQEEXTBbMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC50aGF3dGUu Y29tMDUGCCsGAQUFBzAChilodHRwOi8vc3ZyLW92LWFpYS50aGF3dGUuY29tL1Ro YXd0ZU9WLmNlcjANBgkqhkiG9w0BAQUFAAOCAQEAQKaqABf0+hz+MkHwn6HhnZ6T 3D7u3a3ePrQQgtZWFo+7A5s0C+UA6SBRcvEZDRP7TMZaU+Ft+stglyby33b3koTQ 2X1F484ncBJGyiOBk0M/KQHIsQGUmeXKNLfZlqXhicbT2nq7SktybPR0rsPJoiqN gR8pNlHseb1aHM79NcV9IbpW8B71fEMFQRd7sUvmxGizqOneG4nGXCk04CRRy5H3 raU6Xb2CRi5UdjsJPWjLjLDQZBF5aA0IgOZDi7BghU9cy+P4t2PdBBvPP0ctWI3O LYMF6figGyaw3kCLi4epJ0ZA4ayg8R7KrDNGA7oWI2roknlJd0YEDE3z0Fg2JA== -END CERTIFICATE- 1 s:/C=US/O=Thawte, Inc./CN=Thawte SSL CA i:/C=US/O=thawte,
[Touch-packages] [Bug 1612711] Re: TLS negation fails
Using openssl s_client on a MacOS Sierra machine connecting to the same postgresql server, the failure is identical. Looks like whatever is triggering this is caused by the server, but is being failed by the client. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1612711 Title: TLS negation fails Status in openssl package in Ubuntu: Confirmed Bug description: This seems like a duplicate of #965371, however that is marked fixed, so I don't know. I'm running 16.04.1. I'm setting up OpenLDAP with TLS. I've followed the instructions at https://help.ubuntu.com/lts/serverguide/openldap- server.html#openldap-tls, and test with the command openssl s_client -connect my.server.com:389 -showcerts and I get the error: 140668035487384:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1612711/+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 1612711] Re: TLS negation fails
ssldump looks like the below. >From ssldump, we can see that the server sent three separate certificates. Openssl s_client however claims that no certificates were detected. New TCP connection #42: 172.29.231.43(33116) <-> 172.29.228.240(5432) 42 1 0.0038 (0.0038) C>SV3.1(300) Handshake ClientHello Version 3.3 random[32]= 80 cf 99 66 b3 07 55 c2 3f cf b2 61 13 39 89 c1 33 37 f4 77 21 a3 fd 2e f9 fa 9b 65 4e b5 bd 24 cipher suites Unknown value 0xc030 Unknown value 0xc02c Unknown value 0xc028 Unknown value 0xc024 Unknown value 0xc014 Unknown value 0xc00a Unknown value 0xa5 Unknown value 0xa3 Unknown value 0xa1 Unknown value 0x9f Unknown value 0x6b Unknown value 0x6a Unknown value 0x69 Unknown value 0x68 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA TLS_DH_DSS_WITH_AES_256_CBC_SHA Unknown value 0x88 Unknown value 0x87 Unknown value 0x86 Unknown value 0x85 Unknown value 0xc032 Unknown value 0xc02e Unknown value 0xc02a Unknown value 0xc026 Unknown value 0xc00f Unknown value 0xc005 Unknown value 0x9d Unknown value 0x3d TLS_RSA_WITH_AES_256_CBC_SHA Unknown value 0x84 Unknown value 0xc02f Unknown value 0xc02b Unknown value 0xc027 Unknown value 0xc023 Unknown value 0xc013 Unknown value 0xc009 Unknown value 0xa4 Unknown value 0xa2 Unknown value 0xa0 Unknown value 0x9e TLS_DHE_DSS_WITH_NULL_SHA Unknown value 0x40 Unknown value 0x3f Unknown value 0x3e TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DH_RSA_WITH_AES_128_CBC_SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA Unknown value 0x9a Unknown value 0x99 Unknown value 0x98 Unknown value 0x97 Unknown value 0x45 Unknown value 0x44 Unknown value 0x43 Unknown value 0x42 Unknown value 0xc031 Unknown value 0xc02d Unknown value 0xc029 Unknown value 0xc025 Unknown value 0xc00e Unknown value 0xc004 Unknown value 0x9c Unknown value 0x3c TLS_RSA_WITH_AES_128_CBC_SHA Unknown value 0x96 Unknown value 0x41 Unknown value 0xc011 Unknown value 0xc007 Unknown value 0xc00c Unknown value 0xc002 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 Unknown value 0xc012 Unknown value 0xc008 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0xc00d Unknown value 0xc003 TLS_RSA_WITH_3DES_EDE_CBC_SHA Unknown value 0xff compression methods NULL 42 2 0.0056 (0.0017) S>CV3.3(62) Handshake ServerHello Version 3.3 random[32]= f9 4d fa 63 ee d5 65 6d ba dd 58 de 51 00 8e ac 9f 45 24 43 e2 17 88 07 41 9a 8d aa 7f 95 2a 13 session_id[0]= cipherSuite Unknown value 0xc030 compressionMethod NULL 42 3 0.0056 (0.) S>CV3.3(3345) Handshake Certificate certificate[1329]=[snip] certificate[1010]=[snip] certificate[990]=[snip] 42 4 0.0056 (0.) S>CV3.3(333) Handshake ServerKeyExchange 42 5 0.0056 (0.) S>CV3.3(179) Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign certificate_types unknown value Not enough data. Found 163 bytes (expecting 32767) ServerHelloDone 42 6 0.0061 (0.0004) C>SV3.3(2) Alert level fatal value unknown_ca 420.0062 (0.0001) C>S TCP RST -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1612711 Title: TLS negation fails Status in openssl package in Ubuntu: Confirmed Bug description: This seems like a duplicate of #965371, however that is marked fixed, so I don't know. I'm running 16.04.1. I'm setting up OpenLDAP with TLS. I've followed the instructions at https://help.ubuntu.com/lts/serverguide/openldap- server.html#openldap-tls, and test with the command openssl s_client -connect my.server.com:389 -showcerts and I get the error: 140668035487384:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1612711/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1612711] Re: TLS negation fails
Despite printing "no peer certificate available" below, the postgresql server serves three certificates (two intermediates and a leaf) as picked up by ssldump. In this case it is the client side that is triggering the handshake failure, not the server. The client side refuses to add the cause of the handshake failure to the error message, which is definitely a bug. postgres@sql02:~$ openssl s_client -verify 10 -CAfile .postgresql/root.crt -key .postgresql/postgresql.key -cert .postgresql/postgresql.crt -connect sql01:5432 -servername sql01 verify depth is 10 CONNECTED(0003) 139930468939416:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 379 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1510188432 Timeout : 300 (sec) Verify return code: 0 (ok) --- -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1612711 Title: TLS negation fails Status in openssl package in Ubuntu: Confirmed Bug description: This seems like a duplicate of #965371, however that is marked fixed, so I don't know. I'm running 16.04.1. I'm setting up OpenLDAP with TLS. I've followed the instructions at https://help.ubuntu.com/lts/serverguide/openldap- server.html#openldap-tls, and test with the command openssl s_client -connect my.server.com:389 -showcerts and I get the error: 140668035487384:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1612711/+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 1612711] Re: TLS negation fails
I am seeing the exact same bug, only with the server being postgresql instead of openldap. The same setup and certificates works fine on Trusty, but have regressed on Xenial. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1612711 Title: TLS negation fails Status in openssl package in Ubuntu: Confirmed Bug description: This seems like a duplicate of #965371, however that is marked fixed, so I don't know. I'm running 16.04.1. I'm setting up OpenLDAP with TLS. I've followed the instructions at https://help.ubuntu.com/lts/serverguide/openldap- server.html#openldap-tls, and test with the command openssl s_client -connect my.server.com:389 -showcerts and I get the error: 140668035487384:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1612711/+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 613022] Re: ssh daemon hangs after publickey packet sent
I am seeing this bug in Ubuntu v14.04. No obvious cause. When it's happened we've physically replaced the instances, as there is no console access at AWS. -- 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/613022 Title: ssh daemon hangs after publickey packet sent Status in cloud-init package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in openssh package in Ubuntu: Invalid Bug description: A launched ec2 instance in ap-southeast-1 region is unreachable via ssh. $ ssh -vvv ec2-175-41-171-225.ap-southeast-1.compute.amazonaws.com shows progress up to : debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: smoser@brickies debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply Then nothing for minutes before session is killed (manually). In a 'good' connection, the following would be next: debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey I'll attach full 'ssh -vvv' logs good and bad connection. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: openssh-server 1:5.5p1-4ubuntu3 ProcVersionSignature: User Name 2.6.35-14.19-virtual 2.6.35 Uname: Linux 2.6.35-14-virtual x86_64 Architecture: amd64 Date: Tue Aug 3 14:45:25 2010 Ec2AMI: ami-9fc4bbcd Ec2AMIManifest: ubuntu-images-testing-ap-southeast-1/ubuntu-maverick-daily-amd64-server-20100803.1.manifest.xml Ec2AvailabilityZone: ap-southeast-1a Ec2InstanceType: m1.large Ec2Kernel: aki-11d5aa43 Ec2Ramdisk: unavailable ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: openssh To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/613022/+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 1675118] [NEW] Setting locale breaks sss_ssh_authorizedkeys: set_locale() failed (5): Input/output error
Public bug reported: Configure an Ubuntu Trusty machine with sssd against an LDAP domain. This fails as follows: ubuntu@bastion01:~$ /usr/bin/sss_ssh_authorizedkeys [username] (Wed Mar 22 17:46:15:940434 2017) [/usr/bin/sss_ssh_authorizedkeys] [main] (0x0020): set_locale() failed (5): Input/output error Error setting the locale Further login with LDAP users is impossible. This appears to be a recent regression, a similar machine was deployed on 15 March 2017 using the same orchestration and same configuration without a problem. ubuntu@bastion01:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 14.04.5 LTS Release:14.04 Codename: trusty It looks like this bug or a bug similar to this was fixed in sssd recently, but this doesn't explain the sudden unexpected failure: https://pagure.io/SSSD/sssd/issue/2785 ** Affects: apparmor (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1675118 Title: Setting locale breaks sss_ssh_authorizedkeys: set_locale() failed (5): Input/output error Status in apparmor package in Ubuntu: New Bug description: Configure an Ubuntu Trusty machine with sssd against an LDAP domain. This fails as follows: ubuntu@bastion01:~$ /usr/bin/sss_ssh_authorizedkeys [username] (Wed Mar 22 17:46:15:940434 2017) [/usr/bin/sss_ssh_authorizedkeys] [main] (0x0020): set_locale() failed (5): Input/output error Error setting the locale Further login with LDAP users is impossible. This appears to be a recent regression, a similar machine was deployed on 15 March 2017 using the same orchestration and same configuration without a problem. ubuntu@bastion01:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty It looks like this bug or a bug similar to this was fixed in sssd recently, but this doesn't explain the sudden unexpected failure: https://pagure.io/SSSD/sssd/issue/2785 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1675118/+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 1564179] Re: 389-ds-base linked to NSS and GnuTLS, replication fails
We are currently on a deadline and were forced to switch to CentOS7 to move our project forward, which worked fine out the box. Once our deadline is over I will run tests on the above packages to see what difference they make. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1564179 Title: 389-ds-base linked to NSS and GnuTLS, replication fails Status in 389-ds-base package in Ubuntu: Incomplete Status in openldap package in Ubuntu: New Status in openldap package in Debian: Won't Fix Bug description: The ns-slapd binary is currently linked to two separate SSL libraries, NSS for server connections, and gnutls for client connections via openldap: r...@ldap.example.com:~/src/openldap-2.4.31# ldd /usr/sbin/ns-slapd libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so (0x7f0e14e6) libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x7f0e12def000) Because 389ds's replication plugin passes parameters that are only understandable by NSS to the gnutls library, all attempts to replicate over SSL fails as follows: [30/Mar/2016:17:19:19 +] setup_ol_tls_conn - failed: unable to create new TLS context [30/Mar/2016:17:19:19 +] slapi_ldap_bind - Error: could not configure the server for cert auth - error -1 - make sure the server is correctly configured for SSL/TLS [30/Mar/2016:17:19:19 +] NSMMReplicationPlugin - agmt="cn=Agreement ldap.example.com" (ldap:636): Replication bind with EXTERNAL auth failed: LDAP error 0 (Success) () These messages are caused by NSS certificate nicknames being interpreted by gnutls as filesystem paths, triggering failures. To fix this, 389ds needs to be linked against an LDAP client library that is also linked to NSS. Right now 389ds cannot be used on Trusty at all in any kind of meaningful way. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/389-ds-base/+bug/1564179/+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
