Peço para sair desta lista. Desejo não receber e-mail dessa lista Em qui, 5 de jan de 2023 11:42, <debian-user-digest-requ...@lists.debian.org> escreveu:
> Content-Type: text/plain > > debian-user-digest Digest Volume 2023 : > Issue 7 > > Today's Topics: > Re: Limiting ssh access: by MAC Addr [ Gareth Evans < > donots...@fastmail.fm ] > Re: Limiting ssh access: by MAC Addr [ Jeffrey Walton < > noloa...@gmail.com> ] > Re: Limiting ssh access: by MAC Addr [ jeremy ardley <jer...@ardley.org> > ] > =?UTF-8?Q?erreur_derni=c3=a8re_ligne [ Olivier backup my spare > <backup.my. ] > Re: Limiting ssh access: by MAC Addr [ Tim Woodall < > debianu...@woodall.me. ] > Re: Limiting ssh access: by MAC Addr [ Tim Woodall < > debianu...@woodall.me. ] > =?UTF-8?Q?Re=3a_erreur_derni=c3=a8re [ john doe <johndoe65...@mail.com> > ] > Re: VLC not ejecting CD/DVDs [ Charles Curley > <charlescurley@charl ] > Re: debian sid no boot after this mo [ Frank <debianl...@videotron.ca> > ] > Re: debian sid no boot after this mo [ Eduardo M KALINOWSKI > <eduardo@kalin ] > Re: debian sid no boot after this mo [ Greg Wooledge <g...@wooledge.org> > ] > Re: debian sid no boot after this mo [ Frank McCormick > <debianlist@videotr ] > Date: Thu, 5 Jan 2023 04:33:21 +0000 > From: Gareth Evans <donots...@fastmail.fm> > To: debian-user@lists.debian.org > Cc: debian-user@lists.debian.org > Subject: Re: Limiting ssh access: by MAC Address? > Message-Id: <75516df9-32a1-4ec6-837a-fca292a85...@fastmail.fm> > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: quoted-printable > > > On 3 Jan 2023, at 22:07, Tom Browder <tom.brow...@gmail.com> wrote: > > I ... would like to access my home server from my laptop ... > > > > On 5 Jan 2023, at 04:13, Jeffrey Walton <noloa...@gmail.com> wrote: > > =EF=BB=BF... > > Avoiding the key exchange is a big win > > since those public key operations are so costly. > > Costly in what sense and circumstances? > > For interactive, real-user-at-the-end ssh logins, key checking delays are > ne= > gligible in my experience - certainly no longer than it would take to type > a= > password... > > Kind regards, > Gareth > > > >=20 > > Jeff > Date: Wed, 4 Jan 2023 23:56:06 -0500 > From: Jeffrey Walton <noloa...@gmail.com> > To: Gareth Evans <donots...@fastmail.fm> > Cc: debian-user@lists.debian.org > Subject: Re: Limiting ssh access: by MAC Address? > Message-ID: <CAH8yC8nW8kAWHq2aLE3fzLL_dRJp3m= > uljwqf2sfrpvvjmm...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > On Wed, Jan 4, 2023 at 11:34 PM Gareth Evans <donots...@fastmail.fm> > wrote: > > > > > On 3 Jan 2023, at 22:07, Tom Browder <tom.brow...@gmail.com> wrote: > > > I ... would like to access my home server from my laptop ... > > > > > > > On 5 Jan 2023, at 04:13, Jeffrey Walton <noloa...@gmail.com> wrote: > > > =EF=BB=BF... > > > Avoiding the key exchange is a big win > > > since those public key operations are so costly. > > > > Costly in what sense and circumstances? > > Public key operations for key exchange dominate the cpu cost of a > session. Key exchange is the limiting factor in how many connections a > server can handle. It has always been this way, even for SSL/TLS and > IPSec. > > In contrast, bulk encryption is cheap. Bulk encryption is the block or > stream cipher, and the mac calculations. > > One of the reasons x25519 is so valuable is how efficient it is. Here > are some benchmarks from Crypto++ on a Core i5 10th gen Ice Lake > machine: > > Scheme | ms/op | megacycle/op > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > DH-2048 | 0.565 | 1.977 > ECDH p256 | 0.456 | 1.595 > x25519 | 0.039 | 0.138 > > In the numbers above, lower is better. x25519 is about 15x faster than > DH over integers, and about 11x faster than DH over EC. > > Key exchange is measured in megacycles per operation. That is, how > many million-cycles is needed for an operation. Here, the operation is > exponentiation in a finite field. In contrast, bulk encryption is > measured in cycles per byte. > > Jeff > Date: Thu, 5 Jan 2023 13:18:20 +0800 > From: jeremy ardley <jer...@ardley.org> > To: debian-user@lists.debian.org > Subject: Re: Limiting ssh access: by MAC Address? > Message-ID: <67c4cc0b-0cb4-268f-6abd-767cb7778...@ardley.org> > Content-Language: en-US > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8bit > > On 5/1/23 12:56, Jeffrey Walton wrote: > > On Wed, Jan 4, 2023 at 11:34 PM Gareth Evans <donots...@fastmail.fm> > wrote: > >>> On 3 Jan 2023, at 22:07, Tom Browder <tom.brow...@gmail.com> wrote: > >>> I ... would like to access my home server from my laptop ... > >> > >>> On 5 Jan 2023, at 04:13, Jeffrey Walton <noloa...@gmail.com> wrote: > >>> ... > >>> Avoiding the key exchange is a big win > >>> since those public key operations are so costly. > >> Costly in what sense and circumstances? > > Public key operations for key exchange dominate the cpu cost of a > > session. Key exchange is the limiting factor in how many connections a > > server can handle. It has always been this way, even for SSL/TLS and > > IPSec. > > > > > For your typical home user with no expectation of high numbers of > connections, the issue is more to limit the crap that turns up in the > logs from failed login attempts. > > Requiring a valid client certificate to be presented before, or instead > of, a username/password works perfectly for this. > > I have some recollection that the validation of a client certificate is > not a high cost exercise? > > -- > Jeremy > Date: Thu, 5 Jan 2023 06:46:47 +0100 > From: Olivier backup my spare <backup.my.sp...@gmail.com> > To: debian-user@lists.debian.org > Subject: =?UTF-8?Q?erreur_derni=c3=a8re_ligne_avant_extinction?= > Message-ID: <33fc84fa-7f14-d357-8069-6f1a0c3bb...@gmail.com> > Content-Language: fr > Content-Type: multipart/signed; protocol="application/pkcs7-signature"; > micalg=sha-256; boundary="------------ms060805040503090300020200" > > This is a cryptographically signed message in MIME format. > > --------------ms060805040503090300020200 > Content-Type: multipart/mixed; > boundary="------------BmU8hg9cVyulpEg0oZHc4pMJ" > > --------------BmU8hg9cVyulpEg0oZHc4pMJ > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8bit > > Bonjour > > Sur mon ordinateur personnel j'ai constaté un "ERROR" en rouge, mais > c'est la dernière ligne avant l'extinction. > D'après vos connaissances dans quel fichier son logués les informations > lors de l'extinction? > > Je fais amende honorable, je ne lis plus les fichiers logs depuis que je > ne compile plus le kernel et ça, ça date des années 2005... > > -- > AI Gestionnaire d'infrastructure/ Gestionnaire de Parc. > Centre d'économie S****** > Monero (XMR) - The secure, private, untraceable cryptocurrency > that keeps your money confidential. > Grassroots. Open source. Dedicated to privacy & freedom. > Monero || #xmr > --------------BmU8hg9cVyulpEg0oZHc4pMJ > Content-Type: text/vcard; charset=UTF-8; name="backup_my_spare.vcf" > Content-Disposition: attachment; filename="backup_my_spare.vcf" > Content-Transfer-Encoding: base64 > > QkVHSU46VkNBUkQNClZFUlNJT046NC4wDQpOOlAuO09saXZpZXI7OzsNCk5JQ0tOQU1FOkJh > Y2t1cCBteSBTcGFyZQ0KRU1BSUw7UFJFRj0xOmJhY2t1cC5teS5zcGFyZUBnbWFpbC5jb20N > ClVSTDpodHRwczovL0RlcGxveWFkbWluLmNvbQ0KVFo6RXVyb3BlL1BhcmlzDQpGTjpPbGl2 > aWVyIFAuDQpBRFI6Ozs7UmFtYm91aWxsZXQ7Ozc4MTIwO0ZyYW5jZQ0KRU5EOlZDQVJEDQo= > > > --------------BmU8hg9cVyulpEg0oZHc4pMJ-- > > --------------ms060805040503090300020200 > Content-Type: application/pkcs7-signature; name="smime.p7s" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="smime.p7s" > Content-Description: Signature cryptographique S/MIME > > MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC > DWEwggXsMIID1KADAgECAhBGWEnoYLxLQW8HZ/SNlBHFMA0GCSqGSIb3DQEBCwUAMIGBMQsw > CQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRy > bzEXMBUGA1UECgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 > dGhlbnRpY2F0aW9uIENBIEczMB4XDTIyMTEwNzExNTg1MVoXDTIzMTEwNzExNTg1MVowJDEi > MCAGA1UEAwwZYmFja3VwLm15LnNwYXJlQGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD > ggEPADCCAQoCggEBAIO5UI7cPE2ACkEwXkqC7W74c4L8TnW7Ei13X3XT/NSPMTJ4717JiKHS > no/6+uinLd2sgE3k6wGNusvAiIOV3xL9YHZLd8ZGk2/BQpgrg42krydB7Nzf3cFj7/5as5WM > nH4OtAgbVfwgX6XXCFNA+obCtaUcKpHl+WGbjRK/JAQJ/uNnqw8dqhaTK2M83HELJH4FFnHL > 7v68lPBnmMDKKy5cAt9aNQNvM72iHIYpyZl7QBgV9i5RbkTpUtMnLvazYgZ5bhtD1L1QqDiQ > AZDPglk1nVrJDS+gSPg6CmCNDhL/Os+fECysA6lD//lc5DLV6dYfxOUoRTqYg/6RPU4GEpEC > AwEAAaOCAbowggG2MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUvpepqoS/gL8QU30JMvnh > LjIbz3cwfgYIKwYBBQUHAQEEcjBwMDsGCCsGAQUFBzAChi9odHRwOi8vY2FjZXJ0LmFjdGFs > aXMuaXQvY2VydHMvYWN0YWxpcy1hdXRjbGlnMzAxBggrBgEFBQcwAYYlaHR0cDovL29jc3Aw > OS5hY3RhbGlzLml0L1ZBL0FVVEhDTC1HMzAkBgNVHREEHTAbgRliYWNrdXAubXkuc3BhcmVA > Z21haWwuY29tMEcGA1UdIARAMD4wPAYGK4EfARgBMDIwMAYIKwYBBQUHAgEWJGh0dHBzOi8v > d3d3LmFjdGFsaXMuaXQvYXJlYS1kb3dubG9hZDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB > BQUHAwQwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybDA5LmFjdGFsaXMuaXQvUmVwb3Np > dG9yeS9BVVRIQ0wtRzMvZ2V0TGFzdENSTDAdBgNVHQ4EFgQUrm0dfiOPUPSmnbMwVSXH8ADp > jfswDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQAtcg7gKqmhmlvgt3koVY5J > ixqJoIoPvy6az7hDqSYOrn2QPI10KCSFduL1KNjehz3iinBo4mM8X5G/Z7tXVjKl6U0a7bu3 > 9vQlDa06JYrXXe0kqWzjyGzOn4EJ4H/Ggmx1dzOD4S2HzARgTWdI6jzn0CtiW/0juuxtV+V7 > rKVaekiXMElQZgV441cmeSrLzibEFA+XGNVJK+CU5cf7beBhBfX+4dDX9yPwKjji/o3kH2Qv > cGQVM+Tt2/HlLlrPyhUQ9tDerQFmjXbvnovUfBDaDyO1LutCT5Zgf0IYNcFyw6ko32l/396n > 388zuj7HziTop7CogNfzd0jB2bVUXboe/ScjCyOONKnBMs/OWhHK4ZIsEoa9Au2iBJWDn+V0 > ii9k/J9IM+5z4e00rIhua9R95QsuAOc9SrFW8pek1H5AInKzSZhtHrMUIoZzVAjUOZTnMDH6 > rtnXuABHA5w+cOJEnB4BcVBeB/7vBEcCJYI5WY5Bo4NwmVn02wYBWaGWDDfOvvgsb/s63LN+ > wE3/JRWTQLDo2/uato5DYg9pAx8f2AWDH8fVHS4RYGU9nrmdIBgMD2hDsuZBKK0NXiwpCPmH > C60hcuwz95z21pDhKnmqXEEy6Ot2LFytOCiECzzo1eDk4AjVP7h+Fz6qXczuePlG9HX7CQQ/ > 7mU2Ip6Ytc02ZzCCB20wggVVoAMCAQICEBcQPt49ihy1ygZRk+fKQ2swDQYJKoZIhvcNAQEL > BQAwazELMAkGA1UEBhMCSVQxDjAMBgNVBAcMBU1pbGFuMSMwIQYDVQQKDBpBY3RhbGlzIFMu > cC5BLi8wMzM1ODUyMDk2NzEnMCUGA1UEAwweQWN0YWxpcyBBdXRoZW50aWNhdGlvbiBSb290 > IENBMB4XDTIwMDcwNjA4NDU0N1oXDTMwMDkyMjExMjIwMlowgYExCzAJBgNVBAYTAklUMRAw > DgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5B > Y3RhbGlzIFMucC5BLjEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24g > Q0EgRzMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDt5oeWocGktu3CQlX3Pw8P > ImBfE+CmQ4iGSZF5HBsvGlAP3EYB7va6OobMUWHvxA+ACHEpWq0YfNh6rRUlULOGcIpEFtVf > 4nAiEvdQtiFQBmtWJSn3naoMHqpMvmwZ4lL0Xr1U9JHmTqkU3DuYcNNO3S+hYWDZpWQbeSGi > bNVeiJ4kY6JDh0fvqloK1BsuS3n2OgArPYGfAYtDjCvT2d+6Ym3kArHZjEcrZeBI+yVVnjPw > bTSCKax8DtS2NP/CJ6RjpnRvuSwusRy84OdwdB71VKs1EDXj1ITcCWRZpkz+OhV6L8Zh+P0r > mOSJF6KdHiaozfncURx4s54GFJNRGkx1DnCxcuL0NJMYG42/hrDYOjNv+oGWSEZO/CT3aaLS > MB5wTbZKfcD1R+tTanXD+5Gz5Mi15DTE7QH8naZjZxqqhyxL1KyuIgaVDxvQtPSjo5vTsoa0 > 9rn+Ui8ybHnvYO/a/68OIQIHLGbUd2COnwm0TiZ3Jg/oYGxwnJPvU1nDXNcecWTIJvFF5qD2 > ppJH3HgJVVePUEOY1E4Kp3k0B8hdRdhMV5n+O6RCKCTFcZaESF8sELgdrqnCLPP1+rX7DA8p > xZoX0/9Jk64EOsbfQyLIJlrrob2YS0Xlku6HisZ8qrHLhnkzF5y7O34xmatIp8oZ5c54QP+K > 5flnTYzWjuIxLwIDAQABo4IB9DCCAfAwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRS > 2Ig6yJ94Zu2J83s4cJTJAgI20DBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGGJWh0dHA6 > Ly9vY3NwMDUuYWN0YWxpcy5pdC9WQS9BVVRILVJPT1QwRQYDVR0gBD4wPDA6BgRVHSAAMDIw > MAYIKwYBBQUHAgEWJGh0dHBzOi8vd3d3LmFjdGFsaXMuaXQvYXJlYS1kb3dubG9hZDAdBgNV > HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgeMGA1UdHwSB2zCB2DCBlqCBk6CBkIaBjWxk > YXA6Ly9sZGFwMDUuYWN0YWxpcy5pdC9jbiUzZEFjdGFsaXMlMjBBdXRoZW50aWNhdGlvbiUy > MFJvb3QlMjBDQSxvJTNkQWN0YWxpcyUyMFMucC5BLiUyZjAzMzU4NTIwOTY3LGMlM2RJVD9j > ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTA9oDugOYY3aHR0cDovL2NybDA1LmFj > dGFsaXMuaXQvUmVwb3NpdG9yeS9BVVRILVJPT1QvZ2V0TGFzdENSTDAdBgNVHQ4EFgQUvpep > qoS/gL8QU30JMvnhLjIbz3cwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBCwUAA4ICAQAm > m+cbWQ10sxID6edV94SAhc1CwzthHFfHpuYS30gisWUfWpgp43Dg1XzG2in3VGV7XrzCCGZh > 4JM/XQWp+4oxmyV42Qjz9vc8GRksgo6X2nYObPYZzQjda9wxsCB38i4G3H33w8lf9sFvl0xm > 4ZXZ2s2bF/PdqvrK0ZgvF51+MoIPnli/wJBw3p72xbk5Sb1MneSO3tZ293WFzDmz7tuGU0Pf > ytYUkG7O6annGqbU1I6CA6QVKUqeFLPodSODAFqJ3pimKD0vX9MuuSa0QinH7CkiPtZMD0mp > wwzIsnSs3qOOl60tIZQOTc0I6lCe1LLhrz7Q75J6nNL9N5zVwZ1I3o2Lb8Dt7BA13VFuZvZI > zapUGV83R7pmSVaj1Bik1nJ/R393e6mwppsT140KDVLh4Oenywmp2VpBDuEj9RgICAO0sibv > 8n379LbO7ARa0kw9y9pggFzN2PAX25b7w0n9m78kpv3z3vW65rs6wl7E8VEHNfv8+cnb81dx > N3C51KElz+l31zchFTurD5HFEpyEhzO/fMS5AkweRJIzwozxNs7OL/S/SVTpJLJL1ukZ1lnH > HX0d3xCzRy/5HqfK3uiG22LPB5+RjNDobPAjAz2BKMfkF/+v0pzn8mqqkopQaJzEAbLbMpgQ > YHRCjvrUxxwjJyUFb2Z+40UNtMF4MTK7zTGCA/MwggPvAgEBMIGWMIGBMQswCQYDVQQGEwJJ > VDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UE > CgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0 > aW9uIENBIEczAhBGWEnoYLxLQW8HZ/SNlBHFMA0GCWCGSAFlAwQCAQUAoIICLTAYBgkqhkiG > 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMzAxMDUwNTQ2NDdaMC8GCSqG > SIb3DQEJBDEiBCAS6y4Z9QDhK35rvFvtEnE4gRJs60EtpYPcgHol48obpDBsBgkqhkiG9w0B > CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN > AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGnBgkrBgEE > AYI3EAQxgZkwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQH > DBBQb250ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwj > QWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEZYSehgvEtBbwdn9I2UEcUw > gakGCyqGSIb3DQEJEAILMYGZoIGWMIGBMQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2Ft > bzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UECgwOQWN0YWxpcyBTLnAuQS4x > LDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEczAhBGWEnoYLxL > QW8HZ/SNlBHFMA0GCSqGSIb3DQEBAQUABIIBAID+PLX15ehcV3V3u2hVajtxIxMUDNn8Cqd3 > u6lgDdAmciEIWHCkBg+TCDPA2hXO7oWjVfsaZGTU1UjkQxUqyLIjDCKS+AHlW09ycOFeiIKg > 0w/FhtecmOjP63Xg5ru5DYzeEqE8ocqiRhOJybjVVsPVQQlCcdVDKMhXBmxn+/edKw82dXD0 > ZVkWZxWSY45ZCkAoBvUCbKMDzpgvam/9TbEy3uJ94FxId7DrYt4jp5jIBtsYO6HzvAsfn/ej > n1USaEoxtYv39Nl47liobkXBLmk1V0NC6ygMVOiyEfk5k6uZMqUX9TCvEvr8IOPScbOUomV5 > 7L3CMFxm/uJGGIdU574AAAAAAAA= > --------------ms060805040503090300020200-- > Date: Thu, 5 Jan 2023 06:51:44 +0000 (GMT) > From: Tim Woodall <debianu...@woodall.me.uk> > To: debian-user@lists.debian.org > Subject: Re: Limiting ssh access: by MAC Address? > Message-ID: < > alpine.deb.2.21.2301050542020.23...@einstein.home.woodall.me.uk> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Wed, 4 Jan 2023, Jeffrey Walton wrote: > > > > > The preauth scheme does not hide the service like your TOTP scheme. > > However, it looks like both schemes achieve the same thing - they both > > avoid the costly key exchange. Avoiding the key exchange is a big win > > since those public key operations are so costly. > > > > My scheme doesn't remove the need for any auth. What it does do is limit > the noise in the logs. Given that the DNS query won't come from the same > address as the intended connection you have to open the service to > everything temporarily. > > I was getting anything from thousands to hundreds of thousands of login > attempts per day on a service that didn't accept passwords. > > I now have an aggressive firewall policy that blocks any ip that sends > three SYN that dont get an ACK in an hour. (with a couple of ports that > will remove a ban where external connections are expected) > Roughly 300 ips got added yesterday and 30 managed to remove themselves. > (incoming connections are totally blocked from china, russia and a > handful of other countries along with some netblocks that I've manually > added) > > My quick grep of the firewall logs suggests than I'm seeing 10x as many > attempts to connect to telnet than I am to ssh so I guess ssh is finally > becoming secured from password guessing and people are giving up on > trying (except possibly targetted attacks on servers that accept > passwords) > > I'm also, as far as possible, moving to ipv6. That also cuts down on the > noise a lot. > > So hiding services just isn't as valuable to me now as it was four years > ago. I'm still generating 40MB of firewall logs a day that get backed up > though. > Date: Thu, 5 Jan 2023 07:04:37 +0000 (GMT) > From: Tim Woodall <debianu...@woodall.me.uk> > To: debian-user@lists.debian.org > cc: debian-user@lists.debian.org > Subject: Re: Limiting ssh access: by MAC Address? > Message-ID: < > alpine.deb.2.21.2301050652210.23...@einstein.home.woodall.me.uk> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Wed, 4 Jan 2023, ?ngel wrote: > > > There are no transparent proxies for https. They would either pass > > traffic without inspecting it, or they would need to break the TLS > > connection to MITM it, and -unless the client has installed a CA for > > the proxy- cause all https connections to fail due to untrusted > > certificate. > > > > I suggest you read up about the problem that ESNI is supposed to solve. > > As someone who runs a https transparent proxy that does SNI inspection > and egress filtering, I can assure you they do exist and will break ovpn > running on port 443. > > You might argue that it's not a proxy - it doesn't and cannot cache > content - but so much content is dynamic now anyway that caching isn't > particularly useful except for things like debian packages. Egress > filtering is still possible. > > It's frustrating that so much effort goes into defeating government > level inspection of end user traffic and so little goes into defeating > the countless IoT trojan horses in our homes. Indeed, I wouldn't be > surprised if the long term result of the current trajectory is > authoritarian regimes using phones to spy on people in their homes with > no way to block it (other than turn the phone off - but that already > works today so ESNI isn't needed) > Date: Thu, 5 Jan 2023 08:48:17 +0100 > From: john doe <johndoe65...@mail.com> > To: debian-user@lists.debian.org > Subject: =?UTF-8?Q?Re=3a_erreur_derni=c3=a8re_ligne_avant_extinction?= > Message-ID: <c4c5afb7-4229-de0c-60aa-2033c3ea5...@mail.com> > Content-Language: en-US > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: quoted-printable > > On 1/5/23 06:46, Olivier backup my spare wrote: > > Bonjour > > > > Sur mon ordinateur personnel j'ai constat=C3=A9 un "ERROR" en rouge, mai= > s > > c'est la derni=C3=A8re ligne avant l'extinction. > > D'apr=C3=A8s vos connaissances dans quel fichier son logu=C3=A9s les inf= > ormations > > lors de l'extinction? > > > > Je fais amende honorable, je ne lis plus les fichiers logs depuis que je > > ne compile plus le kernel et =C3=A7a, =C3=A7a date des ann=C3=A9es 2005.= > .. > > > > This is an English mailing list! :) > > Have a look in /var/log. > > =2D- > John Doe > Date: Thu, 5 Jan 2023 05:26:12 -0700 > From: Charles Curley <charlescur...@charlescurley.com> > To: Debian Users <debian-user@lists.debian.org> > Subject: Re: VLC not ejecting CD/DVDs > Message-ID: <20230105052612.15b97bec@jhegaala.localdomain> > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > > On Wed, 04 Jan 2023 09:34:38 +0100 > "Thomas Schmitt" <scdbac...@gmx.net> wrote: > > > > One of those four methods is via SCSI. When I specify that method, > > > eject ejects the CD/DVD. > > > charles@jhegaala:~$ eject -s /dev/sr0 > > > > Does > > eject -r /dev/sr0 > > work too ? > > Yes. > > charles@jhegaala:~$ eject -r /dev/sr0 ; echo $? > 0 > charles@jhegaala:~$ > > > Given the rest of your comments, I'm inclined to file a bug report. > > -- > Does anybody read signatures any more? > > https://charlescurley.com > https://charlescurley.com/blog/ > Date: Thu, 5 Jan 2023 09:12:58 -0500 > From: Frank <debianl...@videotron.ca> > To: debian-user@lists.debian.org > Subject: Re: debian sid no boot after this morning's update > Message-ID: <8dae7a89-2473-764e-4bce-3a416453f...@videotron.ca> > Content-Language: en-US > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8bit > > On 2023-01-04 11:23 p.m., Greg Wooledge wrote: > > On Wed, Jan 04, 2023 at 11:03:15PM -0500, Frank wrote: > >> ** (process:734): WARNING **: 22:32:38.355: Error reading existing > >> Xauthority: Failed to open file ?/var/lib/lightdm/.Xauthority?: > Permission > >> denied > >> Error writing X authority: Failed to open X authority > >> /var/lib/lightdm/.Xauthority: Permission denied > > Does that file exist? If so, ls -ld /var/lib/lightdm/.Xauthority > > > > If not, ls -ld /var/lib/lightdm > > > > Hell, just do both regardless of whether the file currently exists. > > It's one command with two lines of output. Should be the first thing > > you do. > > Yes, the file exists and is owned by lightdm. I don't know whether > this is > correct as I can't find any info on who should own it. > I tried moving it out of the way hoping lightdm or the greeter would > recreate but no luck. > > > > > See if you can figure out which user lightdm is trying to run as. > > Try to make it so that user can write that file, either by removing > > the existing file, or chowning it, or fixing the permissions on the > > directory. Whatever is indicated by the lightdm changelog. Hopefully > > there's a note in the lightdm changelog about this. Or in NEWS. > > > There are no notes or news file for lightdm so I am in the dark. > > It is strange as there were no updates yesterday of lightdm or the > greeter. The GTK > greeter was updated the day before but Debian started and ran fine after > that. > > There are other strange things going on which may or not be related. I > tried to > reinstall lightdm and the greeter using apt. (The Debian partition is > mounted > on my Fedora partition) but apt failed saying it could not contact > debian.deb to > gain access to the needed files. I downloaded the files from Fedora and > moved them > to Debian but dpkg said it could not access them !!?? > > Is there a way to reinstall lightdm and the greeter from Fedora ?? > Perhaps using chroot > which I have zero knowledge of. > > I am getting close to reinstalling Debian ( shades of Windows) ! > > Thanks for any help. > Date: Thu, 5 Jan 2023 11:24:40 -0300 > From: Eduardo M KALINOWSKI <edua...@kalinowski.com.br> > To: debian-user@lists.debian.org > Subject: Re: debian sid no boot after this morning's update > Message-ID: <a9b9421b-95dd-494e-af62-3cb1196f2...@kalinowski.com.br> > Content-Language: pt-BR > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 7bit > > On 05/01/2023 11:12, Frank wrote: > > Is there a way to reinstall lightdm and the greeter from Fedora ?? > > Perhaps using chroot > > which I have zero knowledge of. > > Since the problem seems to be the display manager/greeter, there's a > good chance that you can press Ctrl+F1 (or F2, F3...) to reach a > console, so no need to a console to reinstall debian packages. Try also > Ctrl+Alt+Fn. > > > -- > To give of yourself, you must first know yourself. > > Eduardo M KALINOWSKI > edua...@kalinowski.com.br > Date: Thu, 5 Jan 2023 09:53:12 -0500 > From: Greg Wooledge <g...@wooledge.org> > To: debian-user@lists.debian.org > Subject: Re: debian sid no boot after this morning's update > Message-ID: <y7bkwkygzk+kz...@wooledge.org> > Content-Type: text/plain; charset=iso-8859-1 > Content-Disposition: inline > Content-Transfer-Encoding: 8bit > > On Thu, Jan 05, 2023 at 09:12:58AM -0500, Frank wrote: > > On 2023-01-04 11:23 p.m., Greg Wooledge wrote: > > > On Wed, Jan 04, 2023 at 11:03:15PM -0500, Frank wrote: > > > > ** (process:734): WARNING **: 22:32:38.355: Error reading existing > > > > Xauthority: Failed to open file ?/var/lib/lightdm/.Xauthority?: > Permission > > > > denied > > > > Error writing X authority: Failed to open X authority > > > > /var/lib/lightdm/.Xauthority: Permission denied > > > Does that file exist? If so, ls -ld /var/lib/lightdm/.Xauthority > > > > > > If not, ls -ld /var/lib/lightdm > > > > > > Hell, just do both regardless of whether the file currently exists. > > > It's one command with two lines of output. Should be the first thing > > > you do. > > > > Yes, the file exists and is owned by lightdm. I don't know whether > this is > > correct as I can't find any info on who should own it. > > I tried moving it out of the way hoping lightdm or the greeter would > > recreate but no luck. > > Hmm, that's weird indeed. If the file is owned by lightdm (the user), > that implies that lightdm (the program) was able to write it in the past. > If it can't do so now, then we have to try to guess what changed which > could lead to this result. > > Possibility 1: lightdm (the program) no longer runs as lightdm (the user). > > Pissibility 2: a new restriction has been added to the service which > launches lightdm (the program). Something at the AppArmor level, or at > the systemd unit level, perhaps. > > > It is strange as there were no updates yesterday of lightdm or the > greeter. > > How about in recent days? Maybe a change occurred a few days ago, but > you hadn't rebooted, so the changes didn't actually have any impact yet. > > > The GTK > > greeter was updated the day before but Debian started and ran fine after > > that. > > I don't know what this is. A separate package? > > > There are other strange things going on which may or not be related. I > tried > > to > > reinstall lightdm and the greeter using apt. (The Debian partition is > > mounted > > on my Fedora partition) > > This is confusing. Are you saying that you have a multi-boot system, > with both Debian and Fedora installed on the same hard drive? And that > you booted into Fedora, then mounted the Debian root file system somewhere, > and then chrooted into it? > > > but apt failed saying it could not contact > > debian.deb to > > gain access to the needed files. I downloaded the files from Fedora and > > moved them > > to Debian but dpkg said it could not access them !!?? > > Details would be helpful here. Actual commands, actual error messages. > > > Is there a way to reinstall lightdm and the greeter from Fedora ?? > Perhaps > > using chroot > > which I have zero knowledge of. > > Wait... you DID NOT chroot into the Debian file system after mounting it?! > > How in the hell did you expect ANYTHING to work...? > > OK, basic primer: > > mkdir /debian > mount /dev/whatever /debian > chroot /debian > > There's fancy crap you can do involving bind mounts of /proc and so on, > but you probably don't need all that. > > That said, I think you've jumped ahead too far. Your Debian system > apparently boots just fine -- it just doesn't run X. So boot Debian, > either normally, or with the "systemd.unit=multi-user.target" kernel > parameter, login on a regular text console, and fix it from there. > > Another thing you could try would be to boot your previous kernel, in > case it was a kernel update that broke lightdm. It might not make any > difference, but hey, it's worth trying. > > Another other thing you could try would be to run 'startx' from a > regular text console after booting Debian and logging in on said console. > If X starts correctly that way, then you know the problem is truly in > the DM, not in X, video drivers, video firmware, etc. We suspect this > already, but confirmation is always good. > Date: Thu, 5 Jan 2023 10:38:47 -0500 > From: Frank McCormick <debianl...@videotron.ca> > To: debian-user@lists.debian.org > Subject: Re: debian sid no boot after this morning's update > Message-ID: <ac548065-c5c1-d651-c22e-15110e34a...@videotron.ca> > Content-Language: en-US > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 7bit > > On 1/5/23 09:24, Eduardo M KALINOWSKI wrote: > > On 05/01/2023 11:12, Frank wrote: > >> Is there a way to reinstall lightdm and the greeter from Fedora ?? > >> Perhaps using chroot > >> which I have zero knowledge of. > > > > Since the problem seems to be the display manager/greeter, there's a > > good chance that you can press Ctrl+F1 (or F2, F3...) to reach a > > console, so no need to a console to reinstall debian packages. Try also > > Ctrl+Alt+Fn. > > > > > I never tried that unfortunately. It might have saved me a lot of > trouble. I finally got lightdm and it's greeter reinstalled after > fixing some other problems and the system then booted fine. The strange > thing in my mind is how the whole thing happened, as only the lightdm > greeter had been updated and that was a few days ago. > Thanks for the suggestion - Ill try to keep it in mind. > > -- > Frank McCormick >
