Fórum Root.cz

Hlavní témata => Server => Téma založeno: krakenpico 20. 06. 2025, 10:10:43

Název: Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 20. 06. 2025, 10:10:43
Ahoj,
mám domácí server s open suse MicroOS (immutable distro)
Procesor i5, 2x16GB RAM, 2x2TB ssd disk v RAID1 Btrfs
Používám ho jako cloud na data, fileserver běží v kontejneru. Pro vzdálený přístup je tam sshd.

Než jsem server nakonfiguroval a nebyl veřejně dostupný z internetu, vše běželo asi týden v kuse bez nějakých problémů. Jakmile je vystavený do internetu tak se po nějaké době odmlčí. Přes ssh dostávám "No route to host", ping vrací "Destination Host Unreachable". Musím ho vždy restartovat. Většinou to trvá několik hodin než se znovu zasekne.

Problém bude asi souviset s pokusem o brute force prolomení hesla na ssh. Proti tomu jsem se snažil bránit tím, že jsem nainstaloval fail2ban (max 3 pokusy za hodinu) a omezil počet spojení přes iptables (max 5 spojení za minutu). Root má přihlášení přes ssh zakázané.

V journal logu nic moc zajímavého nikdy nebylo, bylo vidět, že od určitého okamžiku se logy přestaly úplně zapisovat než jsem ho opět restartoval, nejspíš to vždy zkolabovalo dřív, než to stihlo cokoli zalogovat. V posledním logu mě praštilo do očí tohle:
Kód: [Vybrat]
Jun 18 23:15:01 hp800 irqbalance[1172]: Cannot change IRQ 140 affinity: Permission denied
Jun 18 23:15:01 hp800 irqbalance[1172]: IRQ 140 affinity is now unmanaged

Celý log z okamžiku pádu:
Kód: [Vybrat]
Jun 18 22:42:45 hp800 sshd-session[27677]: Connection closed by authenticating user root 195.178.110.160 port 47846 [preauth]
Jun 18 22:42:58 hp800 unix_chkpwd[27749]: password check failed for user (root)
Jun 18 22:42:58 hp800 sshd-session[27747]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=195.178.110.160  user=root
Jun 18 22:43:00 hp800 sshd-session[27747]: Failed password for root from 195.178.110.160 port 57328 ssh2
Jun 18 22:43:00 hp800 sshd-session[27747]: Connection closed by authenticating user root 195.178.110.160 port 57328 [preauth]
Jun 18 22:43:12 hp800 unix_chkpwd[27801]: password check failed for user (root)
Jun 18 22:43:12 hp800 sshd-session[27798]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=195.178.110.160  user=root
Jun 18 22:43:14 hp800 sshd-session[27798]: Failed password for root from 195.178.110.160 port 58334 ssh2
Jun 18 22:45:13 hp800 sshd[1526]: Timeout before authentication for connection from 195.178.110.160 to 192.168.0.106, pid = 27798
Jun 18 22:45:32 hp800 sshd-session[28442]: Invalid user delegate from 92.118.39.92 port 57098
Jun 18 22:45:32 hp800 sshd-session[28442]: pam_unix(sshd:auth): check pass; user unknown
Jun 18 22:45:32 hp800 sshd-session[28442]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=92.118.39.92
Jun 18 22:45:34 hp800 sshd-session[28442]: Failed password for invalid user delegate from 92.118.39.92 port 57098 ssh2
Jun 18 22:45:36 hp800 sshd-session[28442]: Connection closed by invalid user delegate 92.118.39.92 port 57098 [preauth]
Jun 18 22:52:42 hp800 sshd-session[30396]: Invalid user ubuntu from 92.118.39.92 port 44894
Jun 18 22:52:42 hp800 sshd-session[30396]: pam_unix(sshd:auth): check pass; user unknown
Jun 18 22:52:42 hp800 sshd-session[30396]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=92.118.39.92
Jun 18 22:52:45 hp800 sshd-session[30396]: Failed password for invalid user ubuntu from 92.118.39.92 port 44894 ssh2
Jun 18 22:52:45 hp800 sshd-session[30396]: Connection closed by invalid user ubuntu 92.118.39.92 port 44894 [preauth]
Jun 18 22:59:51 hp800 sshd-session[32351]: Connection closed by 164.92.225.16 port 58060
Jun 18 22:59:55 hp800 sshd-session[32374]: Invalid user ubuntu from 92.118.39.92 port 60930
Jun 18 22:59:55 hp800 sshd-session[32374]: pam_unix(sshd:auth): check pass; user unknown
Jun 18 22:59:55 hp800 sshd-session[32374]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=92.118.39.92
Jun 18 22:59:57 hp800 sshd-session[32374]: Failed password for invalid user ubuntu from 92.118.39.92 port 60930 ssh2
Jun 18 22:59:58 hp800 sshd-session[32374]: Connection closed by invalid user ubuntu 92.118.39.92 port 60930 [preauth]
Jun 18 23:00:00 hp800 CRON[32399]: (root) CMD (run-parts /etc/cron.hourly)
Jun 18 23:00:00 hp800 CRON[32398]: (root) CMDEND (run-parts /etc/cron.hourly)
Jun 18 23:00:27 hp800 systemd[1]: Started Timeline of Snapper Snapshots.
Jun 18 23:00:27 hp800 systemd[1]: Starting DBus interface for snapper...
Jun 18 23:00:27 hp800 systemd[1]: Started DBus interface for snapper.
Jun 18 23:00:27 hp800 systemd[1]: snapper-timeline.service: Deactivated successfully.
Jun 18 23:01:27 hp800 systemd[1]: snapperd.service: Deactivated successfully.
Jun 18 23:05:50 hp800 sshd-session[33994]: Connection closed by 45.131.155.254 port 41600
Jun 18 23:07:13 hp800 sshd-session[34363]: Invalid user ubuntu from 92.118.39.92 port 48722
Jun 18 23:07:13 hp800 sshd-session[34363]: pam_unix(sshd:auth): check pass; user unknown
Jun 18 23:07:13 hp800 sshd-session[34363]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=92.118.39.92
Jun 18 23:07:16 hp800 sshd-session[34363]: Failed password for invalid user ubuntu from 92.118.39.92 port 48722 ssh2
Jun 18 23:07:16 hp800 sshd-session[34363]: Connection closed by invalid user ubuntu 92.118.39.92 port 48722 [preauth]
Jun 18 23:11:29 hp800 sshd-session[35532]: Connection closed by 128.199.54.108 port 38072
Jun 18 23:14:32 hp800 sshd-session[36359]: Invalid user sol from 92.118.39.92 port 36514
Jun 18 23:14:32 hp800 sshd-session[36359]: pam_unix(sshd:auth): check pass; user unknown
Jun 18 23:14:32 hp800 sshd-session[36359]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=92.118.39.92
Jun 18 23:14:34 hp800 sshd-session[36359]: Failed password for invalid user sol from 92.118.39.92 port 36514 ssh2
Jun 18 23:14:35 hp800 sshd-session[36359]: Connection closed by invalid user sol 92.118.39.92 port 36514 [preauth]
Jun 18 23:15:01 hp800 irqbalance[1172]: Cannot change IRQ 140 affinity: Permission denied
Jun 18 23:15:01 hp800 irqbalance[1172]: IRQ 140 affinity is now unmanaged
-- Boot ca17436ac7904bb3b9d73398cd8c008a --
Jun 19 15:43:38 hp800 kernel: Linux version 6.15.1-1-default (geeko@buildhost) (gcc (SUSE Linux) 14.3.0, GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.43.1.20241209-7) #1 SMP PREEMPT_DYNAMIC Thu Jun  5 14:29:05 UTC 2025 (75961ad)
Jun 19 15:43:38 hp800 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.15.1-1-default root=UUID=33eda697-8a15-45d4-93af-14d5ce40ddf3 rd.timeout=60 rd.retry=45 splash=silent swapaccount=1 systemd.show_status=1 mitigations=auto quiet security=selinux selinux=1 crashkernel=312M,high crashkernel=72M,low
Jun 19 15:43:38 hp800 kernel: BIOS-provided physical RAM map:
Jun 19 15:43:38 hp800 kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
Jun 19 15:43:38 hp800 kernel: BIOS-e820: [mem 0x000000000009f000-0x00000000000fffff] reserved
Jun 19 15:43:38 hp800 kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000c268cfff] usable
Jun 19 15:43:38 hp800 kernel: BIOS-e820: [mem 0x00000000c268d000-0x00000000c398efff] reserved
Jun 19 15:43:38 hp800 kernel: BIOS-e820: [mem 0x00000000c398f000-0x00000000c3b8efff] ACPI NVS
Jun 19 15:43:38 hp800 kernel: BIOS-e820: [mem 0x00000000c3b8f000-0x00000000c3c0efff] ACPI data
...

