Zdalne wywołanie poleceń w Linuxie (ssh / port knocking / fwknop / shell2http)

Szukałem ostatnio rozwiązania, które pozwoliłoby mi na zdalne wywołanie dowolnego polecenia na jednym z komputerów. 

Docelowy komputer czasami pracuje u mnie po *naście albo *dziesiąt godzin a że jest to ekonomicznie uzasadnione rozwiązanie smart tv to posiada pełnoprawny interfejs graficzny. A Xorg, jak to Xorg, swoje wady ma i często po kilkunastu godzinach pracy po prostu lubi się całkowicie sfreezować (zamrozić / zawiesić) i wówczas pomaga tylko twardy reset. Poszukiwane rozwiązanie problemu i docelowy zamysł był taki, żeby gui na czas wyjścia z domu wyłączyć (o ile nic się nie renderuje), a można to rozwiązać na cztery sposoby.

Pierwszy sposób to ssh. A zrobimy to w taki sposób:

ssh user@pc 'sudo systemctl stop lightdm.service; sudo chvt 1'

Powyższa komenda zatrzymuje nam menedżera logowania i jednocześnie przełącza tty z 7 (domyślne tty dla gui w Debianie) na 1. Gdybyśmy chcieli tylko podejrzeć, czy menedżer logowania się wyłączył to możemy włączyć sprawdzić np htopem:

ssh -t user@pc htop

Po zamknięciu htopa oczywiście zostaniemy rozłączeni.

Drugim sposobem jest tzw port knocking. Metoda - podobno - trochę przestarzała i mało bezpieczna. Polega na wysłaniu "sygnału" na określone przez nas porty, po czym wykonuje określone w konfiguracji komendy. Rozwiązanie dobre, ale tylko lokalnie.

Instalacja (w Debianie):

apt install knockd

Konfiguracja z sekwencjami portów znajduje się w /etc/knockd.conf, przykładowo:

[options]

UseSyslog

LogFile = /var/log/knockd.log

Interface = eno1

[echo]

        sequence    = 1,1,1

        seq_timeout = 1

        command     = echo

        tcpflags    = syn

W sekcji [options] warto uwzględnić nazwę interfejsu oraz gdzie ma być zapisywany log.

Plik "aktywacyjny" /etc/default/knockd:

# control if we start knockd at init or not

# 1 = start

# anything else = don't start

# PLEASE EDIT /etc/knockd.conf BEFORE ENABLING

START_KNOCKD=1

# command line options

KNOCKD_OPTS="-i eno1"

START_KNOCKD domyślnie jest na 0, nazwę sieci ustawiamy wedle potrzeb.

Z poziomu klienta, jeśli klientem również jest Debian instalujemy tę samą paczkę:

apt install knockd

I terminalu wystarczy wykonać:

knock -v host port1 port2 port3

Opcja -v powoduje wypisanie nam na ekranie poszczególnych działań.

Knocking działa również na interfejsach wifi. Po resztę informacji zapraszam do manuali.

Trzecim sposobem jest fwknop. W tym przypadku "logowanie" do serwera działa jak w przeglądarce internetowej. Tzn tworzymy klucz, który przesyłamy do serwera, prawie jak ciasteczko w przeglądarce. Jak serwer odbierze nasze dane to zaakceptuje nasze połączenie i wykorzysta według konfiguracji.

Przedstawię bardzo uproszczoną konfigurację. W przeciwieństwie do poprzedniego rozwiązania musimy zainstalować dwie różne paczki.

Na kliencie instalujemy:

apt install fwknop-client

A na serwerze:

apt install fwknop-server 

Na kliencie uruchamiamy:

fwknop -a ip.klienta -D ip.serwera --key-gen -C /sciezka/do/zdalnej/komendy --save-rc-stanza

