IT Varia

Mercurial na wspólnym koncie SSH dla wielu użytkowników.

2011-04-23T13:12:00.011+02:00

Przedstawiona niżej technika dzielenia repozytorium umożliwia wielu użytkownikom korzystaniem z repozytorium Mercuriala(przy drobnej modyfikacji to samo dotyczy gita) na jednym koncie SSH bez udzielania wszystkim dostępu do shella. Jedyne co na naszym koncie będą mogli robić nasi współpracownicy to korzystanie z określonego repo. Technika ta jest przydatna w przypadkach gdy nie mamy możliwości by każdemu commiterowi przydzielić osobne konto shellowe.
Oczywiście istnieją gotowe(często dość rozbudowane skrypty) korzystające z tej metody(np.Gitosis).
W poniższym artykule chciałbym dotrzeć jednak do sedna działania, dzięki temu czytelnicy będą mogli wymyślić także inne zastosowania i udziwnienia.

By umożliwić innej osobie korzystanie z naszego shella bez podawania jej hasła korzystamy z kluczy RSA. Jak dokładnie należy to zrobić napisałem w innym artykule(Klik). W stosunku do niego należy wykonać drobną modyfikację. Przed treścią klucza należy dopisać poniższą linijkę:


no-port-forwarding,command="./script.pl"

"command" jako shella ustawia wybrane przez nas polecenie, przy okazji zabraniamy znajomym forwardowania za pomocą naszego konta(wszystkie możliwe opcje możemy znaleźć w manualu do sshd).

Teraz pora na najistotniejszą część, tj. treść skryptu(w tym wypadku PERL), która może wyglądać np. tak:


#!/usr/bin/perl

$command = $ENV{'SSH_ORIGINAL_COMMAND'};

if($command eq "hg -R merktest serve --stdio") {
exec($command);
} else {
print "Shell access denied!\n";
}

Oczywiście jest to tylko przykładowy kod dla szczególnego przypadku(dostęp do repozytorium pod nazwą "merktest" ). Można go uogólnić, ulepszyć wedle uznania, wyobraźni i potrzeb. Nie daję tutaj rozbudowanego przykładu gdyż nie jest to celem artykułu ;).

Jeśli chcemy zrobić coś analogicznego dla git'a zmieniamy warunek na:


if ($command eq "git-upload-pack gitrepo")

Oczywiście to również jest szczególny przypadek dla repozytorium o nazwie "gitrepo".

Generalnie polecam eksperymenty.

SOCKS proxy via SSH

2011-03-30T00:44:00.002+02:00

Przydatne przy omijaniu limitów pobierania z różnych rapid-wynalazków i do kilku innych celów.


ssh -D 12345 myuser@remote_ssh_server

Przykładowe ustawienie w Chrome:

Preferencje->Dla zaawansowanych->Ustawienia Proxy->Ręczne ustawienie Proxy
Tam ustawiamy hosta i port. W tym wypadku będzie to odpowiednio: localhost, 12345.

Dostęp do repozytorium Git'a na niestandardowym porcie SSH

2011-03-29T00:09:00.003+02:00

Post z serii: "Dziś pytanie - dziś odpowiedź"

Wbrew pozorom by rozwiązać tytułowy problem nie musimy zmieniać zanadto konfiguracji gita. Rozwiązaniem natomiast jest wyedytowanie pliku .ssh/config.
Przykładowa konfiguracja:


 Host MyRepo
     HostName myrepo.pl
     Port 666
     User myuser

Wtedy .git/config wygląda np. tak:


[core]
repositoryformatversion = 0
 filemode = true
 bare = false
 logallrefupdates = true
