Příspěvky

1

Vývoj / Re:SSH server vytuhne

« kdy: 07. 09. 2023, 17:47:28 »

A proc se v momente, kdy to je vytuhle, nepodivas pomoci GDB, na cem to visi v tom libssh?

Asi proto, že mě to buď nenapadne nebo to neumim :-)

Dneska jsem ale trošku pokročil a zaměřil se na ten valgrind. Možná se mi povedlo najít kde mám chybu, ale ještě si tím nejsem úplně jistej. Musí to běžět docela dlouho, aby to vyplivlo nějaká smysluplná data ve kterých jsem schopen něco najít.

Zdá se, že skutečně špatně pracuji s pamětí což ti chytřejší asi tušili hned. Pokud se z nějakého důvodu rozhodnu navázanou session ukončit tak volám funkci

Kód: [Vybrat]

ssh_disconnect(session); Toto sice session uzavře, ale neuvolňuje to paměť kterou přiřadila funkce

Kód: [Vybrat]

session = ssh_new();. Pravděpodobně je po tomto nutné zavolat ještě funkci

Kód: [Vybrat]

ssh_free(session); Toto mi v celém kódu unikalo a důsledky jsou asi zřejmé. Je zvláštní, že mi ten program sám od sebe vůbec nepadá a jen zatuhne.

Pokud se mi povede ještě ukončit ten accept, bude to ještě lepší, protože pak budu schopen celý příjem SSH korektně ukončit včetně vlákna ve kterém to běží. V tuhle chvíli, když to zastavím natvrdo tak valgrind stále hlásí možný únik což je pořád nějaké varování. Předpokládám, že správný výsledek je když jsou detekované nulové možné i skutečné úniky.

2

Vývoj / Re:SSH server vytuhne

« kdy: 04. 09. 2023, 17:37:30 »

Nemůže dojít k blokování v tom pracovním vlákně?

Domnívám se, že nikoliv. Vede mě k tomu fakt, že v tom pracovním vlákně běží obsluha dalších filedeskriptorů, které mi normálně komunikují. Současně každou sekundu si na konzoli vypisuji krátký text, že toto pracovní vlákno žije. V podstatě proto jsem se tímto celým začal zabývat, protože v pracovním vlákně se dělo všechno podle očekávání a jen jakoby vlákno na příjem SSH stálo.

Zkusil jsem to pustit přes ten valgrind. Po nějaké době jsem to chcípnul a vypadlo toto:

Kód: [Vybrat]

==48106==
==48106== HEAP SUMMARY:
==48106== in use at exit: 6,740 bytes in 42 blocks
==48106== total heap usage: 383,119 allocs, 383,077 frees, 104,143,130 bytes allocated
==48106==
==48106== 3,406 (32 direct, 3,374 indirect) bytes in 1 blocks are definitely lost in loss record 42 of 42
==48106== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==48106== by 0x49FE9AB: ssh_new (in /usr/lib/x86_64-linux-gnu/libssh.so.4.8.7)
==48106== by 0x10CAC4: handle_init_accept_sshbind (server_ssh.c:432)
==48106== by 0x4DAEB42: start_thread (pthread_create.c:442)
==48106== by 0x4E3FBB3: clone (clone.S:100)
==48106==
==48106== LEAK SUMMARY:
==48106== definitely lost: 32 bytes in 1 blocks
==48106== indirectly lost: 3,374 bytes in 26 blocks
==48106== possibly lost: 0 bytes in 0 blocks
==48106== still reachable: 3,334 bytes in 15 blocks
==48106== suppressed: 0 bytes in 0 blocks
==48106== Reachable blocks (those to which a pointer was found) are not shown.
==48106== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==48106==
==48106== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Prijde mi dovny tento radek:

Kód: [Vybrat]

==48106== by 0x49FE9AB: ssh_new (in /usr/lib/x86_64-linux-gnu/libssh.so.4.8.7)
Dela to na me dojem, ze zavolanim funkce ssh_new(), kterou volám každým příjmem se asi vytváří někde nové vlákno. Nevím jestli to něčemu vadí nebo ne, ale dneska už na to nemám sílu tak se tomu budu zas někdy věnovat.
Dík za všechny reakce a hezký zbytek dne :-)