--save-rc-stanza powoduje zapisanie konfiguracje w ~/.fwknoprc. W tym pliku mamy dwa klucze, KEY_BASE64 oraz HMAC_KEY_BASE64 które musimy przenieść na serwer (o tym niżej). Jak do jednego serwera chcemy wysłać kilka różnych komend (raz jedną, innym razem drugą) to przy generowaniu klucza możemy wykorzystać opcję -n nazwa. Dokładny opis w manualu.

Na serwerze włączamy usługę w /etc/default/fwknop-server z poniższymi argumentami:

START_DAEMON="yes"

DAEMON_ARGS="-f -U"

Dodatkowo mamy pliki /etc/fwknop/fwknopd.conf oraz /etc/fwknop/access.conf. Pierwszy zostawiamy z domyślną konfiguracją a do access.conf wrzucamy klucze z ~/.fwknoprc:

SOURCE              ip.klienta

KEY_BASE64          klucz1

HMAC_KEY_BASE64     klucz2

ENABLE_CMD_EXEC     Y

ENABLE_CMD_EXEC zezwala nam na uruchomienie zdalnej komendy. Z poziomu klienta:

fwknop -n docelowy.serwer -C /sciezka/do/komendy

I to wszystko :D fwknop docelowo służy do zdalnej modyfikacji reguł firewalla ale równie dobrze możemy wykorzystać go do zdalnego wykonania komend. W manualu widzimy również opcje CMD_CYCLE_OPEN, CMD_CYCLE_CLOSE oraz CMD_CYCLE_TIMER, których akurat nie testowałem. Mogłyby być alternatywą dla -C /sciezka/do/zdalnej/komendy (czy wystarczyłoby odpalić fwknop -n docelowy.serwer?).

W przeciwieństwie do knockd, za pomocą fwknop udało mi się uruchomić kilka komend jednocześnie (w skrypcie). knockd wykonywał tylko pierwszą komendę z docelowego skryptu.

Na Androida jest aplikacja fwknop. Nie testowałem.

Czwartym i ostatnim sposobem jest shell2http. To taka mała usługa, która pozwala na wykonanie poleceń z poziomu np przeglądarki internetowej (poprzez uprzednio skonfigurowany adress www). Jest to chyba najprostszy sposób jaki udało mi się znaleźć, teoretycznie najmniej problemowy i z tego co widzę to nie wymaga żadnych zależności. Póki co gotowej paczki nie ma w repozytoriach Debiana (stan na 19.01.2026) ale można znaleźć w sieci paczkę *.deb i na luzie ją zainstalować np z wykorzystaniem gdebi:

gdebi shell2http_1.17.0_linux_amd64.deb

Składnia polecenia jest prosta. Tworzymy usługę /etc/systemd/system/shell2http.service:

[Unit]

Description=shell2http

[Service]

Type=oneshot

ExecStart=/bin/shell2http  /polecenie1 "/sciezka/do/polecenia1" /polecenie2 "/sciezka/do/polecenia2"

[Install]

WantedBy=multi-user.target

W miejscu "/sciezka/do/polecenia1" możemy wpisać (między cudzysłowami) kilka poleceń oddzielonych znakiem ";". Następnie aktywujemy:

systemctl enable shell2http.service

Oraz uruchamiamy:

systemctl start shell2http.service

W przeglądarce internetowej odpalamy adres:

adres.ip.serwera:8080/polecenie1

Lub:

adres.ip.serwera:8080/polecenie2

Domyślny port to 8080, ale można to zmienić. Polecam zajrzeć do manuala. Odnoszę wrażenie, że shell2http reaguje najwolniej ze wszystkich opisanych rozwiązań.

I to wszystko :D

Najbezpieczniejszym rozwiązaniem wydaje się być fwknop z racji takiej że "sygnał" jest prawie nie do podrobienia (chyba, ze ktoś ma założony podsłuch) :D

Zdalny dostęp do GUI w Debianie (rdp/ssh) (wersja 1min)

To tylko krótka notka.
Poza x11vnc mamy jeszcze dwie inne możliwości, wedle potrzeb.
Pierwsza z nich to 'stare', dobre Windowsowe rdp. Daje nam, tak jak przy vnc, dostęp do "całego" ekranu i środowiska użytkownika. W Debianie instalujemy:

