Klucze SSH mogą być wykorzystane jako sposób identyfikacji danej osoby przy logowaniu się do zdalnego serwera SSH. Te klucze zawsze występują w parach -- jeden prywatny, drugi publiczny. Pierwszy z nich jest znany tylko nam i powinien być trzymany w sekrecie i pilnie strzeżony. Klucz publiczny z kolei zaś jest przesyłany na każdy serwer SSH, z którym chcemy się połączyć. Gdy serwer jest w posiadaniu naszego klucza publicznego i widzi przy tym, że próbujemy nawiązać połączenie, używa on tego klucza by wysłać do nas zapytanie (challange) -- jest ono zakodowane i musi na nie zostać udzielona odpowiednia odpowiedź, a tej może dokonać ktoś, kto jest w posiadaniu klucza prywatnego. Nie ma innej opcji by rozkodować wiadomość, dlatego też nikt inny nie może udzielić na nią prawidłowej odpowiedzi. To rozwiązanie eliminuje wrażliwość na różne formy podsłuchu -- ten kto nasłuchuje nie będzie w stanie przechwycić pakietów zawierających hasło, bo ono nie jest nigdy transmitowane prze sieć. No i oczywiście jeśli chodzi o samo hasło -- odpadają nam ataki typu Brute Force pod kątem jego złamania.

Ostatnio opisywałem skrypt wp-cli , który posiada ciekawe możliwości pod względem zarządzania instalacją i konfiguracją WordPressa. W tym artykule postaram się przebrnąć przez ten proces wykorzystując jedynie powyższe narzędzie. Nie mam zamiaru korzystać z przeglądarki i nie będę przy tym nawet potrzebował odwiedzać strony WordPressa w celu pobrania jakichkolwiek plików. Wszystkie poniższe kroki zostaną przeprowadzone w terminalu na serwerze i mam nadzieję, że uda mi się pobrać, zainstalować i przygotować WordPressa do pracy.

Narzędzie wp-cli to wiersz poleceń upchnięty w pliku .phar (PHP Archive), przy pomocy którego możemy zarządzać instalacją WordPress'a bez potrzeby zaprzęgania do tego przeglądarki. Przy pomocy tego skryptu będziemy w stanie instalować i aktualizować rdzenne pliki WordPress'a, jego wtyczki i motywy, a także dokonywać szeregu operacji na bazie danych. Projekt jest na licencji MIT, zaś jego źródła są dostępne na githubie.

By dokonywać jakichkolwiek zmian w WordPressie (i mowa tu nie tylko o dodawaniu treści ale także zmianie jego plików źródłowych), to musimy uzyskać dostęp do panelu administracyjnego, a tu z kolei możemy się dostać tylko za pośrednictwem formularza logowania. Panel admina możemy wywołać przez dopisanie do adresu strony wp-admin/ , z tym, że jeśli nie jesteśmy zalogowani, to automatycznie zostaniemy przekierowani na wp-login.php . Nie oznacza to bynajmniej, że nie możemy wykonać zapytania do plików znajdujących się w katalogu wp-admin/ . Obie te powyższe lokalizacje muszą być traktowane ze szczególną ostrożnością, a dostęp do nich limitowany i bardzo restrykcyjny.

Standardowo WordPress dorzuca nieco informacji na swój temat bezpośrednio do kodu wygenerowanej witryny. Jednym z bardziej niebezpiecznych takich dodatkowych wpisów jest wskazówka na temat zainstalowanej wersji skryptu. Oczywiście, że powinniśmy aktualizować WordPressa na bieżąco i możliwie od razu jak tylko zostanie wypuszczona jego nowa wersja ale nie zawsze możemy nadążyć za tymi wszystkimi zmianami i wyrobić się w terminach. Ja jestem też zdania, że kluczowe oprogramowanie (zwłaszcza w internecie) powinno posiadać wersję nie do ustalenia, albo chociaż jakiś mylący ciąg znaków, tak by automatyczne ataki opierające się o wersję danej aplikacji, nie tyle zostawiły nas w spokoju, co zaczęły popełniać błędy, które będą widoczne w logach. Przynajmniej takie jest optymistyczne założenie.

