Linux kysymyksiä

[Viilee]

Minun on vähän hankala nyt pysyä kärryillä ylläolevan vastauksen ydinajatuksen kanssa, mutta koetan silti kommentoida jotain:

On niin paljon erilaisia konffeja koko linuxissa että vaikka selaimista, palomuureista, firejail & apparmorit yms. kaikista sais tiedostoina talteen, on niiden palauttaminen sen verran työlästä että koko imagen palauttaminen kerralla taitaa olla parempi ratkaisu. Tai vaihtoehto b, niin lopettaa se säätäminen ja tyytyä johonkin "tuunaamattomaan" perusympäristöön mitä en vielä halua.

Imagen tekeminen ei palauta yhtään mitään sen enempää kuin tiedostojen kopiointi esim. rsync:llä (tosin en ole varma tarkoititko nyt tätä dd/rsync vertailua vai koko järjestelmän palauittamista ylipäätänsä, onhan se rync:llä tehty kopio myös "image"). Rsync pystyy myös päivittämään varmuuskopion (tai palautuksen) siten ettei kaikkea (muuttumattomia tiedostoja) tarvitse kopioida uudelleen. Dd:lle on silti käyttötarkoituksensa ja voihan se joskus (harvemmin) olla hyvä varmuuskopiovälineenäkin (jokin thin client, esim. HTPC, sääasema tms., varsinkin ei-UEFI tai Legacy BIOS-alustat joiden boottisetup eri partitioneen voi olla hyvinkin aikaavievää), mutta harvemmin x86 työpöytäkoneen varmuuskopiointiin järkevä vaihtoehto. On siinä ainakin semmoinen hyvä puoli, että se on paljon yksinkertaisempi oppia käyttämään, mutta rsync:n opettelua varten joutuu lukemaan n 30 minuuttia esim. Archin wikistä käyttövinkkejä sopivan skriptin tekemistä varten.

Asetustiedostoja ei pitäisi olla hirveän monessa paikassa tyypillisessä Linux-järjestelmässä, vaikka käyttötarkoitus olisikin hyvin spesiaali (jos on, niin kannattaa miettiä tekeekö jotain väärin / olisiko fiksumpi ratkaisu). Mutta toisaalta Linuxeja voi käyttää ihan helkatin monella eri tavalla. Ihan varmasti voi olla jokin sellainenkin käyttötapa, että joutuu puukottelemaan sieltä sun täältä järjestelmää käsin ja koko järjestelmän varmuuskopiointi/palautus tarvittaessa voi olla järkevää. Lisäksi, distron asennusohjelma (paketinhallinta) hakee jokaisen paketin ja purkaa ne erikseen uudelleenasennuksessa, mikä on jkv hitaahko prosessi. Koko järjestelmän palautus (rsync-varmuuskopioista tai jopa dd:llä) voi olla huomattavasti nopeampaa kuin uudelleenasennus ja asetustiedostojen palautus, varsinkin jos se on kohtuu tuore.

Pointti siis, mitään yleispätevää ohjetta ei voi antaa oikean työkalun tai toimintatavan valintaan. Itse kukin valitsee omaan käyttötarkoitukseen parhaimman. Nämä keskustelut on kuitenkin tarkoitettu vinkeiksi.

Jos pari kertaa vuodessa muistais imagen luoda niin saattaa selvitä suht.vähällä säätämisellä?

Mitään yleispätevää sääntöä varmuuskoioiden tekemisen tiheydelle on käytännössä hankalaa antaa, käyttötarpeita ja tapoja on niin helkkaristi. Ts. jokainen tekee tyylillään, mutta koska varmuuskopioiden tekeminen on tylsää, kannattaa harkita tämän automatisoimista ainakin osittain (muuten jää helposti tekemättä =) ). Itse ajattelen myös dataa vähän kerroksina, joistain asioista haluaa varmuuskopiot tiheästi esim. fat fingers tms. -virheitä varten tavalla X (snapshottaava tiedostojärjestelmä!), työn alla olevat asiat myös pilveen / git-repoon / rsync:llä tms. netin yli, joistain tiedostoista (esim. asetustiedostot) keskipitkällä tavalla Y, ja joistain (koko järjestelmästä?) hyvin harvoin (esim. 1x/6kk) tavalla Z.

Jos varmuuskopion koon pitää pienenä, on automatisoinnille helpompaa / käytännöllisempää ja halvempaa löytää paikka esim. netin yli (pilvestä, toiselta palvelimelta / koneelta...).

 

[Gandalf]

On niin paljon erilaisia konffeja koko linuxissa että vaikka selaimista, palomuureista, firejail & apparmorit yms. kaikista sais tiedostoina talteen, on niiden palauttaminen sen verran työlästä että koko imagen palauttaminen kerralla taitaa olla parempi ratkaisu. Tai vaihtoehto b, niin lopettaa se säätäminen ja tyytyä johonkin "tuunaamattomaan" perusympäristöön mitä en vielä halua.

On käyttötiedostoista siis kuitenkin ne backupit tietenkin on myös olemassa. Ja vaikka imagen palauttamisen yhteydessä joutuis jonkun verran säätämäänkin grubia tai muuta taitaa se nopeampaa silti olla käyttövalmiina kuin nykytavalla. Distroina yleensä on jatkuvasti päivittyvät joten ei pitäis hirveästi säätämistä olla. Jos pari kertaa vuodessa muistais imagen luoda niin saattaa selvitä suht.vähällä säätämisellä?