Dále jsem nainstaloval nástroj dool a každou minutu loguji do souboru vytížení systému:
Kód: [Vybrat]
date,time,usr,sys,idl,wai,stl,read,writ,recv,send,used,free,cach,avai,#recv,#send
Jun-18,22:03:22,"0,28","0,192","99,529",0,0,0,"422161,067",692,"576,533",1857556480,28814401536,2170322944,30645948416,"1,05","0,85"
Jun-18,22:04:22,"0,25","0,206","99,543",0,0,0,"194969,6","835,2","663,733",1865502720,28806275072,2170503168,30638002176,"1,283","0,967"
Jun-18,22:05:22,"0,26","0,214","99,527",0,0,0,"194969,6","665,067","807,2",1874911232,28796686336,2170683392,30628593664,"1,067","1,233"
Jun-18,22:06:22,"0,26","0,187","99,554",0,0,0,"194969,6","949,867","706,667",1860571136,28810846208,2170863616,30642933760,"1,433","1,05"
Jun-18,22:07:22,"0,30","0,223","99,468","0,006",0,0,"750660,267","1465,067","1277,867",1867501568,28803321856,2171457536,30635954176,"1,617","1,333"
Jun-18,22:08:22,"0,25","0,214","99,541",0,0,0,"221730,133","2023,333","1779,2",1866502144,28804124672,2171654144,30637002752,"1,567","1,467"
Jun-18,22:09:22,"0,27","0,184","99,535","0,008",0,"4369,067","226645,333","710,667","480,8",1871695872,28798701568,2171883520,30631809024,"0,983","0,733"
Jun-18,22:10:22,"0,26","0,206","99,532",0,0,0,"196061,867","643,867","403,2",1860857856,28809359360,2172063744,30642647040,"0,967","0,633"
Jun-18,22:11:22,"0,24","0,22","99,541",0,0,0,"202069,333","1135,467","486,933",1872654336,28797333504,2172293120,30630850560,"1,95","0,817"
Jun-18,22:12:22,"0,27","0,192","99,538","0,003",0,0,"293546,667",884,"254,667",1866739712,28803002368,2172538880,30636765184,"1,267","0,45"
Jun-18,22:13:22,"0,25","0,212","99,535",0,0,0,"428441,6","505,867","306,667",1874444288,28794896384,2172940288,30629052416,"0,783","0,567"
Jun-18,22:14:22,"0,24","0,192","99,566",0,0,0,"46148,267","666,933","309,067",1862848512,28806434816,2172997632,30640656384,"1,05","0,533"
Jun-18,22:15:22,"0,28","0,223","99,496","0,003",0,0,"230741,333","555,2","314,933",1875341312,28793708544,2173231104,30628163584,"0,9","0,583"
Jun-18,22:16:22,"0,26","0,201","99,54",0,0,0,"598835,2","1001,733","762,133",1870766080,28797857792,2173657088,30632738816,"1,283","1,117"
Jun-18,22:17:22,"0,30","0,209","99,485","0,003",0,0,"408234,667","2413,333","2069,6",1873645568,28794585088,2174050304,30629859328,"1,9","1,783"
Jun-18,22:18:22,"0,28","0,2","99,518",0,0,0,"240298,667","498,133","254,4",1874575360,28793458688,2174246912,30628929536,"0,767","0,45"
Jun-18,22:19:22,"0,26","0,209","99,532",0,0,0,"194969,6","1217,333","356,267",1881182208,28786671616,2174427136,30622322688,"1,833","0,683"
Jun-18,22:20:22,"0,25","0,189","99,557","0,003",0,0,"254225,067","995,6","375,733",1875509248,28792098816,2174672896,30627995648,"1,8","0,767"
Jun-18,22:21:22,"0,25","0,198","99,552",0,0,0,"209169,067","726,133","411,467",1853005824,28814401536,2174873600,30650494976,"1,217","0,783"
Jun-18,22:22:22,"0,24","0,189","99,574",0,0,0,"213538,133","993,467","334,133",1871040512,28796190720,2175049728,30632464384,"1,75","0,667"
Jun-18,22:23:22,"0,25","0,2","99,552",0,0,0,"196061,867","596,8","348,8",1872044032,28795006976,2175229952,30631460864,"1,033","0,7"
Jun-18,22:24:22,"0,30","0,22","99,479","0,006",0,0,"608938,667","899,467","718,667",1868247040,28798238720,2175795200,30635257856,"1,05","0,917"
Jun-18,22:25:22,"0,25","0,195","99,552","0,003",0,0,"194423,467","449,067","299,2",1868079104,28798242816,2175959040,30635425792,"0,717","0,583"
Jun-18,22:26:22,"0,26","0,212","99,432","0,1",0,0,"197427,2","697,067","430,667",1888088064,28778053632,2176139264,30615416832,"1,083","0,767"
Jun-18,22:27:22,"0,27","0,418","99,312","0,003",0,0,"768955,733","479,2","299,2",1876602880,28788805632,2176872448,30626897920,"0,767","0,583"
Jun-18,22:28:22,"0,25","0,195","99,552","0,003",0,0,"580266,667","491,2","288,267",1879494656,28785459200,2177327104,30624010240,"0,767","0,55"
Jun-18,22:29:22,"0,24","0,2","99,557",0,0,0,"237841,067","693,733","542,933",1874882560,28789841920,2177556480,30628622336,"1,1","0,95"
Jun-18,22:30:22,"0,26","0,192","99,552",0,0,0,"46148,267","409,6","269,6",1877225472,28787433472,2177622016,30626279424,"0,6","0,483"
Jun-18,22:31:22,"0,27","0,217","99,51","0,003",0,0,"226918,4","926,133","731,467",1872613376,28791812096,2177855488,30630891520,"1,067","0,9"
Jun-18,22:32:22,"0,25","0,212","99,535",0,0,0,"571528,533","417,733","320,267",1862508544,28801458176,2178297856,30640988160,"0,667","0,6"
Jun-18,22:33:22,"0,30","0,184","99,521",0,0,0,45056,"6276,4","4184,8",1865687040,28798197760,2178379776,30637809664,"3,633","2,833"
Jun-18,22:34:22,"0,25","0,206","99,54","0,003",0,0,561152,"930,8","335,2",1856032768,28807442432,2178789376,30647463936,"1,283","0,6"
Jun-18,22:35:22,"0,25","0,203","99,543",0,0,0,"68539,733","549,6","350,133",1863479296,28799930368,2178854912,30640017408,"0,933","0,683"
Jun-18,22:36:22,"0,23","0,187","99,582",0,0,0,"230195,2","721,067","349,6",1880875008,28782321664,2179067904,30622621696,"1,15","0,617"
Jun-18,22:37:22,"0,27","0,214","99,521",0,0,0,"208076,8","914,4","276,8",1876402176,28786597888,2179264512,30627094528,"1,617","0,517"
Jun-18,22:38:22,"0,27","0,203","99,524","0,003",0,0,"228010,667","1019,2","711,733",1873657856,28789112832,2179493888,30629838848,"1,367","0,933"
Jun-18,22:39:22,"0,25","0,189","99,563",0,0,0,"559513,6","441,6","312,8",1880051712,28782309376,2179903488,30623444992,"0,617","0,533"
Jun-18,22:40:22,"0,26","0,206","99,535",0,0,0,45056,"408,267","265,6",1867083776,28795211776,2179969024,30636412928,"0,617","0,483"
Jun-18,22:41:22,"0,24","0,184","99,574","0,003",0,0,"194969,6","3260,667","2884,267",1879109632,28783005696,2180149248,30624387072,"2,783","2,933"
Jun-18,22:42:22,"0,29","0,203","99,507",0,0,0,"194969,6","771,6","620,533",1865625600,28796289024,2180349952,30637871104,"0,883","0,733"
Jun-18,22:43:22,"0,37","0,228","99,401","0,003",0,0,"825207,467","1824,533","1843,467",1880727552,28780576768,2180960256,30622760960,"1,55","1,55"
Jun-18,22:44:22,"0,24","0,178","99,582",0,0,0,"474316,8","1795,733","1507,067",1873461248,28787433472,2181369856,30630043648,"1,383","1,45"
Jun-18,22:45:22,"0,26","0,203","99,541",0,0,0,"82466,133","413,6","320,8",1862205440,28798574592,2181484544,30641291264,"0,633","0,567"
Jun-18,22:46:22,"0,28","0,198","99,516","0,003",0,0,"563063,467","987,067","754,133",1869135872,28791164928,2181963776,30634360832,"1,15","0,967"
Jun-18,22:47:22,"0,26","0,2","99,538",0,0,0,"237021,867","475,733","370,133",1856270336,28803813376,2182180864,30647226368,"0,8","0,733"
Jun-18,22:48:22,"0,27","0,209","99,524",0,0,0,"210261,333","465,067","296,8",1886625792,28773261312,2182377472,30616870912,"0,75","0,567"
Jun-18,22:49:22,"0,26","0,195","99,541",0,0,0,"197154,133","2435,067","2161,067",1874427904,28785278976,2182557696,30629068800,"1,9","1,883"
Jun-18,22:50:22,"0,24","0,195","99,56","0,003",0,0,"226372,267","437,333","281,867",1875271680,28784222208,2182770688,30628225024,"0,667","0,5"
Jun-18,22:51:22,"0,24","0,217","99,546",0,0,0,"228829,867","475,467","347,2",1871073280,28788224000,2182967296,30632423424,"0,683","0,6"
Jun-18,22:52:22,"0,26","0,178","99,563",0,0,0,"194969,6","433,6","299,467",1866616832,28792500224,2183147520,30636879872,"0,65","0,533"
Jun-18,22:53:22,"0,29","0,214","99,488","0,008",0,0,"613580,8","803,067","728,533",1880481792,28778078208,2183704576,30623014912,"1,017","0,95"
Jun-18,22:54:22,"0,27","0,212","99,518",0,0,0,"442914,133","519,733",356,1870536704,28787630080,2184097792,30632960000,"0,783","0,633"
Jun-18,22:55:22,"0,25","0,192","99,555",0,0,0,"44509,867",408,"299,467",1881411584,28776689664,2184163328,30622085120,"0,65","0,583"
Jun-18,22:56:22,"0,25","0,203","99,546","0,003",0,0,"194969,6","600,8","445,067",1868537856,28789383168,2184343552,30634958848,"0,95","0,817"
Jun-18,22:57:22,"0,25","0,178","99,574",0,0,0,"196061,867","425,067",308,1873129472,28784611328,2184523776,30630367232,"0,683","0,6"
Jun-18,22:58:22,"0,24","0,198","99,524","0,036",0,0,"409053,867","475,067",308,1878339584,28779057152,2184867840,30625157120,"0,733","0,6"
Jun-18,22:59:22,"0,25","0,214","99,535",0,0,0,"44509,867","523,467","414,667",1874636800,28782694400,2184933376,30628859904,"0,867","0,817"
Jun-18,23:00:22,"0,30","0,2","99,493","0,003",0,0,"226372,267","3706,8","3267,467",1874132992,28782964736,2185166848,30629363712,"3,2","3,183"
Jun-18,23:01:22,"0,27","0,214","99,518",0,0,0,"655906,133","849,867","400,533",1870610432,28785971200,2185666560,30632873984,"1,267","0,75"
Jun-18,23:02:22,"0,26","0,209","99,529","0,003",0,0,"561971,2","421,867","321,867",1873661952,28782432256,2186153984,30629826560,"0,7","0,65"
Jun-18,23:03:22,"0,26","0,195","99,549",0,0,0,"279074,133","430,4","330,4",1874513920,28781334528,2186399744,30628974592,"0,717","0,667"
Jun-18,23:04:22,"0,24","0,214","99,549",0,0,0,"194969,6","420,267","309,6",1867886592,28787781632,2186579968,30635601920,"0,633","0,6"
Jun-18,23:05:22,"0,25","0,175","99,568","0,003",0,0,"253678,933","448,933","356,533",1875238912,28780183552,2186825728,30628249600,"0,717","0,667"
Jun-18,23:06:22,"0,27","0,212","99,518",0,0,0,"528657,067","523,467","385,333",1874391040,28780605440,2187251712,30629064704,"0,733","0,65"
Jun-18,23:07:22,"0,28","0,212","99,507",0,0,0,45056,808,"658,933",1877110784,28777803776,2187333632,30626377728,"0,917","0,8"
Jun-18,23:08:22,"0,26","0,178","99,56","0,003",0,0,"557875,2","1764,133",1504,1863479296,28791025664,2187743232,30640009216,"1,183","1,183"
Jun-18,23:09:22,"0,25","0,206","99,543",0,0,0,"49425,067","465,6","345,333",1874362368,28780077056,2187808768,30629126144,"0,667","0,6"
Jun-18,23:10:22,"0,25","0,181","99,568",0,0,0,"196061,867","439,6","326,667",1865617408,28788641792,2187988992,30637871104,"0,667","0,633"
Jun-18,23:11:22,"0,25","0,212","99,541","0,003",0,0,"387754,667","505,067","405,333",1867829248,28786089984,2188328960,30635663360,"0,767","0,733"
Jun-18,23:12:22,"0,27","0,203","99,527",0,0,0,"323857,067","405,067","297,867",1873821696,28779782144,2188644352,30629666816,"0,6","0,533"
Jun-18,23:13:22,"0,25","0,187","99,563",0,0,0,"197154,133","2278,533","1941,2",1869897728,28783521792,2188828672,30633590784,"1,95","2,033"
Jun-18,23:14:22,"0,26","0,2","99,538","0,003",0,0,"199338,667","4206,667","3483,867",1873682432,28779556864,2189008896,30629806080,"2,833","3,217"
Jun-18,23:15:22,"0,29","0,206","99,502",0,0,0,"616174,933","833,333","702,4",1882103808,28770623488,2189504512,30621376512,1,"0,917"
Jun-18,23:16:22,"0,25","0,192","99,56",0,0,0,"226645,333","479,467","346,933",1873805312,28778725376,2189701120,30629675008,"0,667","0,6"
Jun-18,23:17:22,"0,25","0,206","99,538","0,003",0,0,"389939,2",432,340,1867702272,28784484352,2190045184,30635778048,"0,683","0,633"
Jun-18,23:18:22,"0,26","0,209","99,535",0,0,0,"209169,067","405,867","314,4",1863270400,28788719616,2190241792,30640209920,"0,6","0,567"
Jun-18,23:19:22,"0,23","0,181","99,588",0,0,0,"62532,267",460,"331,467",1872572416,28779352064,2190307328,30630907904,"0,683","0,6"