3

Vývoj / Re:SSH server vytuhne

« kdy: 04. 09. 2023, 15:51:25 »

Jste si jistý tím, že „zatuhne“ ssh_bind_accept()

Jsem si tím jistej, ale nerad bych něco přehlížel takže to ještě jednou ověřím. Nejsem v tomto vůbec kovanej takže všechno je čistě amatérské a někdy ani nevím jak bych měl správně postupovat. Zdrojových příkladů na SSH server jsem nikde moc nenašel, takže takže je to hodně velkej pokus omyl....doufám, že se za to na mě nikdo nebude zlobit a že právě pro takovéto účely vznikají tato fóra. K ladění používám funkci printf a snažím se prokousat těmi hroznými výpisy, ale v případě více vláken možná tato metoda selhává :-)

Ten současný kód máte udělaný tak, že se serverem může komunikovat vždy jen jeden klient.

Toto není pravda i když to tak na první pohled vypadá. Pokud Vás to zajímá tak trošku víc popíšu jak to je udělané a proč.
funkce

ssh_bind_accept(sshbind, session)

je pro mě blokující. Jakmile jí tedy zavolám tak neskončí dokud se žádnej klient nepokusí navázat spojení. To je pokud chcete komunikovat s více zařízeními dost omezující nemyslíte? Nevím jak to dělá někdo kdo to umí ale já to řeším tak, že celý příjem SSH spojení běží ve vlastním vlákně. Jakmile je spojení přijato, předávám přes mutex deskriptor navázaného spojení hlavnímu vláknu. Jakmile je deskriptor předaný tak se vracím opět k

ssh_bind_accept(sshbind, session)

a čekám na další spojení. Vlákno tedy jen čeká v blokující funkci a jakmile vrátí příjem, předá ukazatel a opakuje se. Veškeré odbavení spojení jako příjem, odeslání a ukončení je už řešeno jako neblokující v jiném vlákně. Tenhle princip mi funguje a zkoušel jsem i takové experimenty, že jsem si na úplně jiném počítači vytvořil tisíce SSH klientů, které se trvale jen připojovali a odpojovali. Veškeré mé pokusy a omyly vždy vedly ke stejnému závěru. Tím je právě ta blokující funkce, takže se furt točím dokola.

zkontrolovat to valgrindem je první věc

Toto jsem opakovaně zkoušel, ale nikdy jsem na nic nepřišel. Asi se k tomu s odstupem času opět vrátím.

4

Vývoj / Re:SSH server vytuhne

« kdy: 04. 09. 2023, 11:10:20 »

Ano celá obsluha SSH je v jednom vlákně. Ono to tak musí být, protože funkce příjmu spojení je blokující.
v libssh sice existuje funkce

Kód: [Vybrat]

sss_bind_set_blocking(sshbind,0), ale ta podle mě nefunguje nebo jsem na to nepřišel.
zde je kód:

Kód: [Vybrat]

static void *handle_init_accept_sshbind(void *arg){
  ssh_session session;
  uint8_t pom;
  ssh_bind sshbind = (ssh_bind)arg;
  while(1){
    session = ssh_new();
    if(session != NULL){
     ssh_set_message_callback(session, nc_sshcb_msg, session);
     if(ssh_bind_accept(sshbind, session) != SSH_OK){
       ssh_disconnect(session);
       }
     else{
       if(ssh_handle_key_exchange(session) != SSH_OK){
         ssh_disconnect(session);
         }
       else{
         //spojeni prijato
         }       
       }
     }
   }
   ssh_bind_free(sshbind);
   ssh_finalize();
   return NULL;
   }

A vytuhne to zde:

Kód: [Vybrat]