Yleensä käyttöjärjestelmät desktopille ovat melko valmiita että ei minuuttia kauempaa tarvitse kliksutella ja sillä sitten menee vuosia. Mutta jos menee jatkuvasti päivittyvällä tai sellaisella joka päivittyy pari kertaa vuodessa, eli näitä kehittäjille suunnattuja tuoretta tekniikkaa niin voi olla harmeja tiedossa jos enemmänkin säätää kun tietenkin ohjelmissa voi ominaisuudet muuttua. Oletus on se, että siellä ei ole mitään migraatiota ohjelmoitu versioiden välille jos jossain muutoksia, että sitten pitää varustautua korjailemaan jos vanhat konffit ei pelaa. Palvelimessa sitten on omat niksit millä automatisoidaan asioita.

Itse desktopilla tosiaankin asennan vaan tikulta uuden, teen pienet muutokset ja muutan jos tarvetta tulee enkä tee yhtään mitään backuppia järjestelmälle. Ainoastaan kotikansion tiedostot talteen. Jos kiintolevy paukahtaa niin ihan sama, uuden käyttöjärjestelmän asentaa tuoreesta asennusimagesta kuitenkin nopeasti.

 

[=JP=]

Pitäisi jaksaa tutustua noihin immutable jakeluihin, että miten toimivat ja miten vaikeaa niiden ylläpito on. Olisiko tuollaisesta vaikka peruskäyttäjälle hyötyä, koska ei voi pistää sekaisin ainakaan helposti.

Tällä hetkellä OpenSuSe Tumbleweed aktiivikäytössä ja siinä tuo Snapper, joka hyödyntää Btrfs on kyllä kätevä, ku voi roll back vetästä milloin vaan, jos vaikka päivitys menee persiilleen, niin bootin jälkeen takas edelliseen tilaan. Tämähän ei tietenkään auta, jos vaikka levy hajoaa, sitä varten on sitten oltava oikeat varmuuskopiot...

 

[Pah0lain3]

Minun on vähän hankala nyt pysyä kärryillä ylläolevan vastauksen ydinajatuksen kanssa, mutta koetan silti kommentoida jotain:


Imagen tekeminen ei palauta yhtään mitään sen enempää kuin tiedostojen kopiointi esim. rsync:llä (tosin en ole varma tarkoititko nyt tätä dd/rsync vertailua vai koko järjestelmän palauittamista ylipäätänsä, onhan se rync:llä tehty kopio myös "image"). Rsync pystyy myös päivittämään varmuuskopion (tai palautuksen) siten ettei kaikkea (muuttumattomia tiedostoja) tarvitse kopioida uudelleen. Dd:lle on silti käyttötarkoituksensa ja voihan se joskus (harvemmin) olla hyvä varmuuskopiovälineenäkin (jokin thin client, esim. HTPC, sääasema tms., varsinkin ei-UEFI tai Legacy BIOS-alustat joiden boottisetup eri partitioneen voi olla hyvinkin aikaavievää), mutta harvemmin x86 työpöytäkoneen varmuuskopiointiin järkevä vaihtoehto. On siinä ainakin semmoinen hyvä puoli, että se on paljon yksinkertaisempi oppia käyttämään, mutta rsync:n opettelua varten joutuu lukemaan n 30 minuuttia esim. Archin wikistä käyttövinkkejä sopivan skriptin tekemistä varten.

Asetustiedostoja ei pitäisi olla hirveän monessa paikassa tyypillisessä Linux-järjestelmässä, vaikka käyttötarkoitus olisikin hyvin spesiaali (jos on, niin kannattaa miettiä tekeekö jotain väärin / olisiko fiksumpi ratkaisu). Mutta toisaalta Linuxeja voi käyttää ihan helkatin monella eri tavalla. Ihan varmasti voi olla jokin sellainenkin käyttötapa, että joutuu puukottelemaan sieltä sun täältä järjestelmää käsin ja koko järjestelmän varmuuskopiointi/palautus tarvittaessa voi olla järkevää. Lisäksi, distron asennusohjelma (paketinhallinta) hakee jokaisen paketin ja purkaa ne erikseen uudelleenasennuksessa, mikä on jkv hitaahko prosessi. Koko järjestelmän palautus (rsync-varmuuskopioista tai jopa dd:llä) voi olla huomattavasti nopeampaa kuin uudelleenasennus ja asetustiedostojen palautus, varsinkin jos se on kohtuu tuore.

Pointti siis, mitään yleispätevää ohjetta ei voi antaa oikean työkalun tai toimintatavan valintaan. Itse kukin valitsee omaan käyttötarkoitukseen parhaimman. Nämä keskustelut on kuitenkin tarkoitettu vinkeiksi.



Mitään yleispätevää sääntöä varmuuskoioiden tekemisen tiheydelle on käytännössä hankalaa antaa, käyttötarpeita ja tapoja on niin helkkaristi. Ts. jokainen tekee tyylillään, mutta koska varmuuskopioiden tekeminen on tylsää, kannattaa harkita tämän automatisoimista ainakin osittain (muuten jää helposti tekemättä =) ). Itse ajattelen myös dataa vähän kerroksina, joistain asioista haluaa varmuuskopiot tiheästi esim. fat fingers tms. -virheitä varten tavalla X (snapshottaava tiedostojärjestelmä!), työn alla olevat asiat myös pilveen / git-repoon / rsync:llä tms. netin yli, joistain tiedostoista (esim. asetustiedostot) keskipitkällä tavalla Y, ja joistain (koko järjestelmästä?) hyvin harvoin (esim. 1x/6kk) tavalla Z.