Nějaký nápad v kterém logu zjistit více info, nebo jaké další logování nasadit?

Stále mám možnost změnit port ssh z 22 na nějaký random a nebo zakázat přihlašování heslem úplně. Vyzkoušet to můžu, alespoň by to potvrdilo hypotézu o zahlcení ssh. Každopádně i tak bych rád zjistil, co přesně se tam děje, a měl potvrzené, že to je opravdu problém v tomto a né v něčem jiném. Chtěl bych ten probékm identifikovat, a né jen obejít.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: redustin 20. 06. 2025, 10:55:03
Co konkrétně obnáší to "Než jsem server nakonfiguroval ...  vše běželo asi týden v kuse bez nějakých problémů."?

Byla změna jen umístění do netu, nebo nějaká další konfigurace, jak je zmíněno?
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 20. 06. 2025, 11:16:39
Konkrétně jsem si hrál s nastavením a rozjetím serveru v docker compose. Fail2ban a iptables jsem začal konfigurovat až po tom, co se problém začal objevovat po vystavení do internetu.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: pedro42 20. 06. 2025, 12:00:06
Doporučuji dát do sshd_config
Kód: [Vybrat]
MaxAuthTries 2nebo o něco více. To způsobí, že po 2 neúspěšných pokusech sshd uživatele vykopne (zavře spojení).
K tomu něco jako
Kód: [Vybrat]
iptables -A INPUT -i ${WAN_INTERFACE} -p tcp -m state --state NEW -m hashlimit --hashlimit-mode srcip --hashlimit-srcmask 24 --hashlimit-upto 1/min --hashlimit-burst 3 --hashlimit-name rate_ssh4 --dport 22 -j ACCEPTcož způsobí omezení poču nových spojení z daného /24 subnetu. Jinými slovy párkrát to někdo zkusí a firewall začne zahazovat nová příchozí spojení na port 22, za minutu zase pár nových spojení pustí a zase začne zahazovat.
Nebo dovolit přístup na ssh jen přes VPN a pak je úplný klid.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: ETNyx 20. 06. 2025, 12:00:57
Zajímavý problém,.. Každopádně vypněte přihlašování heslem a používejte pouze klíče.

