Content-Type: text/plain
debian-user-digest Digest Volume 2023 : Issue 7
Today's Topics:
Re: Limiting ssh access: by MAC Addr [ Gareth Evans <donotspam@fastmail.fm ]
Re: Limiting ssh access: by MAC Addr [ Jeffrey Walton <noloader@gmail.com> ]
Re: Limiting ssh access: by MAC Addr [ jeremy ardley <jeremy@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 <debianuser@woodall.me. ]
Re: Limiting ssh access: by MAC Addr [ Tim Woodall <debianuser@woodall.me. ]
=?UTF-8?Q?Re=3a_erreur_derni=c3=a8re [ john doe <johndoe65534@mail.com> ]
Re: VLC not ejecting CD/DVDs [ Charles Curley <charlescurley@charl ]
Re: debian sid no boot after this mo [ Frank <debianlist@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 <greg@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 <donotspam@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-FCA292A8510C@fastmail.fm" target="_blank" rel="noreferrer">[🔎] 75516DF9-32A1-4EC6-837A-FCA292A8510C@fastmail.fm>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
> On 3 Jan 2023, at 22:07, Tom Browder <tom.browder@gmail.com> wrote:
> I ... would like to access my home server from my laptop ...
> On 5 Jan 2023, at 04:13, Jeffrey Walton <noloader@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 <noloader@gmail.com>
To: Gareth Evans <donotspam@fastmail.fm>
Cc: debian-user@lists.debian.org
Subject: Re: Limiting ssh access: by MAC Address?
Message-ID: <CAH8yC8nW8kAWHq2aLE3fzLL_dRJp3m=uLjwqf2SFrPvVjmMbEw@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 <donotspam@fastmail.fm> wrote:
>
> > On 3 Jan 2023, at 22:07, Tom Browder <tom.browder@gmail.com> wrote:
> > I ... would like to access my home server from my laptop ...
>
>
> > On 5 Jan 2023, at 04:13, Jeffrey Walton <noloader@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 <jeremy@ardley.org>
To: debian-user@lists.debian.org
Subject: Re: Limiting ssh access: by MAC Address?
Message-ID: <[🔎] 67c4cc0b-0cb4-268f-6abd-767cb7778b6d@ardley.org" target="_blank" rel="noreferrer">[🔎] 67c4cc0b-0cb4-268f-6abd-767cb7778b6d@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 <donotspam@fastmail.fm> wrote:
>>> On 3 Jan 2023, at 22:07, Tom Browder <tom.browder@gmail.com> wrote:
>>> I ... would like to access my home server from my laptop ...
>>
>>> On 5 Jan 2023, at 04:13, Jeffrey Walton <noloader@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.spare@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-6f1a0c3bb343@gmail.com" target="_blank" rel="noreferrer">[🔎] 33fc84fa-7f14-d357-8069-6f1a0c3bb343@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 <debianuser@woodall.me.uk>
To: debian-user@lists.debian.org
Subject: Re: Limiting ssh access: by MAC Address?
Message-ID: <[🔎] alpine.DEB.2.21.2301050542020.23174@einstein.home.woodall.me.uk" target="_blank" rel="noreferrer">[🔎] alpine.DEB.2.21.2301050542020.23174@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 <debianuser@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.23174@einstein.home.woodall.me.uk" target="_blank" rel="noreferrer">[🔎] alpine.DEB.2.21.2301050652210.23174@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 <johndoe65534@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-2033c3ea5adc@mail.com" target="_blank" rel="noreferrer">[🔎] c4c5afb7-4229-de0c-60aa-2033c3ea5adc@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 <charlescurley@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" <scdbackup@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 <debianlist@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-3a416453f75a@videotron.ca" target="_blank" rel="noreferrer">[🔎] 8dae7a89-2473-764e-4bce-3a416453f75a@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 <eduardo@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-3cb1196f249a@kalinowski.com.br" target="_blank" rel="noreferrer">[🔎] a9b9421b-95dd-494e-af62-3cb1196f249a@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
eduardo@kalinowski.com.br
Date: Thu, 5 Jan 2023 09:53:12 -0500
From: Greg Wooledge <greg@wooledge.org>
To: debian-user@lists.debian.org
Subject: Re: debian sid no boot after this morning's update
Message-ID: <[🔎] Y7bkWKYGZk+Kzyz1@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 <debianlist@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-15110e34a94a@videotron.ca" target="_blank" rel="noreferrer">[🔎] ac548065-c5c1-d651-c22e-15110e34a94a@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