Jos varmuuskopion koon pitää pienenä, on automatisoinnille helpompaa / käytännöllisempää ja halvempaa löytää paikka esim. netin yli (pilvestä, toiselta palvelimelta / koneelta...).

Sori, oman kirjoituksen ulosanti ei ole parasta mahdollista
Yritin kuvailla omia tilanteita ja tarpeita, mutta ehkä meni pieleen.

Ei minulle ole mitään väliä millä sen imagen tekee tai opettelee tekemään. Kaikki keinot oli tervetulleita ideoita. Rescuezilla osui ja uppos hyvin. Rsync on myös kyllä muistiin laitettu. Mitä halvemmaksi tulee niin sen parempi. Tarkoitus oli yrittää vähän helpottaa tätä freshinstallin jälkeista säätämistä kun täytyy selaimien ja sen lisäosien backupit palauttaa. Konffata apparmorit sekä firejailit yms "sadat" pikkujutut. Tässä ei ole mitään varsinaista päämäärää ollu koskaan, tämä on vain kiva harrastus. Kokoajan vastaan tulee uutta. Tulee käytettyä paljon just näitä rolling release distroja.

on hyvää keskustelua. Ihan varmasti nämä hommat pystyisi tekemään paremmallakin tapaa, mutta en ole vielä siinä vaiheessa mielestäni. Pikkuhiljaa. Jotkut asiat täytyy vaan ottaa vähän lievemmällä oppimiskäyrällä.

 

[Pah0lain3]

Pitäisi jaksaa tutustua noihin immutable jakeluihin, että miten toimivat ja miten vaikeaa niiden ylläpito on. Olisiko tuollaisesta vaikka peruskäyttäjälle hyötyä, koska ei voi pistää sekaisin ainakaan helposti.

Tällä hetkellä OpenSuSe Tumbleweed aktiivikäytössä ja siinä tuo Snapper, joka hyödyntää Btrfs on kyllä kätevä, ku voi roll back vetästä milloin vaan, jos vaikka päivitys menee persiilleen, niin bootin jälkeen takas edelliseen tilaan. Tämähän ei tietenkään auta, jos vaikka levy hajoaa, sitä varten on sitten oltava oikeat varmuuskopiot...

Mulla on menny niin monet kerran Endeavouros jakelun kanssa hommat pieleen kun tuo jakelu tiputtaa päivityksiä todella tiuhaan ja välillä tuntuu etteivät edes testaa toimivatko ne, kun jää vain mustaan ruutuun oma tietokone. Tää backup image on ollu pitkään mielessä jo mutta nyt vasta sain aikaiseksi kysellä, mutta joskus tästä olis ollu valtava apu monet kerrat Nää omat jutut vois varmasti toteuttaa paremminkin, mutta näillä on nyt mentävä. Ehkä tuo rescuezilla tai rsync tulee antamaan isot avustukset. Täytyy vaan riittävän iso ssd vielä tilata ja aika näyttää kokeeko sen sitten tarpeelliseksi vai hankaloittaako entisestään.

 

[JiiPee]

Dd:n käytöstä varmuuskopioihin - kannattaa ymmärtää miksi se (tai vastaava) saattaa ola huono työkalu, ja valita mieluiten oikea sopivampi työkalu, riippuen siitä mikä on päämäärä. Dd voi olla ihan ok mutta usein ei ole!

Alkuperäinen kysymyshän oli imagen teosta ja siihen tarkoitukseen rsync on kyllä täysin väärä työkalu.

 

[keskiverto]

Alkuperäinen kysymyshän oli imagen teosta ja siihen tarkoitukseen rsync on kyllä täysin väärä työkalu.

Tuo on totta. Aina ei kuitenkaan ole varma, onko kysymys:
1. Kuinka kopioida image?
vai
2. Kuinka kopioida image (koska haluan varmuuskopioita)?

Molempiin voi vastata vaikka 'dd', mutta jälkimmäisen kanssa pitäisi miettiä onko image todella paras tapa tehdä varmuuskopioita.

 

[Pah0lain3]

Riittääkö tuon xz-utils takaportin kanssa etttä sshd on disabloituna kotikoneessa? mutta onko tietoa aiheuttaako tuo takaportti itse jotain muutoksia jossain?

Luin jostain uutisesta että githubin xz kehittäjätilit ois laitettu jäihin, eli eikö siihen ole edes tulossa paikkausta?
xz --version komento näyttää että vielä ois käytössä tästä vanha versio kun en ole kerennyt päivittää, mutta kannattaako edes päivittää kun sitten se päivittää vaan tuohon takaporttiversioon?

Kuitenkin Arch linuxin tiedotteessa kehotetaan päivittämään välittömästi...

TL;DR: Upgrade your systems and container images now!

 

[ltrvs]

Riittääkö tuon xz-utils takaportin kanssa etttä sshd on disabloituna kotikoneessa?

Eikös se tämän hetken tietämyksellä veivannut itsensä sshd:n kylkeen niin, että hyväksyy tietyllä avaimella komennot pahantahtoiselta hyökkääjältä. Eli sshd:n disablointi riittäisi.

Ei aiheutuisi vaaraa, mutta onko tietoa aiheuttaako tuo takaportti itse jotain muutoksia jossain?