Když píšete o rozjetí serveru v docker compose tak ty logy jsou z docker kontejneru? Pak by ten IRQ záznam nebyl překvapující, pochybuji, že by docker měl možnost zapisovat někam do /proc/irq/140/smp_affinity aby mohl přerozdělovat HW přerušení mezi jádry fyzického CPU.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Michal Šmucr 20. 06. 2025, 12:17:00
Nepřijde mi moc pravděpodobné, že by to bylo tím ssh nebo že by někdo složil server tímhle způsobem.
Tyhle pokusy o ověření a hádání hesel jsou bohužel úplně standardní pro jakoukoliv veřejnou adresu, kde běží ssh server.
Ale ještě jsem se nesetkal s tím, že by to vedlo k nedostupnosti serveru. Ten interval mezi pokusy bývá poměrně dlouhý, aby to způsobilo nějaký problém.
SSH port nechávám standardní, jen to rovnou přenastavím, aby se nedalo ověřit heslem, ale jen přes pubkey. Případně tam přesně jak jste udělal vy, nastavím fail2ban.

Tady např. namátková statistika z jednoho ne příliš navštěvovaného virtuálu s veřejnou IP. Aktuálně běží 20 dní po posledním rebootu, 27654 pokusů (standard).

Status for the jail: sshd
|- Filter
|  |- Currently failed:   5
|  |- Total failed:   27654
|  `- Journal matches:   _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned:   1
   |- Total banned:   1906
   `- Banned IP list:   45.135.232.177



Takže myslím, že to bude něco jiného a je tam jen časová shoda.
Je zvláštní, že tam nemáte nic zalogované dál. Protože pokud se k tomu nemůžete dostat a bylo to sítí jak myslíte, přijdete fyzicky k serveru, zmáčkete krátce tlačítko napájení (nepodržíte), tak by se měl server začít regulérně vypínat a měly by se zapsat nějaké další hlášky do žurnálu.
Pokud je to úplně tuhé a opravdu to musíte natvrdo vypnout, tak tam s největší pravděpodobností bude něco na fyzické konzoli (monitoru). Buď nějaký backtrace, nebo třeba hromada hlášek z nějakého modulu, blokového zařízení (pokud nejde zapsat a souborový systém se přepnul do R/O režimu).