Jeśli zamierzamy kupić sprzęt, który dopiero co trafił na półki w sklepach, to prawdopodobnie zaraz po podłączeniu go do naszego komputera okaże się, że to urządzenie nie jest nawet wykrywane przez system operacyjny. W przypadku gdy jego producent zapewnia w miarę przyzwoity support, to być może problemy, których doświadczamy, zostaną rozwiązane wraz z instalacją najnowszego kernela. Co jednak w przypadku gdy nawet po aktualizacji kernela nie jesteśmy w stanie odpalić, np. nowo zakupionej karty WiFi? Jako, że te wszystkie sprzęty działają w oparciu określone moduły, wystarczy taki moduł pozyskać, skompilować i załadować w systemie. Problem w tym, że z każdą nową wersją jądra operacyjnego, która trafi do repo debiana, będziemy musieli ręcznie budować moduł na nowo i właśnie w tym artykule opiszę jak nauczyć system, by sam przeprowadzał tę mozolną czynność bez naszego udziału.

WordPress, jako jeden z popularniejszych CMSów, został przetłumaczony na wiele języków, w tym też i na polski. Czasem jednak przez zwykłe roztargnienie (lub też i z innych przyczyn) możemy nie przestawić opcji odpowiedzialnej za język, wobec czego zainstaluje nam się angielska wersja WordPressa. W tym krótkim wpisie zostanie zawartych kilka informacji na temat tego jak zmienić język, na wypadek gdybyśmy odziedziczyli angielską wersję skryptu oraz też jak przebiega sam proces lokalizacji tekstu w WordPressie i co się tak naprawdę dzieje po wybraniu innego języka.

Być może kiedyś zdarzy się nam taka sytuacja, gdzie zwyczajnie zapomnimy hasła do konta admina na naszym blogu opartym o skrypt Wordpressa. Standardowo ten CMS nie wymaga od nas byśmy podawali hasło przy przeprowadzaniu szeregu operacji w panelu administracyjnym, w przeciwieństwie do usług świadczonych choćby przez google. Jeśli zdarzy nam się zgubić albo zapomnieć takie hasło, to mamy cały wachlarz rozwiązań, z którego możemy skorzystać, by hasło odzyskać.

Typografia ma na celu wprowadzenie pewnego rodzaju urozmaiceń do pisanego tekstu, takich jak np. bardziej zawinięte ogonki w cudzysłowach, albo zmianę ich pozycji (lewy dolny róg, zamiast górnego), czy też mniejszy odstęp między trzema kropkami lub ewentualnie łączenie kilku myślników w jeden dłuższy. W WordPressie ten mechanizm automatycznie będzie przepisywał nam te powyższe znaki (i wiele innych), co w przypadku systemów linuxowych nie zawsze jest rzeczą pożądaną, a to z tego względu, że np. skrypty shellowe, czy polecenia systemowe, korzystają jedynie z prostych apostrofów ' oraz prostych cudzysłowów " i wszelkie inne odpowiedniki, to inny numerek w tablicy kodowej, a więc i inny znak. Wobec czego, tak skopiowany tekst (czy skrypt) będzie zawierał błędy składni.

Wszystkie główne dystrybucje, a może raczej ich środowiska graficzne, wykorzystują do odtwarzania dźwięku serwer PulseAudio. Niektóre wręcz są tak z nim zżyte, że nie idzie ich oddzielić od siebie. Ja generalnie uważam, że ten kawałek oprogramowania jest jak najbardziej przydatny człowiekowi i potrafi realizować kilka kwestii, które bez niego, albo by nie były możliwe do osiągnięcia, albo trzeba by się natrudzić przy ich implementacji, np. przesyłanie dźwięku przez sieć. U siebie na debianie nigdy nie miałem większych problemów z PulseAudio, z kolei zaś te, które się przytrafiały na drodze jego użytkowania, szło w miarę prosty sposób wyeliminować. Jest jednak jeden problem, z którym prawdopodobnie spotkaliśmy się wszyscy, przynajmniej jeśli wykorzystujemy mikrofon w stopniu większym niż przeciętny użytkownik komputera. Chodzi o to, że po odpaleniu pewnych aplikacji (lub też i w trakcie ich działania), takich jak np. Skype, Mumble, czy TeamSpeak3, dźwięk we wszystkich pozostałych programach potrafi zwyczajnie zdechnąć.