[remote "origin"]
 fetch = +refs/heads/*:refs/remotes/origin/*
 url = MyRepo:RepoName
[branch "master"]
 remote = origin
 merge = refs/heads/master

MyRepo - Etykieta której użyliśmy w pliku .ssh/config
RepoName - Zdalny folder z repozytorium Git'a

Szybka synchronizacja danych za pomocą RSync'a i sshfs

2011-03-28T02:57:00.006+02:00

Przykładowy skrypt nie wymagający wielkiego komentarza:


#!/bin/sh
sshfs -p 666 user@farmachine.pl:/home/shark /home/shark/fardata/
rsync -rvvl --exclude-from exclude.txt /home/shark/LOCAL-FOLDER/ /home/shark/fardata/REMOTE-FOLDER
sudo umount /home/shark/fardata

Krótkie wyjaśnienie:

1.Za pomocą systemu plików sshfs montujemy zdalny zasób na w lokalnym folderze
2.Za pomocą rsync'a(jak sama nazwa wskazuje) synchronizujemy zasoby(tu ważne by rozumieć, że kopiowanie następuje od lewa do prawa. Kolejność argumentów jak przy standardowym 'cp')
3.Odmontowujemy, zamontowany wcześniej zasób
4.Koniec ;)

Opcje:

r - kopiowanie rekurencyjne (Rekurencja - patrz: rekurencja ;))
v - verbose
l - kopiuj symlinki jako symlinki
exclude-from - wyłączenie wybranych plików ze śledzenia przez rsync'a(w tym wypadku wystarczy wypisać te pliki w osobnych liniach w pliku exclude.txt)

P.S. By móc korzystać z sshfs należy posiadać FUSE'a i pakiety zależne(apt-get sam załatwia sprawę)

Dla zainteresowanych: man sshfs, man rsync

Przydatność screena

2010-08-03T00:37:00.006+02:00

Dawno nic nie pisałem. Oczywiście nie będę opisywał czym screen jest - jestem na to zbyt leniwy, z resztą po co kserować wikipedie? :> Artykuł będzie bardzo krótki i precyzyjny :P

Opiszę ciekawy(moim zdaniem) przypadek użycia. Inspiracją powstania artykułu był problem postawiony przez kolegę. Problem prezentuje się następująco:

Chcemy wykonać jakąś długotrwałą operację na naszym koncie shellowym(np. kopiowanie plików na inne konto :) ) ale nie chcemy zostawiać włączonego komputera.

Rozwiązanie:

1.Logujemy się na konto
2.Odpalamy screena ( polecenie screen)
3.Odpalamy potrzebny program(np. mc)
4.Kopiujemy co tam chcemy
5.Ctrl+Z
6.bg
7.Ctrl+a d (puszczenie screena w tło)
8.Wylogowujemy się
9.Idziemy biegać ;)

Kiedy wrócimy:

1.Logujemy się
2.screen -r
3.fg
4.Cieszymy się zakończoną operacją(lub czekamy dalej :P)

KONIEC

Do przeczytania:

Screen

Podgląd obrazków w JS z wykorzystaniem

2010-07-13T00:48:00.014+02:00

Tradycyjnie wpis będzie krótki, gdyż wolę pokazać trochę więcej kodu a mniej się rozpisywać. Nie mniej jednak należy się krótkie wyjaśnienie. Po co pisać notkę na tak precyzyjnie określony temat?
Okazuje się, że rozwiązanie powyższego problemu nie jest tak oczywiste jak mogłoby się wydawać.
Z przyczyn bezpieczeństwa większość przeglądarek(jak na razie jedynym wyjątkiem jaki znalazłem jest IE) uniemożliwia podejrzenie przez programistę JS pełnego parametru 'value' kontrolki input z typem "file". Jak zatem dostać się do pliku graficznego i wyświetlić go za pomocą JS jeszcze przed załadowaniem na serwer? Rozwiązaniem jest dobranie się do obrazka zapisanego w postaci base64(czyli po prostu surowych danych),utworzenie obiektu img oraz wyświetlenie go na ekranie. Koniec czczej pisaniny. Przed nami przykład.


 1 <script type="text/javascript" src="pixastic.core.js"></script>

 2 <script type="text/javascript" src="actions/resize.js"></script>
 3 <script type="text/javascript">

 4 
 5 
 6         function loadImage() {
 7 

 8         var img = new Image();
 9         

10  img.onload = function() {
11 
12                 Pixastic.process(img, "resize", {

13                         width : 100,
14                         height : 100
15                 });

16 
17         }
18 
19 
20 
21         var imgsource;

22 
23                 if(document.getElementById('filefield').files) {
24                 imgsource = document.getElementById('filefield').files.item(0).getAsDataURL();

25                 };
26 
27 
28         datastring = new String(imgsource);

29         mime = datastring.substring(0, 10);
30 

31         if(mime=='data:image') {
32         img.src = imgsource;

33         document.getElementById('my').innerHTML="";
34 
35         setTimeout(function() {

36         document.getElementById('my').appendChild(img);
37 
38         }
39         ,50);

40 
41         } else {alert("Niepoprawny typ pliku!!"); }

42 
43 
44         }
45 
46         </script>
47 

48         <html>
49 
50             <head>
51             </head>
52 

53         <body>
54 
55         <span id='my'></span>
56 
57         </body>

58  </html>

syntax highlighted by Code2HTML, v. 0.9.1

Wprawne oko zauważy, że w powyższym kodzie jest coś więcej niż tylko rozwiązanie problemu z tytułu. W istocie tak jest. W przykładzie zastosowałem bibliotekę 'Pixastic'(wiele ciekawych zastosowań - polecam), które posłużyła mi do stworzenia miniaturki obrazka. Dodatkowo kod zawiera zabezpieczenie przed omyłkowym wprowadzeniem pliku który nie zawiera grafiki a także timeout który daje czas na zmniejszenie obrazka. Jeśli ktoś jest ciekawy co się stanie bez timeoutu i po zmianie innych opcji - zapraszam do eksperymentowania.

Aktualizacja: Okazuje się, że zaprezentowana metoda działa jedynie w FF3!!
Jeśli uda mi się znaleźć jakiś bardziej uniwersalny sposób(w co wątpię) lub chociaż
obejścia dla innych przeglądarek coś o tym napiszę.

Do przeczytania

Pixastic
Base64
Inspiracja powyższej notki - dla znających j.francuski

Mac i Linux

2010-07-05T02:32:00.004+02:00

Niniejszy artykuł znów będzie krótki. Pozwolę sobie przedstawić bardzo prosty sposób instalacji(i uruchomienia) Linuksa na lanserskim sprzęcie wyprodukowanym przez firmę Steve'a Jobsa.
W sieci krąży mnóstwo metod korzystających z narzędzia rEFIt.
Co jednak zrobić gdy w ogóle nie chcemy korzystać z MacOSX ani jego bootloadera na naszym błyszczącym pudełku?
Sposób jest prosty i niektórym znany. Jedyne co należy zrobić to zmienić format tablicy partycji(a właściwie utworzyć nową tablicę) z GPT domyślnego dla współczesnych MACów dla bliższy PCtowcom format MBR(w programie parted - msdos). Można wykonać tą operację za pomocą instalatora MacOSX(sposób banalny) lub pod Linuksem(instalatorem lub LiveCD) za pomocą programu GNU Parted(sposób niewiele trudniejszy).
Jak używa się instalatora MacOSX chyba nie muszę opisywać, jeśli chodzi o program GNU Parted polecam przeczytanie manuala. Nie muszę chyba wspominać o konieczności zarchiwizowania istotnych danych.
Po wykonaniu tej czynności można już całkiem zwyczajnie instalować system wraz z bootloaderem który należy umieścić w MBR. Po zakończeniu procesu i resecie naszym oczom ukaże się białe tło a po chwili(niestety aż kilkanaście sekund) ekran bootloadera.

UWAGA! Sposób testowany na Macu Mini i dystrybucji Debian Lenny.

Do przeczytania:

GPT
MBR
GNU Parted
EFI
rEFIt

Upgrade do Ubuntu 10.04 i problem z Apache'em

2010-06-11T00:49:00.008+02:00

Po upgradzie mojego Ubuntu do 10.04 LTS pojawił się bardzo irytujący problem. Apache przestał przetwarzać pliki php umieszczone w folderach użytkownika.
Przykładowo: http://localhost/~user/example.php nie chciało działać. Żeby było śmieszniej http://localhost/example.php działało bez problemu.

Na szczęście tym razem pomógł Ardvark(www.vark.com). Przy okazji polecam ten serwis.

Okazuje się, że aktualizacja wprowadziła pewne "usprawnienie" do konfiguracji Apache'a.

Rozwiązaniem jest edycja pliku /etc/apache2/mods-enabled/php5.conf i zakomentowanie następujących linijek:


<IfModule mod_userdir.c>
<Directory /home/*/public_html>
php_admin_value engine Off
</Directory>
</IfModule>>