Jinak to může být spousta věcí, od nějakého hardwarového problému, potíž na filesystému (zkoušel jste po těch pádech kontrolu btrfs a scrub?), přes problémy s nějakou aktualizovanou verzí jádra na konkrétním HW (OpenSUSE Micro na rozdíl od Leap Micro je založené na Tumbleweedu, tzn. je to rolling a je tam vždycky poslední stable jádro. Ale i v tom případě by mělo jít naběhnout z nějakého staršího snapshotu).

Ta chyba/varování s irqbalance se některým lidem (s určitým hw, např. od HP) začala objevovat od jádra 6.12 a dál.. ale zas nemělo by to být smrtící, v určité chvíli to prostě přestane šoupat to konkrétní IRQ mezi jádry, ale nezmrzne celý systém.
https://github.com/Irqbalance/irqbalance/issues/336

Takže já bych zkusil - zkontrolovat fyzickou konzoli, případně pokud bych měl podezření na problémy s tím ukládáním, tak si otevřít SSH konzoli na server s nějakým puštěným tmuxem, screenem, kde bych rozjel journalctl --dmesg --follow. Na SSH klientu bych nastavil keepalive (např. ServerAliveInterval 60, ServerAliveCountMax 10) a logoval výstup někam do souboru na klientu. Tzn. kdyby tam byl problém, tak odchytíte ty dmesg hlášky i když se to nepodaří zapsat na disk.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Ħαℓ₸℮ℵ ␏⫢ ⦚ 21. 06. 2025, 20:29:26
jde opravdu o domácí server s veřejnou IP? Pro zajímavost bych před jeho network interface předhodil něco ,čím je možné tcpdumpovat: router nebo switch s mirrorem a zjistit, zda zahazování se něděje dřív. je to plnohotnotné x86 nebo něco osekaného ve smyslu emmc, atom, podvyživevená virtuálka.   Já semtam mám podobný problém na VPS, kdy se to nějak odmlčelo a taky jedna z hypotéz byl nával ssh skriptidýtů.

není nával i jinde ? třeba na http? pomůže conntrack -L nebo netstat
dál bych se kouknul chvílema na wireshark/tcpdump, jestli tam není nějaké bombardování odpovídané icmp  ...

A zaujalo mě řešení s -m hashlimit.  funguje i per/connection nebo jen paketově? Já používám m recent taky s maskou /24 a zajímalo by mě  srovnání,funcionalita je odlišná ale dají se použít na stejné užití. potřebuje hash limit nějakou  (ručně vytvořenou )pracovní tabuulku jako /proc(/sys)/net/(xt_)recent/název ?
Kód: [Vybrat]
-A ssh_blocks -m recent --set --name SSH --mask 255.255.255.0 --rsource
-A ssh_blocks -m recent --update --seconds 198 (--reap) --hitcount 2 --name SSH-název --mask 255.255.255.0 --rsource -j DROP
btw nepochopil jsem co dělá reap
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 24. 06. 2025, 12:59:13
Zatím to vypadá, že to opravdu s ssh nemělo nic společného. Server byl tuhý úplně, musel jsem podržet tlačítko na vypnutí. Odpojil jsem ho od internetu a problém přetrvával. Nakonec to vypadá, že po vypnutí docker deamona, už k zamrzání nedochází. Nejspíš budu muset použít podman, docker na imutable OS má nejspíš nějaký problém.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 25. 06. 2025, 09:01:09
Tak ne, tím dockerem to taky není, už to zase spadlo.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Ħαℓ₸℮ℵ ␏⫢ ⦚ 25. 06. 2025, 10:37:12
A co problém na úrovni distribuce. Nekde nevím kde , možná i na rootu,nebo blogu se během posledního roku mohlo psát o immutable Linuxu.


Má nějaké neduhy. Immutable distr.? Co třeba mount varú,runú do tmpfs, dojde místo někde?
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Michal Šmucr 25. 06. 2025, 13:42:37
Tak ne, tím dockerem to taky není, už to zase spadlo.

Opravdu nikde nebylo nic vidět? Žádná chybová hláška z jádra nebo kernel panic s backtrace? Co ten kontinuální monitoring, jak jsem psal?

Jinak jestli to opravdu zmrzne bez jakékoliv další informace, čehokoliv zalogovaného, tak to samozřejmě může být závažnější problém s hardwarem. Od zdroje, přes desku až po přehřívání CPU.

Na tu diagnostiku HW se to Micro moc nehodí, systémový repozitář má úplné minimum balíčků. Asi bych stáhl a spustil nějakou živou distribuci (např. SystemRescue).
Pak bych z https://www.mersenne.org/download/ stáhl linuxový balíček s cli verzí prime95 a rozbalil. Když pusíte příkaz mprime, je tam torture test (to je relativně spolehlivá klasika) a třeba hodinka v blend režimu ukáže dost problémů. Podobně je v tom SystemRescue také stress-ng, který má některé podobné testy.
Ideálně tohle pustit v tmuxu s druhým rozděleným terminálem, abyste to viděl najednou, a dívat se na výstup z příkazu 'watch -n1 sensors'. Ten by vám měl průběžně ukazovat teploty (pokud to podporuje desku a CPU).
Případně tomu ještě dát trochu zahulit najednou a např. dělat u toho nějakou diskovou aktivitu (fio a kontinuální přepisování souborů v random režimu na připojeném oddílu), pokud by tam byl fakt zdroj nějak na hraně, tak by to mohlo vyvolat vymrznutí nebo pád.

U vadných RAM modulů to mívá typicky trochu jiný průběh a fakt tam vidíte pády, adresy chyb atp. - není to úplně blackout. Nicméně cvičný memtest (aspoň do 5. kroku) samozřejmě neuškodí a je taky na přímo jako položka v GRUBu u těch živých distribucí.

A co problém na úrovni distribuce. Nekde nevím kde , možná i na rootu,nebo blogu se během posledního roku mohlo psát o immutable Linuxu.

Má nějaké neduhy. Immutable distr.? Co třeba mount varú,runú do tmpfs, dojde místo někde?

To se mi nezdá, fakticky to není nic jiného než kombinace r/o a r/w subvolumů se snapshoty na Btrfs spojených přes overlay. To volné místo je sdílené napříč celým fs a samozřejmě detailně vidět např. přes btrfs device usage. Navíc tyhle chyby jsou opravdu "vidět", bývá tam spousta chybových hlášek.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 26. 06. 2025, 10:01:48
Díky, ten monitoring vyzkouším
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Petr Hložek 26. 06. 2025, 15:46:44
Dobrý den,