apt install xorgxrdp xrdp

I tyle. Pliki konfiguracyjne mamy w /etc. Usługa systemowa 'tworzy' się w trakcie instalacji, więc każdy sobie musi sam "dopracować" poszczególne ustawienia.

Drugą z opcji, jeżeli korzystamy z ssh, jest tzw X11 Forwarding. W przeciwieństwie do rdp i vnc poniższa funkcja umożliwia nam uruchomienie jednego konkretnego programu z poziomu terminala klienckiego. Sprawdzamy co mamy w pliku konfiguracyjnym:

cat /etc/ssh/sshd_config | grep -e X11Forwarding -e PermitUserEnvironment -e X11UseLocalhost

U mnie jest ustawione na:

X11Forwarding 

PermitUserEnvironment yes 

X11UseLocalhost yes

I tyle. Restartujemy usługę:

systemctl restart ssh.service

I to wszystko.

Druga opcja, umożliwia nam, zamiast instalacji całego środowiska graficznego, instalację np jednego konkretnego programu (do np księgowości, czy co tam potrzebujemy.

Programów graficznym pokroju gimpa czy innego blendera raczej bym nie uruchamiał, ale do mniej wymagających spraw dobre będą obydwie metody :D pozostała tylko kwestia przekierowania audio (w bliżej nieokreślonej przyszłości, mam już kilka pomysłów).

Instalacja i konfiguracja Lyrion Music Server na przykładzie Debiana

Całkiem przez przypadek znalazłem ostatnio Lyrion Music Server. Jest to serwer muzyki z masą różnych opcji i dodatków. Okazało się, że instalacja jest cholernie prosta, soft bardzo użyteczny a i jak ktoś ma stary sprzęt grający (tudzież wzmacniacz, głośniki, cokolwiek innego) to wystarczy zainwestować np w jakiś mały komputerek (terminal, mini pc, raspberry pi, cokolwiek podobnego) i mamy na czym słuchać :D

https://lyrion.org/

Poza instalacją Debiana wystarczy zainstalować paczkę deb z powyższej strony (najlepiej z wykorzystaniem gdebi to i dociągnie zależności) oraz dodatkowo wymagany będzie poniższy odtwarzacz:

https://packages.debian.org/trixie/squeezelite

Dla stable instalujemy...:

apt install squeezelite

Pakiet w repo dostępny jest od wydania Debiana Bullseye do Unstable (na 22.12.2025).

Jako że docelowo chciałem mieć możliwość odtwarzania muzyki zgranej z płyt do katalogu domowego docelowego użyszkodnika, to musiałem trochę pokombinować. Serwer tworzy użytkownika squeezeboxserver, więc testowo dodałem go do następujących grup:

gpasswd -a squeezeboxserver users

gpasswd -a squeezeboxserver uzyszkodnik

Uprawnienia dla katalogu domowego:

chmod -R 755 /home/uzyszkodnik

Pozwoli nam to na dostęp do muzyki. Dla list odtwarzania zrobiłem osobny katalog m3u i dla niego inne uprawnienia:

chmod -R 777 /home/uzyszkodnik/m3u

Dodatkowo, w opcjach serwera:

No i to by było na tyle. Reszta konfiguracji odbywa się poprzez panel administracyjny. Dostęp można zahasłować - panel Zaawansowane i Zabezpieczenia.

Konfiguracja transmission-daemon na przykładzie Debiana Stable

Kilka tygodni temu potrzebowałem skonfigurować klienta Transmission w trybie systemowej usługi (tzw demona). Oto bardzo krótki poradnik na przykładzie Debiana Stable (wersja 13 w momencie pisania). U mnie usługa działa na użytkowniku na którym docelowo operuję.

Najpierw instalujemy:

apt install transmission-cli transmission-common transmission-daemon

Usługa po wystartowaniu ładuje sobie konfig i w trakcie wyłączania np systemu nadpisuje wcześniej zapamiętaną konfigurację. Niweluje nam to wprowadzone w między czasie zmiany także jeżeli po powyższej instalacji, o ile usługa sama z siebie wystartuje, wyłączamy:

systemctl stop transmission-daemon.service

Następnie musimy utworzyć następujący plik (katalog, jeśli nie istniejemy, również należy utworzyć)...:

nano /etc/systemd/system/transmission-daemon.service.d/user.conf

... o następującej zawartości:

[Service]

User=

User=xxx

Group=xxx

Naszego użytkownika, w omawianym przypadku xxx, dodajemy do odpowiedniej grupy:

gpasswd -a xxx debian-transmission

W katalogu domowym tworzymy katalog:

mkdir .config/transmission-daemon

I z katalogu plik z ustawieniami:

cp /etc/transmission-daemon/settings.json .config/transmission-daemon/

Zawartość /etc/transmission-daemon profilaktycznie usuwamy (z poziomu roota):

rm -R /etc/transmission-daemon/*

W pliku konfiguracyjnym .config/transmission-daemon/settings.json znajdujemy i zmieniamy następujące linie tak, żeby ściągnięte materiały były np w naszym katalogu domowym:

    "download-dir": "/home/xxx/Pobrane",

    "incomplete-dir": "/home/xxx/Pobrane",

Hasło znajduje się w poniższej linijce...:

    "rpc-password": "jakies-haslo",

Hasło wpisujemy jakie chcemy, transmission-daemon na swój sposób je przetworzy dając wynik w - na pozór - losowych znakach w pliku wyżej (zakładam, że dlatego wczytuje i nadpisuje konfigurację uniemożliwiając dokonanie zmian w trakcie działania).

Teraz wykonujemy z poziomu roota następujące dwie komendy:

systemctl daemon-reload ; systemctl start transmission-daemon.service

I to by było na tyle. Pisane z pamięci, mam nadzieję że się nie pomyliłem gdzieś po drodze :D

Server VNC z poziomu ekranu logowania - GNU/Linux Debian

Od jakiegoś czasu zachodziła potrzeba uruchomienia serwera vnc na kilku maszynach. Nie zawsze jest czas żeby biegać od ekranu do ekranu, nawet jeżeli są to jednostki do testów itp.

Naskrobałem (no dobra, podobne rozwiązanie można znaleźć...) usługę systemową (unit w systemd pod Debianem 13). Tworzymy plik /etc/systemd/system/x11vnc.service o następującej zawartości:

[Unit]

Description=x11vnc

After=display-manager.service network.target syslog.target

 

[Service]

Type=forking

ExecStart=/usr/bin/x11vnc -forever -display :0 -auth guess -rfbauth plik.z.haslem

ExecStop=/usr/bin/killall x11vnc

Restart=on-failure

 

[Install]

WantedBy=multi-user.target

Tworzymy plik.z.haslem (najwygodniej w katalogu /etc lub ewentualnie /opt):

x11vnc -storepasswd haslo plik.z.haslem

Następnie, oczywiście z uprawnieniami roota:

systemctl daemon-reload

systemctl enable x11vnc.service

systemctl start x11vnc.service

 

I to było na tyle.

iwlwifi - wyłączenie trybu oszczędzania energii powersave

 Cześć!

Pokrótce. Na wifi6 Intela (AX200) sieć po dłuższym czasie zaczynała "ścinać" i pracować niestabilnie. Pomagało rozłączenie i połączenie na nowo.

Szczegóły znajdują się w tym (wątku)

Używam Network Managera i u mnie zadziałały dwie metody.

Pierwsza metoda jest dla NM. Robimy taki skrypcik (nazwa i zapis w pliku *.sh dowolnie):

wifi=`nmcli connection show --active | grep wifi | awk '{print $1}'`

sudo nmcli connection modify $wifi 802-11-wireless.powersave disable

Niestety składnia wiersza poleceń nmcli wymusza każdorazowe wykonanie skryptu po zmianie sieci więc trzeba zrobić to manualnie. Można wrzucić to też do cron'a lub napisać własną usługę żeby skrypt sprawdzał (w dodatkowej linijce) czy powersave jest włączony, jeśli tak to go wyłączamy jak wyżej i to wszystko.

Druga metoda jest bardziej pewna bo powersave jest wyłączony na poziomie "kernela" i jest to zrobione w trakcie uruchamiania się systemu. W swoim bootloaderze dopisujemy takie cudo jako opcję kernela:

iwlwifi.power_save=0

Dla gruba domyślnie będzie to plik /etc/default/grub i następująca linijka:

GRUB_CMDLINE_LINUX_DEFAULT="quiet iwlwifi.power_save=0"

Trzecią metodą, której nie sprawdzałem ale powinna zadziałać, jest utworzenie pliku /etc/modprobe.d/iwlwifi.conf z poniższą zawartością:

options iwlwifi power_save=0

I tyle.

command not found po zalogowaniu się na root'a (via su)

W Debianie 10 wprowadzili małą zmianę w poleceniu su która polega na dostarczeniu (lub nie) zmiennych dotyczących m. in. dostępu do programów tylko dla root'a. Traf chciał że odkryłem to dopiero po 4 latach na Debianie 12 (wcześniej korzystałem przez kilka lat z Ubuntu LTS). Owa zmiana objawiała się jak na zrzucie:

Sprawdziłem zmienne i oto rezultat:

Na wiki Debiana jest taki wpis, w którym napisane jest:

The su command in buster is provided by the util-linux source package, instead of the shadow source package, and no longer alters the PATH variable by default. This means that after doing su, your PATH may not contain directories like /sbin, and many system administration commands will fail. There are several workarounds:

Use su - instead; this launches a login shell, which forces PATH to be changed, but also changes everything else including the working directory.

Use sudo instead. sudo still runs commands with an altered PATH variable.

To get a regular root shell with the correct PATH, you may use sudo -s.

To get a login shell as root (equivalent to su -), you may use sudo -i.

Put ALWAYS_SET_PATH yes in /etc/default/su (create it) to get an approximation of the old behavior. This is documented in su(1).

Put the system administration directories (/sbin, /usr/sbin, /usr/local/sbin) in your regular account's PATH (see EnvironmentVariables for help with this).

Wykorzystałem więc przedostatnią metodę:

/etc/default/su:

ALWAYS_SET_PATH yes

I Problem rozwiązany :D

Podziękowania dla Forumowiczów z dug.net.pl którzy dali namiar na rozwiązanie problemu :D

Zmiana polskich znaków na łacińskie w napisach (sed, enca)

W 2014 popełniłem wpis dotyczący zamiany polskich znaków w plikach tekstowych na ascii. Chodziło wówczas o to, by w razie problemów z kodowaniem plików tekstowych, odtwarzacz je wyświetlający nie "krzaczył". To jeszcze pół biedy, bo w ten sposób można byłoby się domyśleć o co chodzi, ale vlc lubi po prostu nie wyświetlać "problematycznych" linii tekstu.

Otóż poprawiłem nieco skrypt i o to rezultat:

#!/bin/bash

for f in *.srt; do

   sed 's/ą/a/g' "$f" -i;

   sed 's/ę/e/g' "$f" -i;

   sed 's/ż/z/g' "$f" -i;

   sed 's/ź/z/g' "$f" -i;

   sed 's/ł/l/g' "$f" -i;

   sed 's/ó/o/g' "$f" -i;

   sed 's/ą/a/g' "$f" -i;

   sed 's/ś/s/g' "$f" -i;

   sed 's/ć/c/g' "$f" -i;

   sed 's/ń/n/g' "$f" -i;

   sed 's/Ą/A/g' "$f" -i;

   sed 's/Ę/E/g' "$f" -i;

   sed 's/Ż/Z/g' "$f" -i;

   sed 's/Ź/Z/g' "$f" -i;

   sed 's/Ł/L/g' "$f" -i;

   sed 's/Ó/O/g' "$f" -i;

   sed 's/Ą/A/g' "$f" -i;

   sed 's/Ś/S/g' "$f" -i;

done

Lub, z wykorzystaniem enca:

#!/bin/bash

for f in *.srt; do

   enca -L polish -x utf-8 "$f"

done

Wykorzystanie smartfona jako kamery internetowej - Android

Cześć!

Żeby wykorzystać naszego smartfona jako kamery internetowej potrzebujemy:
- smartfon z androidem :)
- WiFi lub kabel usb
- Windowsa lub Linux'a :)

Najpierw, instalujemy aplikację DroidCam:

Użytkownicy Windowsa ściągają aplikację (KLIK), instalują i się niczym nie martwią :) uwaga - zgodnie z tym co jest napisane w podanym linku, programy z Windows Store mogą nie wykrywać w ten sposób naszej kamery. Poszczególne aplikacje trzeba dograć "ręcznie", spoza sklepu.

Użytkownicy Linux'a ściągają aplikację (KLIK) i się niczym nie martwią. Protip -> przy każdej aktualizacji kernela trzeba ręcznie kompilować sterownik, co zajmuje 5 sekund, z czego 4 wklepanie komendy.

Droid Cam z automatu działa przez WiFi. Chcąc jednak skorzystać z przewodu USB należy wprowadzić małą zmianę w ustawieniach telefonu. Najpierw należy włączyć "opcje programisty" lub "opcje programistyczne":
- ustawienia > system > informacje o urządzeniu > 7x klik na "numer kompilacji":

Następnie w samych opcjach programisty należy włączyć "debugowanie usb:"

I to wszystko. Tak wygląda droidcam pod linux'em:

A tak pod Windowsem:

A sama aplikacja z poziomu smartfona wygląda następująco:

I to wszystko. Dziękuję za uwagę :)

Konfiguracja prostego klastra komputerowego wysokiej dostępność (HA) na przykładzie Windows Server 2008

Cześć!

Stworzyłem kiedyś klaster komputerowy wysokiej dostępności, który posłużył mi jako podstawka do obrony tytułu inżyniera. Wykorzystałem do tego Windows Server 2008 R2, oraz grę fps Assault Cube, żeby zobrazować działanie klastra. Szczegółowo nie warto opisywać tej pracy ze względu starą wersję serwerowego systemu Windows. W zamian za to wrzucę tutaj same zrzuty ekranowe dla "skrótu myślowego", ponieważ nowsze wersje niewiele się różnią w stosunku do 2008 R2.

I na koniec krótki filmik:

Messenger w Pidginie (2018) - Ubuntu 18.04 LTS

Kiedyś Facebook korzystał z XMPP w Messengerze. Kilka lat temu jednak wycofali wsparcie dla XMPP na rzecz własnego protokołu. Oto działające rozwiązanie w grudniu 2018 roku.

Najpierw musimy znaleźć i ściągnąć pakiet purple-facebook przeznaczony dla naszej wersji systemu. Dla mnie będzie to:

wget http://download.opensuse.org/repositories/home:/jgeboski/xUbuntu_18.04/amd64/purple-facebook_20180323~ef6ae47~9ff9acf9fa14~145_amd64.deb

Jakby powyższy link nie działa, lub paczka nie jest przeznaczona dla naszej wersji systemu, to wówczas musimy sami namierzyć potrzebną nam wersję. Link do repo na dole.

Następnie instalujemy ją:

gdebi purple-facebook_20180323~ef6ae47~9ff9acf9fa14~145_amd64.deb

Zamiast gdebi możemy wykorzystać dpkg:

dpkg-i purple-facebook_20180323~ef6ae47~9ff9acf9fa14~145_amd64.deb

Następnie:

 aptitude install pidgin-encryption

A na końcu...:

I to wszystko, mamy działającego messengerze w Pidginie.

Linki:
- repo jgeboski