if(ssh_bind_accept(sshbind, session) != SSH_OK){

5

Vývoj / Re:SSH server vytuhne

« kdy: 04. 09. 2023, 10:40:53 »

tak tohle určitě vyloučit nemůžu, ale pokud zavolám v linuxu nějakou funkci zde např.

Kód: [Vybrat]

ssh_bind_accept(sshbind, session), tak bych očekával, že ta funkce někdy skončí. V tomto případě ta funkce skončí jen v případě, že příjde SSH spojení jinak neznám jediný způsob jak jí ukončit. V momentě kdy to vytuhne, tak už žádné spojení nepřijme a nikdy tedy neskončí. Přiznám se, že nechápu kde by v tomto případě mohl být problém s pamětí, protože jakmile tu funkci zavolám, tak se celá další obsluha programu předává OS dokud ten funkci neukončí a neumožní pokračovat v programu.

Jinak se omlouvám, ale špatně jsem napsal, že používá openSSH. Používá libssh. Chybně jsem se domníval, že to znamená to stejné. Je možné, že implementace libssh je nějaká zastaralá, nebo neúplná. Možná je chyba právě v tom.

6

Vývoj / SSH server vytuhne

« kdy: 04. 09. 2023, 09:13:50 »

Ahoj,
dlouhodobě provozuju program SSH serveru v linuxu postavený na openSSH, psaný v C.
Od začátku co jsem si s tím začal hrát jsem pozoroval, že funkce:

Kód: [Vybrat]

ssh_bind_accept(sshbind, session)má pouze blokující volání. To se mi nikdy nepovedlo vyřešit, ale s tímto umím žít.

Co mi ale vadí je to, že po nějaké době cca jeden den SSH server vytuhne a už nepříjme žádné spojení.
Blokovaná funkce už nikdy neskončí a zůstává to v ní viset dokud nevypnu/zapnu program serveru.

Ze začátku jsem si myslel, že to je proto že mám málo spojení na server. Pak jsem si ale vedle postavil
program SSH klienta, kterej se každou minutu připojí a opět odpojí. Tím jsem si toto vyloučil a stále to vytuhne.

Nyní bych to chtěl vyřešit lépe a chtěl bych to udělat tak, že nebude docházet k vypnutí/zapnutí programu serveru, ale
že se SSH pokusím reinicializovat za běhu. Doufám, že to povede k pro mě přijatelnějšímu chování.

Chtěl bych se ale zeptat jestli někdo netuší proč to SSH vytuhne? Případně jestli něco nemůžu udělat jinak.

Na tom programu serveru beží ještě další např. TCP server, TLS server a žádný z nich to nedělá, takže toto je pro mě velká záhada.
Dík.
 

7

Vývoj / Re:Nefunkční proměnná v BASH scriptu

« kdy: 02. 03. 2023, 07:49:23 »

pokud mi neco neunika, tak ten find odstavec resit normalne=obracene :-)

Kód: [Vybrat]