Potem wystarczy zrestartować serwer np. tak:

sudo /etc/init.d/apache2 restart

Po wykonaniu powyższych czynności wszystko wraca do normy i można już spokojnie kodzić w php ;)

Źródło:ubuntuforums

Klucze RSA

2010-05-28T21:29:00.006+02:00

Poniższa notka będzie jeszcze krótsza od poprzedniej ;>
Teraz do rzeczy. Tworzenie kluczy to dość prosty proces.
Przebiega następująco:

Wchodzimy do katalogu .ssh w naszym katalogu domowym i wpisujemy:

ssh-keygen

Generator zapyta najpierw o nazwę pliku,do którego zostanie zapisany klucz. Domyślnie będzie to id_rsa(klucz prywatny), jeśli chcemy zmienić nazwę pliku wpisujemy coś, jeśli nie wystarczy ENTER. Klucz publiczny będzie nazywać się prawie tak samo - dodatkowo posiada rozszerzenie "pub". Kolejnym krokiem jest wpisanie hasła(dwukrotnie), przy czym nie jest ono konieczne(jeżeli nie chcemy hasła wystarczy ENTER). W ten sposób utworzyliśmy klucz.
Teraz jeśli chcemy móc logować się na zdalnego hosta za pomocą klucza powinniśmy wysłać na niego nasz klucz publiczny(id_rsa.pub).
Na zdalnym hoście kopiujemy ten plik do katalogu .ssh(plikowi możemy zmienić nazwę - to nie ma znaczenia) i wykonujemy:

cat id_rsa.pub >> authorized_keys

(id_rsa.pub to oczywiście nasz plik z kluczem publicznym)

Od tej pory możemy bezpiecznie logować się na nasze konto shellowe.

Reverse Shell

2010-05-27T17:39:00.004+02:00

To będzie bardzo krótki ale za to konkretny wpis. ;]
Chciałbym przedstawić ciekawą możliwość, którą daje protokół ssh o której pewnie nie każdy wie.

Rozważmy następującą sytuację:

Mamy dwa hosty - A i B. Komputer A znajduje się w sieci wewnętrznej za maskaradą, komputer B jest w sieci publicznej. Do wykonania poniższych operacji nie potrzebujemy konta administratora. Chcemy z komputera B zalogować się na shella komputera A. Sytuacja odwrotna jest oczywiście trywialna. Jak jednak dostać się do shella komputera znajdującego się w sieci prywatnej?

Rozwiązanie:

user@A:~$ ssh -NR 3333:localhost:22 user@B

W ten sposób ustanawiamy połączenie w trybie odwrotnego shella(-R), przełącznik -N służy do tego by nie otwierać shella w trybie interaktywnym. To połączenie będzie nam służyło jedynie do ustawienia ścieżki zwrotnej. Jak wiadomo nie możemy bez dodatkowych operacji połączyć się z hostem w sieci prywatnej. Pierwszy numer portu to port wejściowy komputera A(kiedy nie mamy roota musi być wyższy niż 1024), drugi to oczywiście port SSH.

user@B:~$ ssh user@localhost -p 3333

Z hostem w sieci wewnętrznej łączymy się tak jak powyżej. Przełącznik -p wskazuje port ten sam który ustawiliśmy wcześniej.

Jeżeli przeszkadza nam ciągłe wpisywanie haseł możemy skorzystać z kluczy RSA. Wtedy możemy nawet dołączyć pierwsze polecenie do skryptów startowych hosta A.
Zagadnienie to nie jest zbyt skomplikowane ale na wszelki wypadek opiszę je w następnej notce.

Źródło: http://www.plenz.com/reverseshell