nemáte náhodou na server připojena nějaká zařízení pomocí cifs? Třeba pro zálohování někam mimo? V cifs-utils je někde memory leak, postupně sežere celou paměť a server končí přesně jak píšete. Mám/měl jsem stejný problém, dneska jsem nainstalovat update a doufám, že to pomůže. Na serveru mám 64GB RAM, takže vždy chvilku trvalo, než se server zasekl. Sice používám Ubuntu Server 24.04, ale kdo ví, jestli podobný problém není i v Suse.

Petr
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Peterekcze 26. 06. 2025, 18:22:39
Dobry den,
něco podobného jsem řešil s gigabyte brix. Jaky tam mate síťované karty intel e1000?
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 26. 06. 2025, 20:56:51
Nemám

Dobrý den,

nemáte náhodou na server připojena nějaká zařízení pomocí cifs? Třeba pro zálohování někam mimo? V cifs-utils je někde memory leak, postupně sežere celou paměť a server končí přesně jak píšete. Mám/měl jsem stejný problém, dneska jsem nainstalovat update a doufám, že to pomůže. Na serveru mám 64GB RAM, takže vždy chvilku trvalo, než se server zasekl. Sice používám Ubuntu Server 24.04, ale kdo ví, jestli podobný problém není i v Suse.

Petr
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 26. 06. 2025, 21:04:30

Dobry den,
něco podobného jsem řešil s gigabyte brix. Jaky tam mate síťované karty intel e1000?

Ano, vypadá to tak

Kód: [Vybrat]
lspci -nn | grep -i ethernet
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (7) I219-LM [8086:15bb] (rev 10)

lshw -c network
WARNING: you should run this program as super-user.
  *-network
       description: Ethernet interface
       product: Ethernet Connection (7) I219-LM
       vendor: Intel Corporation
       physical id: 1f.6
       bus info: pci@0000:00:1f.6
       logical name: eno1
       version: 10
       serial: c4:65:16:a2:19:d4
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=6.15.1-1-default duplex=full firmware=0.5-4 ip=192.168.0.106 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:145 memory:e1200000-e121ffff
WARNING: output may be incomplete or inaccurate, you should run this program as super-user.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: jjrsk 27. 06. 2025, 02:49:21
Pokud si pamatuju, tak inteli sitovky se nemely s tuxem rady, pokud na nich byl zapnuty rx/tx offload. Ale netusim estli se to tyce tvyho modelu.

zjisteni stavu
ethtool -k ethX

vypnuti
ethtool -K ethX rx off tx off

Edit:

Pripadne sem ted jeste nasel v poznamnicku ze problemovy muze byt totok
ethtool -K ethX tso off

Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 27. 06. 2025, 09:31:36
Ano, měl jsem to zapnuté, zkusil jsem vypnout a uvidím, jestli to pomůže. Zatím díky

Pokud si pamatuju, tak inteli sitovky se nemely s tuxem rady, pokud na nich byl zapnuty rx/tx offload. Ale netusim estli se to tyce tvyho modelu.

zjisteni stavu
ethtool -k ethX

vypnuti
ethtool -K ethX rx off tx off

Edit:

Pripadne sem ted jeste nasel v poznamnicku ze problemovy muze byt totok
ethtool -K ethX tso off
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Michal Šmucr 27. 06. 2025, 10:02:54
Nezdá se mi, že by s tím měl mít cokoliv společného RX, TX offload. Ale nevím, co myslel Peterekcze zmínkou o e1000 nebo e1000e (PCIe) ovladači.
1GbE síťovky od Intelu jedou s těmi zapnutými offloady naprosto běžně ve výchozí konfiguraci a jsou přítomné skoro na všech základních deskách s Intel CPU. V určitých specifických situacích offloady dává smysl vypnout (DPI firewally, zachytávání raw paketů..), nebo pokud to opravdu prokazatelně způsobí problémy (např. bude špatně fungovat škálování TCP okna). Nicméně to rozhodně není tak, že Intel síťovka => vypnu rovnou veškerý offload, to je blbost.
Další věc je, a zas se vrátím k tomu, co už jsem psal. Pokud by tohle nastalo, nejspíš by nevytuhl celý systém tak, že bude třeba vzít natvrdo tlačítkem a nikde nebude ani hláška. I pokud by systém např. po půl dni ztratil jen síťovou konektivitu, tak se krátkým stisknutím spustí normálně shutdown a systém se regulérně vypne, zapíše logy.
Což je i důvod, proč jsem navrhoval, ať se nejdřív zkusí vytížit a otestovat HW, a případně nasimulovat to vymrznutí, aby se tohle vyloučilo a neztrácel čas nějakými softwarovými tweaky naslepo (docker on/off, offload on/off..), zvlášť jestli to předtím fungovalo (předpokládám).

Ale třeba ještě Peterekcze vysvětlí, co měl konkrétně s tím Brixem a e1000.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Peterekcze 27. 06. 2025, 10:07:58
Nezdá se mi, že by s tím měl mít cokoliv společného RX, TX offload. Ale nevím, co myslel Peterekcze zmínkou o e1000 nebo e1000e (PCIe) ovladači.
1GbE síťovky od Intelu jedou s těmi zapnutými offloady naprosto běžně ve výchozí konfiguraci a jsou přítomné skoro na všech základních deskách s Intel CPU. V určitých specifických situacích offloady dává smysl vypnout (DPI firewally, zachytávání raw paketů..), nebo pokud to opravdu prokazatelně způsobí problémy (např. bude špatně fungovat škálování TCP okna). Nicméně to rozhodně není tak, že Intel síťovka => vypnu rovnou veškerý offload, to je blbost.
Další věc je, a zas se vrátím k tomu, co už jsem psal. Pokud by tohle nastalo, nejspíš by nevytuhl celý systém tak, že bude třeba vzít natvrdo tlačítkem a nikde nebude ani hláška. I pokud by systém např. po půl dni ztratil jen síťovou konektivitu, tak se krátkým stisknutím spustí normálně shutdown a systém se regulérně vypne, zapíše logy.
Což je i důvod, proč jsem navrhoval, ať se nejdřív zkusí vytížit a otestovat HW, a případně nasimulovat to vymrznutí, aby se tohle vyloučilo a neztrácel čas nějakými softwarovými tweaky naslepo (docker on/off, offload on/off..), zvlášť jestli to předtím fungovalo (předpokládám).

Ale třeba ještě Peterekcze vysvětlí, co měl konkrétně s tím Brixem a e1000.


Myslel jsem přesně toto co již zde bylo poslané: ethtool -K ethX rx off tx off

Toto me vyřešilo můj problém.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: redustin 27. 06. 2025, 10:14:07
@Peterekcze: Ta síťovka opravdu způsobila zaseknutí celého serveru, nebo jen nebyl přístupný po síti? Samozřejmě jsem se setkal se síťovkami, které se po čase začaly zasekávat a bylo nutné je vyměnit či místo nich (onboard) použít PCI(e) náhrady, ale nepamatuju si, že by zasekly celý systém (tedy stejně jak píše Michal).