while read file; do
dir=${file%/*}
echo "${dir}"
/home/irma/database_sort_new "${dir}"
OPAKOVAT=1
done < <(find /opt/databaze_pracovni -name "database.db")


Asi ti nic neuniklo....toto funguje. Dík za pomoc, protože tohle mi ušetří spoustu nervů :-)

8

Vývoj / Re:nefunkční proměná v BASH scriptu

« kdy: 01. 03. 2023, 15:00:47 »

Super...dík za radu. To ale rozhodně nebyl můj záměr. Když jsem ten script tvořil tak jsem prostě googlil a zkoušel různý věci aby to dělalo to co potřebuji a je to několik let zpátky. Nyní potřebuji s tím zas něco jiného a nestačím se divit :-)

Tak se zeptám ještě na jednu věc....jak z toho ven, resp. lze to nějak jednoduše upravit nebo je potřeba znovu zapátrat?
Dík.

9

Vývoj / Nefunkční proměnná v BASH scriptu

« kdy: 01. 03. 2023, 14:11:24 »

Ahoj, laboruju se skriptem v bashi ve kterém se snažím třídit databázový soubor. Třídění mi funguje, ale překvapilo mě chování proměné "OPAKOVAT"

Kód: [Vybrat]

#!/bin/bash
exit_status=0

while true; do
  OPAKOVAT=0
 
  find /opt/databaze_pracovni  -name "database.db" -exec sh -c '
     for file do
       dir=${file%/*}
       echo "$dir"
       /home/irma/database_sort_new "$dir"       
     OPAKOVAT=1 
     done' sh {} +
 
  echo $OPAKOVAT
  if [ $OPAKOVAT -eq 1 ]; then
      echo "nebude se uspavat"
      continue
  fi
 
  echo "sleep"
  sleep 300s
done
Zjistil jsem, že proměná "OPAKOVAT" se mi na konci skriptu nikdy nevyhodnotí jako "1" a to i přes to, že vždy najdu několik databázových souborů takže cyklus vždy proběhne. Můžete mi prosím někdo poradit co dělám špatně? Dík

10

Server / Re:Nefungující HTTP

« kdy: 22. 11. 2022, 10:10:28 »

Ten můj nezabezpečenej webserver podle logu příjme nové spojení a odpoví na něj. Do prohlížeče už se ale nic nedostane. Pokud udělám to stejné přes VPNku tak to funguje jak z praku vždy.

To, že ten werbserver vlastně odpoví může být spekulace, protože nehlásí žádnou chybu a neznám důvod proč by neměl odpovědět.

11

Server / Re:Nefungující HTTP

« kdy: 22. 11. 2022, 10:08:53 »

Internet od O2 mám...již jsem psal výše.

Určitě to není problém posledních tří dní. Děje se to delší dobu. Většinou to jde, ale pak prostě příjde jedno dopoledne a přestane to jít.

12

Server / Re:Nefungující HTTP

« kdy: 22. 11. 2022, 10:07:07 »

Ten můj nezabezpečenej webserver podle logu příjme nové spojení a odpoví na něj. Do prohlížeče už se ale nic nedostane. Pokud udělám to stejné přes VPNku tak to funguje jak z praku vždy.

13

Server / Re:Nefungující HTTP

« kdy: 22. 11. 2022, 09:37:03 »

OK, tak DNS to není.
Toto pozoruji jen u nás v kanceláři, kde je internet od o2 a není tu aktivní žádný firewal nebo o něm nevím.

Pokud tento problém nastane, tak to nejde ani na jednom z našich počítačů a nezáleží na OS ani na webovém prohlížeči.

Současně se pouze domnívám, že je to věcí http nebo https, protože např. www.seznam.cz mi jde, ale např. www.mcu.cz už nejde.

Ještě jsem pozoroval jednu věc...provozuju VPS na veřejném serveru, kde je nezabezpečený webový server. Pokud na něj přistoupím přímo přes veřejnou IP adresu nebo DNS adresu tak mi to nefunguje. Jakmile použiju VPNku tak to začne fungovat.

Líp už to popsat nedokážu.

14

Server / Nefungující HTTP

« kdy: 22. 11. 2022, 08:59:30 »

Ahoj, už delší dobu pozoruju, že mi občas nefungujou weby, které nemají zabezpečené spojení resp ty, které nejsou https. Např. včera to pravděpodobně nešlo během dne a dneska už to zase jde. Může jít o chybu u mě, nebo je to nějakej globální šotek? Někde jsem slyšel názor, že DNS googlu údajně může blokovat nezabezpečené spojení, ale to se mi nějak nepovedlo potvrdit, protože mi tu kolega zkusil jinej DNS server a nešlo to také. Dík za případnou reakci.

15

Server / Re:SSH na OpenWrt přístupy botů

« kdy: 14. 10. 2022, 20:21:20 »

Ahoj, docela by mě zajímalo jestli se někomu stalo, že čelil skutečně reálnému útoku. Provozuju už několik let veřejně dva SSH servery (k čistě experimentálním účelům) na jiném portu než 22 a loguju si každý pokus o přihlášení včetně přihlašovacích údajů (k přihlášení se používá jen uživatelské jméno a heslo). Za celou dobu provozu tyto servery čelily statisícům neplatným pokusům o přihlášení. 100% těchto přihlášení se snažilo používat naprosto nesmyslné uživatelské údaje které byli sice reálné např: root root nebo ssh ssh, ale nikdy jsem neviděl že by se ten robot snažil vyloženě o uhádnutí hrubou silou. Současně bych řekl, že ten problém uhádnutí hesla je sice důležitej, ale ke každému jednomu heslu přeci existuje i uživatelské jméno, které to utočníkovi zase o něco stěžuje....nedokážu si představit, že by útočník, který o mém systému nic neví dokázal jakýmkoliv způsobem uhádnout byť jen username natož pak k němu přiřadit i příslušné heslo.