Käsittääkseni ei ole tietoa että aiheuttaisi muita muutoksia, mutta tutkimukset kesken eikä varmuutta että tekeekö muutakin.

Luin jostain uutisesta että githubin xz kehittäjätilit ois laitettu jäihin, eli eikö siihen ole edes tulossa paikkausta?

Github pistänyt jäihin, mutta kehittäjä yhä aktiivisena, ks. XZ Utils backdoor , muun infon seassa suunnitelmaa julkaisusta:
"A clean XZ Utils release version could jump to 5.8.0"

mutta kannattaako edes päivittää kun sitten se päivittää vaan tuohon takaporttiversioon?

Arch Linux - News: The xz package has been backdoored mukaan 5.6.0-1 ja 5.6.1-1 sisältää takaoven, kun taas 5.6.1-2 ei.

 

[Pah0lain3]

Eikös se tämän hetken tietämyksellä veivannut itsensä sshd:n kylkeen niin, että hyväksyy tietyllä avaimella komennot pahantahtoiselta hyökkääjältä. Eli sshd:n disablointi riittäisi.
Käsittääkseni ei ole tietoa että aiheuttaisi muita muutoksia, mutta tutkimukset kesken eikä varmuutta että tekeekö muutakin.
Github pistänyt jäihin, mutta kehittäjä yhä aktiivisena, ks. XZ Utils backdoor , muun infon seassa suunnitelmaa julkaisusta:
"A clean XZ Utils release version could jump to 5.8.0"

Arch Linux - News: The xz package has been backdoored mukaan 5.6.0-1 ja 5.6.1-1 sisältää takaoven, kun taas 5.6.1-2 ei.

Kiitos, nyt tuo on aika selvää koko homma.

 

[Kaalip]

Joidenkin lähteiden mukaan koko takaovi ei edes vaikuttanut Arch käyttäjiin ollenkaan.

 

[Barbarossa]

Joidenkin lähteiden mukaan koko takaovi ei edes vaikuttanut Arch käyttäjiin ollenkaan.

Tämä perustuu (tai perustui) siihen että opensshd ei itsessään linkittele liblzma:an, mutta jotkut distrot käyttävät patchattua opensshd:ta joka linkittää libsystemd:n mukaan ("laiska" keino sd_notifyn käyttämiseksi). Libsystemd taas linkittää liblzma:n jota kautta se päätyisi tällä tavalla patchatulla sshd:llä matkaan.

Kaikki distrot eivät tuota patchia käytä, ilmeisesti Arch on yksi näistä.

Mutta tuo "ei koske Archia" väittämä pätee ainoastaan siinä tapauksessa tuota linkitysketjua sshd:hen ei synny mitään muutakaan reittiä pitkin, minkä yksiselitteinen varmistaminen ei ole aivan kevyesti luvattavissa.

Tästä(kin) syystä nuo sorkitut versiot on varmuuden vuoksi pannassa kaikkialla. Osa, esim. Gentoo, poisti varmuuden vuoksi myös 5.4.x versiot joiden rellipaketit ovat Jia Tanin allekirjoittamia vaikka näihin ei oltu vielä koiruuksia lisäilty.

 

[Enforcer]

Osaako joku linux velho sanoa, mitä pci express root porttia mun samsungin nvme käyttää? Pitäisi siis biosesta käydä muuttamassa pari asetusta, mutta niin palikka etten ymmärrä, mikä porttia tuo nyt käyttää. Porttei mitä siellä voi muuttaa on 1,7,9-12.

Spoileri: lspci -v

00:00.0 Host bridge: Intel Corporation Device 4617
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0
Capabilities: [e0] Vendor Specific Information: Len=14 <?>

00:02.0 VGA compatible controller: Intel Corporation Alder Lake-N [UHD Graphics] (prog-if 00 [VGA controller])
DeviceName: Onboard - Video
Subsystem: Intel Corporation Alder Lake-N [UHD Graphics]
Flags: bus master, fast devsel, latency 0, IRQ 159
Memory at 6000000000 (64-bit, non-prefetchable) [size=16M]
Memory at 4000000000 (64-bit, prefetchable) [size=256M]
I/O ports at 3000
Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
Capabilities: [40] Vendor Specific Information: Len=0c <?>
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [100] Process Address Space ID (PASID)
Capabilities: [200] Address Translation Service (ATS)
Capabilities: [300] Page Request Interface (PRI)
Capabilities: [320] Single Root I/O Virtualization (SR-IOV)
Kernel driver in use: i915
Kernel modules: i915

00:0d.0 USB controller: Intel Corporation Device 464e (prog-if 30 [XHCI])
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: medium devsel, IRQ 128
Memory at 6001010000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Capabilities: [90] Vendor Specific Information: Len=14 <?>
Capabilities: [b0] Vendor Specific Information: Len=00 <?>
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.0 USB controller: Intel Corporation Device 54ed (prog-if 30 [XHCI])
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, medium devsel, latency 0, IRQ 137
Memory at 6001000000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Capabilities: [90] Vendor Specific Information: Len=14 <?>
Capabilities: [b0] Vendor Specific Information: Len=00 <?>
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 RAM memory: Intel Corporation Device 54ef
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: fast devsel
Memory at 6001020000 (64-bit, non-prefetchable) [disabled] [size=16K]
Memory at 600102a000 (64-bit, non-prefetchable) [disabled] [size=4K]
Capabilities: [80] Power Management version 3