Zato umírající zdroje na desce zasekávaly systém spolehlivě.

Otázkou je, zda by nebylo jednodušší řešení použít jiný komp. Vzhledem ke specifikaci CPU i5 asi nepůjde o žádné nenahraditelné serverové železo, přehodit disky a jede se dál.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Michal Šmucr 27. 06. 2025, 10:55:18
Myslel jsem přesně toto co již zde bylo poslané: ethtool -K ethX rx off tx off

Toto me vyřešilo můj problém.

Díky za upřesnění, pokud to vyřešilo problém, tak bezva a byla by to pro tazatele relativně jednoduchá úprava (třeba přes NetworkManager pro persistentní nastavení v SUSE Micro např. - nmcli con modify <spojeni> ethtool.feature-rx off ethtool.feature-tx off a následně nmcli con up <spojeni>).

Mám ještě pro zajímavost stejnou otázku jako teď redustin.
Jevilo se to u vás s Brixem podobně, tzn. zmrznul vám celý počítač bez jediné hlášky a musel jste ho vypnout natvrdo? Nebo "jen" ztratil konektivitu po nějaké době?
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 27. 06. 2025, 12:40:08
Tak i po vypnutí rx, tx a tso problém přetrvává. Byl jsem tam připojen přes ssh a měl výpis journalctl --follow, ale tam nic vidět nebylo. Zaměřím se ještě na tu diagnostiku hw přes live distro.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Michal Šmucr 27. 06. 2025, 13:42:09
Tak i po vypnutí rx, tx a tso problém přetrvává. Byl jsem tam připojen přes ssh a měl výpis journalctl --follow, ale tam nic vidět nebylo. Zaměřím se ještě na tu diagnostiku hw přes live distro.

Ještě jak jsem předtím zmínil ten stress-ng (měl by být na tom System Rescue live cd), mimo ten prime95.
Jeho výhoda je, že se ty jeho testy (stressory) nechají spustit najednou, když chcete vytížit celý systém.

Např. tohle (jen jsem to teď rychle splácal dohromady)
Kód: [Vybrat]
stress-ng -v --verify --metrics-brief --tz --hdd 4 --hdd-bytes 1G --hdd-opts wr-rnd,direct --temp-path /mnt/datavm/temp/ --matrix 0 --vm 2 --vm-bytes 50% --vm-populate --timeout 5m
První parametr nastaví verifikaci (pokud ji stressor podporuje), --tz ukáže statistiku teploty CPU, pak se tím --hdd zapne paralelní náhodný zápis (4 procesy, každý 1G), pak vytížení CPU s použitím matic (FPU, velký odběr) a automatickým počtem procesů podle počtu jader, pak vytížení pamětí přes --vm a nakonec celková doba trvání testu přes --timeout (jinak se zastavuje ručně přes ctrl+c).
Akorát až bych byl v živé distribuci, tak bych si někam ručně připojil ten Btrfs oddíl a upravil cestu v --temp-path, aby to zapisovalo na ta SSD.
Ale jinak je tam těch testů mraky, včetně třeba velké zátěže s obsluhou přerušení, tohle je jen rychlý výkop.

Uvidíte, jak se to bude případně chovat.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: jjrsk 27. 06. 2025, 17:13:10
@Peterekcze: Ta síťovka opravdu způsobila zaseknutí celého serveru, nebo jen nebyl přístupný po síti? ...
Ja mam ve svym poznamnicku napsano, ze s temi offloady po nejaky dobe proste vytuhne kernel. Ale je to poznamka uz pomerne hodne letita, takze to nemusi platit pro aktualni stav.

S realtekama to problem neni protoze ty to neumej ;D. (stema sou zase jiny potize)

měl výpis journalctl --follow
Obavam se, ze tohle je ti uplne nanic. I ve zdejsim propadlisti bys nasel ze pokud neco chcipne, tak tenhle pseudologer jde dolu jako prvni, takze zadny logy neuvidis. Musis jit niz abys mel sanci. dmesg je to co hledas. Samo ani to ti nemusi dat odpoved. A v idealnim pripade ten vypis nepoustecj pres ssh ale lokalne.



Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: LolPhirae 27. 06. 2025, 19:46:21
Our jee, a teď sem naběhne Lennartův fanklub.  ;D ;)
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Michal Šmucr 27. 06. 2025, 23:26:41
Obavam se, ze tohle je ti uplne nanic. I ve zdejsim propadlisti bys nasel ze pokud neco chcipne, tak tenhle pseudologer jde dolu jako prvni, takze zadny logy neuvidis. Musis jit niz abys mel sanci. dmesg je to co hledas. Samo ani to ti nemusi dat odpoved. A v idealnim pripade ten vypis nepoustecj pres ssh ale lokalne.

Ten tip byl ode mě původně v trochu jiném kontextu. Pokud má úplně headless systém a třeba to vytuhne tak, že už to vůbec nic nezapíše do persistentního logu na disku (vypadá to, že ne) a musí to natvrdo vypnout, tak přes ssh je alespoň nějaká šance zkusit přes druhý počítač odchytit, co se tam předtím stalo, jestliže ještě pojede síť (zatím opravdu nevíme, jestli je opravdu problém ta síťovka, jediné co tazatel popsal, je že počítač přestane reagovat).
A na tohle je ve výsledku už trochu jedno, jestli ve vzdáleném terminálu pustíš journalctl --dmesg --follow, jak jsem psal, nebo dmesg -w (byť dmesg je asi přímočařejší volba, co to netahá přes další buffer a sahá si rovnou na /dev/kmsg).
Samozřejmě je i pár dalších možností třeba forwardování na syslog server (což samozřejmě vyžaduje zas funkční síť), nebo na nižší úrovni přesměrovat konzoli na sériák a připojit se tam z jiného počítače terminálovým emulátorem.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: redustin 28. 06. 2025, 07:40:26
Přes ssh jo, ale to by už asi musela být konexe otevřená před zátuhem, aby ssh nepotřebovalo sahat na disk. Obvykle bývají při loginu zapnuté nějaké statistiky/úvodní info a bez přístupu k disku přihlášená ssh sešna nenaběhne.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 30. 06. 2025, 18:27:48
Zkoušel jsem dnes v rychlosti na live SystemRescue příkaz stress-ng -a 0 a za 10minut tam bylo 0 failed. Ještě zkusím s připojenými disky.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Lu Kash 03. 07. 2025, 08:46:22
Tak to jsem zvedavy, co to bude:) Memtest byl? Nechal bych bezet dmesg -w na pripojenem monitoru, pokud je v logu neco vic pred zamrznutim, bude to tam. Pres sit uz to treba neproleze.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 03. 07. 2025, 14:40:23
Memtest proběhl v pořádku, všelijaké stress testy nic neukázaly. Nevím jestli to mohl být hw problém, PC byl už starší kousek, ale zrovna ramky a disky byly úplně nové. Možná vás zklamu a možná je to škoda, ale už jsem ztratil trpělivost a přeinstaloval to na ubuntu server. Pokud to problém vyřeší, tak tato záhada asi zůstane neobjasněna. Každopádně díky za všechny tipy.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 08. 07. 2025, 13:53:01
Nechci to zakřiknout, ale na Ubuntu zatím bez problémů.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 21. 07. 2025, 13:28:02
Tak problém ikdyž o něco veselejší přetrvává, nyní pc nezamrzne ale restartuje se a opět nabootuje, logy opět neříkají nic moc.

Problém by mohl být nejspíš v nedostatečném výkonu zdroje. Jedná se o mini pc (HP EliteDesk 800 G4 DM), kde je 2x16GB ram a 2x2tb ssd disk.

Tuším, že mám 65W adaptér. Zkusím to zapojit přes chytrou zásuvku s měřením spotřeby, jestli to něco řekne.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 21. 07. 2025, 19:41:03
Tak adaptér je 90W
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Michal Šmucr 22. 07. 2025, 12:12:48
To je mrzuté, že se problém vrací.
Ty komponenty, co jste psal, nezní nějak extrémně náročně, aby to nedal 90W zdroj.
Největší spotřebu bude mít CPU (byť nevím, co tam přesně je). Ale tam bych předpokládal, že k těm miniPC dává HP podle modelu CPU odpovídající zdroj (65, 90 nebo 150W). Taky by v případě problému mělo být náchylnější, když to vytížíte a vzroste jeho TDP, což je přesně důvod, jak jsem vám předtím psal o tom Prime nebo stress-ng. A podle toho, co jste psal, tak to nevytuhlo.
Nicméně samozřejmě nelze vyloučit, že odchází nějaká součástka nebo je třeba i nějaká tepelná závislost.
Stran té spotřeby CPU, asi by se dalo dočasně vyzkoušet nastavit tomu nějaký nižší TDP limit (Intel na to má RAPL rozhraní, co se dá v Linuxu ovládat přes sysfs a můžete třeba sundat celkový odběr package z 35 na 25W, dá se to typicky dohledat někde v datasheetu u Intelu od konkrétního CPU).
To by dočasně snížilo špičkový odběr a možná prodloužilo intervaly výskytu (jestli to s tím souvisí), ale zas mi to přijde, že se tím jenom obejde řešení problému, co bude někde jinde (např. deska, zdroj).

Takže za dané situace bych asi zkusil sehnat zdroj na výměnu. Bývá tam standardní 19,5V, jde jen o to, aby měl správný konektor a dával dostatečný proud. Bude jich určitě tuna i od OEM výrobců. Když jsem to řešil k notebookům, většinou jsem to sehnal okolo 6-800 Kč. To mi přijde jako nejlevnější a nejsnazší výměna pro vyzkoušení.
Pokud to nezabere, tak asi realisticky s tímhle miniPC smůla a nezbyde než vyndat SSD, RAM a poohlédnout se po náhradě.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 25. 08. 2025, 09:46:24
Tak záhada stále nevyřešena.

Podle logů, kde před restartem nebyly zapsané žádné chyby to vypadalo na problém s napájením. Zkoušel jsem tedy další 2 různé 90W adaptéry a nakonec jsem koupil i 135W adaptér. Problém to nevyřešilo.

Takže to vypadalo na nějaký jiný HW problém. Podařilo se mi sehnad druhý HP EliteDesk 800 G4 a jediné co jsem použil z původního byly disky, 2x2TB SSD disky (v RAID 1)

K restartům ale dochází stále.

Tak nevím zda nějaký problém přímo s těmi disky, s raidem, nebo nějaké linuxové ovladače.

Konkrétně se jedná o 2 identické disky DAHUA C970 PLUS 2TB (oba nové)

Ještě vyzkouším pouze jeden disk, přeformátovat a přeinstalovat OS a vyzkoušet bez RAIDu.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 25. 08. 2025, 10:32:51
Tak ještě vyzkouším tohle, vypadá to jako stejný problém:
https://forum.proxmox.com/threads/proxmox-random-reboots-on-hp-elitedesk-800g4-fixed-with-proxmox-install-on-top-of-debian-12-now-issues-with-hardware-transcoding-in-plex.132187/

Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 25. 08. 2025, 10:49:48
Dává mi to smysl, že by mohl být problém vážně s iGPU a přechodem do nižšího idle stavu. Když jsem totiž zařízení instaloval a pak konfiguroval, cca týden jsem měl připojený monitor a k restartu nedošlo ani jednou. Jakmile bylo vše nakonfigurované, tak jsem monitor odpojil a server učinil veřejně viditelný z internetu, pak začaly brute force útoky, proto jsem si to dal do souvislosti s tím. Ale souvislost byla s tím odpojeným monitorem, který grafice nedovoloval přejít do nejnižšího idle stavu. Dnes vyzkouším, snad to problém konečně vyřeší.
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: Michal Šmucr 25. 08. 2025, 11:57:15
To je docela cesta, co jste vyzkoušel  :P uff.

Ale ty věci z vlákna na Proxmox fóru vypadají nadějně, zvlášť jestli ty rebooty taky dokážete izolovat na dobu, kdy není připojený monitor.
Vypadá to jako pěkná divočina.. minimálně na některých konfiguracích zmrzne ten i915 ovladač, pak začne postupně růst teplota a následně to natvrdo restartuje nějaká tepelná ochrana.
Taky zajímavá zmínka od někoho, komu pomohl jenom downgrade BIOSu.

Jinak pokud to pozitivně nemrzne s připojeným monitorem, tak by, pokud selžou ostatní zmíněné a jednodušší věci, mohlo teoreticky zabrat uložení EDIDu z toho konkrétního monitoru a pak natvrdo přiřazení ke konkrétnímu DP výstupu přes parametr jádra drm.edid_firmware=, což by mělo zajistit, že to pojede jako by byl pořád připojený.

A mimochodem ty powersave stavy jsou obecně docela častá příčina problémů, typicky třeba NVMe disků, které mají své vnitřní mechnismy pro low power stavy (APST). A ještě je tam pak podobná, ale separátní věc na PCIe (ASPM).
Občas je nutné s některými zařízeními to povypínat, nebo minimálně najít nějakou bezproblémovou úroveň šetření, funkční dobu přechodu a selektivně nastavit (občas se pak ještě musí řešit jestli to nastavuje jádro, nebo BIOS).

Každopádně díky, že jste tu to vlákno zmínil.. a držím palce s vyřešením ;)
Název: Re:Nedostupný server, zamrznutí, brute force ssh
Přispěvatel: krakenpico 27. 08. 2025, 11:25:45
Díky všem za rady, a snahu pomoct problém vyřešit. Zatím to běží bez restartu.

Řešení:

Přidal jsem do /etc/default/grub:
Kód: [Vybrat]
GRUB_CMDLINE_LINUX_DEFAULT="i915.enable_dc=0 intel_idle.max_cstate=7"
Potom
Kód: [Vybrat]
sudo update-grub