00:15.0 Serial bus controller: Intel Corporation Device 54e8
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 27
Memory at 4017000000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [80] Power Management version 3
Capabilities: [90] Vendor Specific Information: Len=14 <?>
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:15.1 Serial bus controller: Intel Corporation Device 54e9
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 40
Memory at 4017001000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [80] Power Management version 3
Capabilities: [90] Vendor Specific Information: Len=14 <?>
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:16.0 Communication controller: Intel Corporation Device 54e0
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 158
Memory at 6001027000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3
Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [a4] Vendor Specific Information: Len=14 <?>
Kernel driver in use: mei_me
Kernel modules: mei_me

00:1c.0 PCI bridge: Intel Corporation Device 54be (prog-if 00 [Normal decode])
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 122
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: [disabled] [16-bit]
Memory behind bridge: 80a00000-80bfffff [size=2M] [32-bit]
Prefetchable memory behind bridge: [disabled] [64-bit]
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Intel Corporation Device 7270
Capabilities: [a0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [220] Access Control Services
Capabilities: [150] Precision Time Measurement
Capabilities: [a30] Secondary PCI Express
Kernel driver in use: pcieport

00:1d.0 PCI bridge: Intel Corporation Device 54b0 (prog-if 00 [Normal decode])
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 123
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: [disabled] [16-bit]
Memory behind bridge: 80800000-809fffff [size=2M] [32-bit]
Prefetchable memory behind bridge: [disabled] [64-bit]
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Intel Corporation Device 7270
Capabilities: [a0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [220] Access Control Services
Capabilities: [150] Precision Time Measurement
Capabilities: [a30] Secondary PCI Express
Kernel driver in use: pcieport

00:1d.1 PCI bridge: Intel Corporation Device 54b1 (prog-if 00 [Normal decode])
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 124
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: [disabled] [16-bit]
Memory behind bridge: 80600000-807fffff [size=2M] [32-bit]
Prefetchable memory behind bridge: [disabled] [64-bit]
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Intel Corporation Device 7270
Capabilities: [a0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [220] Access Control Services
Capabilities: [150] Precision Time Measurement
Capabilities: [a30] Secondary PCI Express
Kernel driver in use: pcieport

00:1d.2 PCI bridge: Intel Corporation Device 54b2 (prog-if 00 [Normal decode])
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 125
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
I/O behind bridge: [disabled] [16-bit]
Memory behind bridge: 80400000-805fffff [size=2M] [32-bit]
Prefetchable memory behind bridge: [disabled] [64-bit]
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Intel Corporation Device 7270
Capabilities: [a0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [220] Access Control Services
Capabilities: [150] Precision Time Measurement
Capabilities: [a30] Secondary PCI Express
Kernel driver in use: pcieport

00:1d.3 PCI bridge: Intel Corporation Device 54b3 (prog-if 00 [Normal decode])
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 126
Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
I/O behind bridge: [disabled] [16-bit]
Memory behind bridge: 80c00000-80cfffff [size=1M] [32-bit]
Prefetchable memory behind bridge: [disabled] [64-bit]
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Intel Corporation Device 7270
Capabilities: [a0] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [220] Access Control Services
Capabilities: [150] Precision Time Measurement
Capabilities: [a30] Secondary PCI Express
Kernel driver in use: pcieport

00:1e.0 Communication controller: Intel Corporation Device 54a8
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at 4017002000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [80] Power Management version 3
Capabilities: [90] Vendor Specific Information: Len=14 <?>
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:1e.3 Serial bus controller: Intel Corporation Device 54ab
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0, IRQ 37
Memory at 4017003000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [80] Power Management version 3
Capabilities: [90] Vendor Specific Information: Len=14 <?>
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:1f.0 ISA bridge: Intel Corporation Device 5481
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: bus master, fast devsel, latency 0

00:1f.4 SMBus: Intel Corporation Device 54a3
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: medium devsel, IRQ 16
Memory at 6001024000 (64-bit, non-prefetchable)
I/O ports at efa0
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801

00:1f.5 Serial bus controller: Intel Corporation Device 54a4
DeviceName: Onboard - Other
Subsystem: Intel Corporation Device 7270
Flags: fast devsel
Memory at 80d00000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: intel-spi
Kernel modules: spi_intel_pci

01:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
Subsystem: Intel Corporation Ethernet Controller I226-V
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at 80a00000 (32-bit, non-prefetchable) [size=1M]
Memory at 80b00000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number a8-b8-e0-ff-ff-01-ef-29
Capabilities: [1c0] Latency Tolerance Reporting
Capabilities: [1f0] Precision Time Measurement
Capabilities: [1e0] L1 PM Substates
Kernel driver in use: igc
Kernel modules: igc

02:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
Subsystem: Intel Corporation Ethernet Controller I226-V
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at 80800000 (32-bit, non-prefetchable) [size=1M]
Memory at 80900000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number a8-b8-e0-ff-ff-01-ef-2a
Capabilities: [1c0] Latency Tolerance Reporting
Capabilities: [1f0] Precision Time Measurement
Capabilities: [1e0] L1 PM Substates
Kernel driver in use: igc
Kernel modules: igc

03:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
Subsystem: Intel Corporation Ethernet Controller I226-V
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at 80600000 (32-bit, non-prefetchable) [size=1M]
Memory at 80700000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number a8-b8-e0-ff-ff-01-ef-2b
Capabilities: [1c0] Latency Tolerance Reporting
Capabilities: [1f0] Precision Time Measurement
Capabilities: [1e0] L1 PM Substates
Kernel driver in use: igc
Kernel modules: igc

04:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
Subsystem: Intel Corporation Ethernet Controller I226-V
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at 80400000 (32-bit, non-prefetchable) [size=1M]
Memory at 80500000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number a8-b8-e0-ff-ff-01-ef-2c
Capabilities: [1c0] Latency Tolerance Reporting
Capabilities: [1f0] Precision Time Measurement
Capabilities: [1e0] L1 PM Substates
Kernel driver in use: igc
Kernel modules: igc

05:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 (prog-if 02 [NVM Express])
Subsystem: Samsung Electronics Co Ltd SSD 970 EVO
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at 80c00000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [b0] MSI-X: Enable+ Count=33 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [148] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [158] Power Budgeting <?>
Capabilities: [168] Secondary PCI Express
Capabilities: [188] Latency Tolerance Reporting
Capabilities: [190] L1 PM Substates
Kernel driver in use: nvme
Kernel modules: nvme

Spoileri: lspci -t

-[0000:00]-+-00.0
+-02.0
+-0d.0
+-14.0
+-14.2
+-15.0
+-15.1
+-16.0
+-1c.0-[01]----00.0
+-1d.0-[02]----00.0
+-1d.1-[03]----00.0
+-1d.2-[04]----00.0
+-1d.3-[05]----00.0
+-1e.0
+-1e.3
+-1f.0
+-1f.4
\-1f.5

PS. Muutin asetuksen jokaisesta pcie root portista niin näyttää toimivan..

 

[Ryzkis40]

Onkohan kovin yleistä Linuxissa ettei kaikilla hiirillä kaikki napit toimi? Itsellä Deltacon langaton ja alkuun testaamassani Garudassa näin että peukalon eteen/taakse-nappulat ei tunnistu lainkaan. Unohdin linuxin hetkeksi kunnes innostuin testailemaan taas Minttiä ja siinäkin sama homma. Netin ohjeet neuvoo kalastelemaan terminaalissa inputtipalautteen perusteella nappien numerot ja määrittelemään ne uudelleen conffitiedostoon mutta itsellä nuo napit vaikuttaa olevan täysin pois pelistä eikä minkäänlaista palautetta tule, eli liekö sitten mitään tehtävissä?

 

[Hyrava]

Onkohan kovin yleistä Linuxissa ettei kaikilla hiirillä kaikki napit toimi? Itsellä Deltacon langaton ja alkuun testaamassani Garudassa näin että peukalon eteen/taakse-nappulat ei tunnistu lainkaan. Unohdin linuxin hetkeksi kunnes innostuin testailemaan taas Minttiä ja siinäkin sama homma. Netin ohjeet neuvoo kalastelemaan terminaalissa inputtipalautteen perusteella nappien numerot ja määrittelemään ne uudelleen conffitiedostoon mutta itsellä nuo napit vaikuttaa olevan täysin pois pelistä eikä minkäänlaista palautetta tule, eli liekö sitten mitään tehtävissä?

Ei tuo ainakaan hirveän yleistä ole kun itselläni on Ubuntu/Xubuntu/Debian -koneissa viimeisten 10v aikana ainakin 6 eri Microsoftin tai Logitechin hiiren sivunapit toimineet ihan suoraan. En sitten tiedä onko tuossa Deltacossa jotenkin epästandardisti tehty nuo sivunapit.

 

[SamCer]

Onkohan kovin yleistä Linuxissa ettei kaikilla hiirillä kaikki napit toimi? Itsellä Deltacon langaton ja alkuun testaamassani Garudassa näin että peukalon eteen/taakse-nappulat ei tunnistu lainkaan. Unohdin linuxin hetkeksi kunnes innostuin testailemaan taas Minttiä ja siinäkin sama homma. Netin ohjeet neuvoo kalastelemaan terminaalissa inputtipalautteen perusteella nappien numerot ja määrittelemään ne uudelleen conffitiedostoon mutta itsellä nuo napit vaikuttaa olevan täysin pois pelistä eikä minkäänlaista palautetta tule, eli liekö sitten mitään tehtävissä?

Deltacon kohdalla kyllä, on normaalia, että heidän hiiret ei toimi kunnolla Linuxin kanssa. Noitten halppis pommien kanssa oot ihan oman onnes varassa... Linux nojaa standardeihin, Windows taas nojaa Microsoftiin...

 

[Ryzkis40]

Jahas, eli paree ilmeisesti olla sitten laadukas merkkihiiri näiden Linuxien kanssa. Mielenkiintoista sinällään kun Windowsissa käsittääkseni kuitenkin ihan standardiajureilla toimii nämä halppikset eikä niille tarvi mitään omia asennella, että luulisi sitten jonkin sortin standardeja noudattavan mutta ilmeisesti Mikkisoftan standardit ei ole samat kuin Linuxilla sitten.

 

[SamCer]

Jahas, eli paree ilmeisesti olla sitten laadukas merkkihiiri näiden Linuxien kanssa. Mielenkiintoista sinällään kun Windowsissa käsittääkseni kuitenkin ihan standardiajureilla toimii nämä halppikset eikä niille tarvi mitään omia asennella, että luulisi sitten jonkin sortin standardeja noudattavan mutta ilmeisesti Mikkisoftan standardit ei ole samat kuin Linuxilla sitten.

Aikoinaan esim. nettisivut piti suunnitella erikseen yhdet sivut Microsoftin Internet Explorerille ja toiset muille selaimille, kun IE noudatti Microsoftin omia "standerdeja". Ja olikohan se PPP-protokolla, josta Microsoft halusi, että se kirjoitettaisiin uudestaan kun heidän toteutus ei toimi muiden kanssa yhteen. Tuolloin prokollan kehittäjän eivät suostuneet asiaan ja jopa Microsoft joutui sillä kertaa taipumaan ja korjaamaan oman toteutuksen standardin mukaiseksi. Ja tuohon vielä asiakirjastandardi kaaos (oliko se nyt odt, joka haluttiin ainoaksi formaatiksi), kun Micosoftille ei kelvannut avoin OpenDocument-formaatti, vaan halusi väkisin oman formaatin rinnalle, joka hoitui hienosti lahjomalla porkukkaa ympärimaailmaa docx-formaatin taakse ja tulos näkyy tänäkin päivänä...

Joten joo heillä on "vähän" erilainen käsitys standardeista...

 

[Emeron]

Aikoinaan esim. nettisivut piti suunnitella erikseen yhdet sivut Microsoftin Internet Explorerille ja toiset muille selaimille, kun IE noudatti Microsoftin omia "standerdeja". Ja olikohan se PPP-protokolla, josta Microsoft halusi, että se kirjoitettaisiin uudestaan kun heidän toteutus ei toimi muiden kanssa yhteen. Tuolloin prokollan kehittäjän eivät suostuneet asiaan ja jopa Microsoft joutui sillä kertaa taipumaan ja korjaamaan oman toteutuksen standardin mukaiseksi. Ja tuohon vielä asiakirjastandardi kaaos (oliko se nyt odt, joka haluttiin ainoaksi formaatiksi), kun Micosoftille ei kelvannut avoin OpenDocument-formaatti, vaan halusi väkisin oman formaatin rinnalle, joka hoitui hienosti lahjomalla porkukkaa ympärimaailmaa docx-formaatin taakse ja tulos näkyy tänäkin päivänä...

Joten joo heillä on "vähän" erilainen käsitys standardeista...

Microsoftin vika kun hiiri ei toimi Linuksissa? Vai miten tämä vuodatus tulisi tulkita

 

[Viilee]

Tulkitsin avautumisen siten, että isot toimijat, joilla on paljon valtaa (/rahaa), kusee standardien päälle, jos siihen vain on jokin kannustin (vendor-lock-inin mahdollisuus, datan keräys tms.), ja saa valitettavan usein myös tahtonsa läpi.

Hiiristä puheenollen, ei ole vielä koskaan tullut vastaan hiirtä joka ei toimisi standardina HID-hiirenä. Melkeinpä niin päin, että kalliimmissa spesiaalihiirissä joissa on jos jonkinlaista hilavitkutinta ja erikoisominaisuutta, on osa ominaisuuksista saattanut olla jonkin erityisemmän, mutta kuitenkin jonkin kohtuullisen standardin, takana. Osa erikoisnapeista voi ollakin esim. näppäimistö Kernelin mielestä. RGB:kin on yleensä reverse-engineerattu ja saa toimimaan jollain harrasteiljoiden softalla; mutta perushiiirenä (tarkoittaa siis vähintään 5-, usein 7-nappinen osuus) toimii ihan standardiajureilla.

Toki on ihan uskottavaa, että halvimmista halvimmat tietokonehiiret (tai jotkin erät) on tehty jollain mahdollisimman halvalla saaduista ylijäämäosista, jotka ei sitten tuekaan mitään standardia, koska osat on aluperin mihinlie puoliksi suljettuun tarkoitukseen tehty. Siis tarkoitan, että uskon kyllä ylläolevan keskustelun, Deltacon hiiret ei toimi, mutta varmaankin poikkeus?

Noin ihan mielenkiinnosta ja ehkä jopa hyödyllisenä tietona, näkisin miten ko. hiiri näkyy lsusb:n listauksessa (erityisesti valmistajan ja osan id:t kiinnostaa, eli ne xxxx:yyyy -numerosarjat, varsinkin jos niitä on monta) ja mitä xev ja evtest sanoo.

EDIT: Linuxille ei todellakaan tarvitse ostaa kalliimpaa ja erityisen laadukasta hiirtä. Ongelmat näitten kanssa on todella harvinaisia.

 

[Barbarossa]

Pintapuolisesti yksinkertainen asia mutta koska kyseessä USB niin mikään ei olekaan enää yksioikoista jos kurkistaa syvemmälle. Aihe on melko monimutkainen eikä riitä aika tai motivaatio kovin syvällistä tekstiä kirjoittamaan, mutta raapaisen vähän pintaa:

USB HID Class speksin mukaiset hiiret ja näppikset pääsääntöisesti toimivat Linuxissakin ilman ylimääräisiä säätöjä, peliohjaimetkin mutta näiden tukeminen on paljolti pelistä kiinni. Toki täydellistä maailmaa ei olekaan ja kaskessa voi olla monta kantoa, tässä muutama toivottavasti havainnollistava esimerkki osin omien havaintojen pohjalta ja osin speksin rajoissa teoriaa.

Laitevalmistaja voi olla lähtenyt sooloilemaan ja tekee jotakin speksin ulkopuolista, ja vaatii ajurin joka kertoo käyttöjärjestelmälle että mitä se tekee. Yleensä ajuri on tarjolla ainoastaan Windowsille ja ellei valmistaja tiedä mitä tekee, voi olla turhauttava kokemus. Harvinaista näppisten ja hiirten kohdalla, mutta tämä on selkeä tapaus jos sellainen sattuu.

Yleisemmät tapaukset ovat kuitenkin hiukan hankalampia avata. USB HID (kuten useimmat USB luokat) luokka toimii siten että laite itse ilmoittaa isännälle (report descriptor) että mitä sen lähettämät reportit pitävät sisällään, esim. hiiren osoittimet, näppäinpainallukset, analogiohjainten asennot, ym. Ja on laitteen (valmistajan) vastuulla huolehtia että nuo descriptorit ovat järkeviä, ja että ne reportit vastaavat descriptoreita ja ovat myös kuranttia tavaraa. Kuten ylempänä jo sivuttiinkin, yksi fyysinen laite voi ilmoittaa useamman USB laitteen isännälle eikä se ole mahdotonta että vaikka jokin astetta monimutkaisempi peliohjain ilmoittaa olevansa hiiri, näppäimistö ja joystick yhtä aikaa,

Esimerkkinä hiiri. Oikea ja vasen nappi ovat aika lailla pienin yhteinen nimittäjä kaikille, nykyään myös rulla jonka painallus toimii myös keskinappina käytännössä aina. Mutta siitä eteenpäin ollaankin vähän ohuemmilla jäillä. Vaikkapa nykypäivänä ei mitenkään harvinainen hiiri, kolme nappia, rulla ja kaksi peukalonappia. Hiiri voi ilmoittaa yksinkertaisesti että nappeja on viisi, vastaanottajan päätettävissä mitä nelos ja vitosnappi tekee. Tai sitten ne lähettävätkin browser forward/backward näppäinkoodit.

Jos kiinnostaa ryömiä kaninkoloon niin kernelin dokkari Introduction to HID report descriptors — The Linux Kernel documentation lienee hyvä alkupiste.

 

[ylivoima]

Mikä open source vaihtoehtoa suosittelette officen korvaajaksi ubuntulle?

 

[IcePen]

Se mikä tulee Ubuntun matkassa..

 

[Katali]

Mikä open source vaihtoehtoa suosittelette officen korvaajaksi ubuntulle?

LibreOffice

 

[Ryzkis40]

Noin ihan mielenkiinnosta ja ehkä jopa hyödyllisenä tietona, näkisin miten ko. hiiri näkyy lsusb:n listauksessa (erityisesti valmistajan ja osan id:t kiinnostaa, eli ne xxxx:yyyy -numerosarjat, varsinkin jos niitä on monta) ja mitä xev ja evtest sanoo.

Lsusb näyttää

Bus 003 Device 002: ID 0603:0002 Novatek Microelectronics Corp. Sino Wealth keyboard/mouse 2.4 GHz receiver

xev ja evtest ei reagoi mitenkään kun painelen noita eteen/taakse-namiskoja. Muutoin tulee palautetta kaikilta muilta OK. Evtest näytti tällaista

/dev/input/event6: SINO WEALTH USB Composite Device
/dev/input/event7: SINO WEALTH USB Composite Device Mouse
/dev/input/event8: SINO WEALTH USB Composite Device System Control

Vauras on USB laite Hiiri siis Deltaco MS-776.

 

[SamCer]

Mulla on ongelmana, että en saa Rocky Linux 9.2:sta poistettua salasanalla kirjautumista ssh:lla.

# cat /etc/ssh/sshd_config

Spoileri

#    $OpenBSD: sshd_config,v 1.104 2021/07/02 05:11:21 dtucker Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

# To modify the system-wide sshd configuration, create a  *.conf  file under
#  /etc/ssh/sshd_config.d/  which will be automatically included below
Include /etc/ssh/sshd_config.d/*.conf

# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile    .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#KbdInteractiveAuthentication yes
KbdInteractiveAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
# WARNING: 'UsePAM no' is not supported in RHEL and may cause several
# problems.
#UsePAM no
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem    sftp    /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    PermitTTY no
#    ForceCommand cvs server

# cat /etc/ssh/sshd_config.d/04-ipa.conf

Spoileri

# IPA-related configuration changes to sshd_config

PubkeyAuthentication yes
##Lisätty Yubikey autentikointia varten
PubkeyAuthOptions verify-required
KerberosAuthentication no
GSSAPIAuthentication yes
UsePAM yes
ChallengeResponseAuthentication yes
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

Mistä se vielä voi vielä sen kaivaa vielä luvan sille? Ubuntu 22.04 servuissa on toi sama /etc/ssh/sshd_config.d/04-ipa.conf -tiedosto, eikä ne päästä passulla sisään, ainoastaan noi Rockyt ei suostu tottelemaan. Niin joo ja muita conffeja ei tuolla /etc/ssh/sshd_config.d -hakemistossa ole.

Sain tämän viimeinkin ratkaistua, se kun levisi myös Ubuntu Servuihini. Eli ongelmana oli se, että autentikointitavoissa näkyi järkähtämättä "KbdInteractiveAuthentication", vaikka se oli nimenomaan estetty conffeissa, jolloin pääsi kirjautumaan sisään passulla, vaikka sekin oli konffeissa estetty.

Se mikä tuon "KbdInteractiveAuthentication" pakotti päälle on "ChallengeResponseAuthentication yes", sen kun vaihtoi asentoon "ChallengeResponseAuthentication no", niin samalla katosi toi "KbdInteractiveAuthentication" sallituista autentikointi metodeista. PAM:illa ei ollut mitään tekemistä asian kanssa.