Witam,

Moje pytanie dotyczy skryptów uniksowych, więc gdzieniegdzie będę odnosił
się do cech tego systemu.
Otóż, mam potrzebę przebudowania istniejącego skryptu (załóżmy jego nazwę
*working*) służącego do logowania na urządzenia i wykonywania na nich
określonych operacji, w taki sposób, by wyrzucić na zewnątrz dane
uwierzytelniające (login i hasło) do urządzeń.
Pomysł jest taki, by napisać dodatkowy skrypt/program serwisowy (nazwijmy go
*credit*), który dostarczałby danych uwierzytelniających dla skryptu
*working*. Docelowo przydatny byłby również dla innych moich skryptów.
Działanie skryptu *credit* byłoby następujące:
- przy pierwszym uruchomieniu skrypt pyta o login i hasło do urządzeń,
- zapamiętuje te dane i w jakiś sposób udostępnia na zewnątrz,
- po zadanym czasie (np. 2 godz.) dane uwierzytelniające deaktualizują się i
skrypt ponownie pyta o ich wprowadzenie przez użytkownika [chodzi o sytuację
pozostawienia stacji roboczej nie zablokowanej i ograniczenie możliwości
wykorzystania danych zalogowanego użytkownika - hasło nie zmienia się z taką
częstotliwością :) ].
Uruchomienie skryptu working powoduje "odpytanie" skryptu credit o dane
logowania jakich ma użyć i w razie potrzeby (przedawnienie danych) credit
odpytuje użytkownika o dane.

I teraz moje pytania:
W jaki sposób zrealizować przekazywanie danych uwierzytelniających pomiędzy
skryptami credit i working (a docelowo również innymi)?
Myślałem o zapisaniu danych w pliku z maksymalnie ograniczonymi prawami =
400; czas modyfikacji pliku posłużyłby do ustalenia przedawnienia danych.
Inna metoda - zapis danych w zmiennych środowiskowych użytkownika (login,
hasło i dodatkowo timestamp do ustalenia przedawnienia danych).
Obie metody zapisu danych można by ulepszyć poprzez zakodowanie danych, ale
trzeba by zastosować dodatkowo jakiś klucz, czyli użytkownik musiałby
podawać dodatkowo ten klucz i co gorsza przy każdym uruchomieniu skryptu
working (tak by credit mógł odkodować zakodowane dane i przekazać do skryptu
working), więc raczej odpada. Zastosowanie jakiegoś "sobie znanego
algorytmu" bez potrzeby podawania klucza też mija się z celem, bo wystarczy
analiza skryptu.

Chciałbym uniknąć podawania w skrypcie roboczym nazwy pliku / zmiennych
środowiskowych do odczytania danych logowania lecz zastosować jakiś
interfejs wymiany danych, który zapewniłby aktualność danych logowania.
Czyli w skrypcie working powinno być odwołanie do credit, który ostatecznie
zwraca dane logowania. Inaczej credit czuwa nad aktualizacją danych
logowania i ich dostarczeniem do programów z nich korzystających.
W jaki sposób zrealizować taki interfejs? Może na zasadzie, że credit działa
jako daemon i jest odpytywany o dane logowania przez inne skrypty? W jaki
sposób podejść do problemu?

PS. Język programowania dowolny, ale najchętniej coś skryptowego: Perl, Tcl,
Bash, itp.

--
Szczepan J. Fijał :: sjf @ 50°07'N 18°58'E
xmpp:s...@j...pl | tlen:sjf | gg:2604451 | skype:s.fijal?call
"Linux is like Wigwam. No gates, no windows... Apache inside ;-)"

do góry

On 08/02/2010 10:20 PM, ..:: sjf ::.. wrote:
> Witam,
>
> Moje pytanie dotyczy skryptów uniksowych, więc gdzieniegdzie będę
> odnosił się do cech tego systemu.
> ...

A myślałeś o użyciu ssh i zapisaniu kluczy urządzeń na komputerze,
z którego będą wołane skrypty?

do góry

Użytkownik "Segmentation Fault" <c...@o...eu> napisał w
wiadomości grup dyskusyjnych:4c58038b$0$2603$6...@n...neostrada
.pl...
> On 08/02/2010 10:20 PM, ..:: sjf ::.. wrote:
>> Witam,
>>
>> Moje pytanie dotyczy skryptów uniksowych, więc gdzieniegdzie będę
>> odnosił się do cech tego systemu.
>> ...
>
> A myślałeś o użyciu ssh i zapisaniu kluczy urządzeń na komputerze,
> z którego będą wołane skrypty?
Tak, to mogłoby być rozwiązanie gdyby nie to, że do urządzeń mogę się
zalogować jedynie przez telnet.
Aha, problem podejrzenia haseł sniferem można pominąć gdyż chodzi o
wydzieloną sieć zarządzania, wejście do serwerowni jest naprawdę trudne.
Ja tak naprawdę nie pytam o sposób zabezpieczenia/szyfrowania/etc. danych
logowania lecz o to jak sensownie rozwiązać komunikację między programami.
Czy coś na zasadzie klient-serwer czy inaczej?

--
Szczepan J. Fijał :: sjf @ 50°07'N 18°58'E
xmpp:s...@j...pl | tlen:sjf | gg:2604451 | skype:s.fijal?call
"Linux is like Wigwam. No gates, no windows... Apache inside ;-)"

do góry

Hej,


On 3 Sie, 19:19, "..:: sjf ::.." <s...@u...org.invalid> wrote:
> Użytkownik "Segmentation Fault" <c...@o...eu> napisał w
> wiadomości grup dyskusyjnych:4c58038b$0$2603$6...@n...neostrada
.pl...> On 08/02/2010 10:20 PM, ..:: sjf ::.. wrote:
> >> Witam,
>
> >> Moje pytanie dotyczy skryptów uniksowych, więc gdzieniegdzie będę
> >> odnosił się do cech tego systemu.
> >> ...
>
> > A myślałeś o użyciu ssh i zapisaniu kluczy urządzeń na komputerze,
> > z którego będą wołane skrypty?
>
> Tak, to mogłoby być rozwiązanie gdyby nie to, że do urządzeń mogę się
> zalogować jedynie przez telnet.
> Aha, problem podejrzenia haseł sniferem można pominąć gdyż chodzi o
> wydzieloną sieć zarządzania, wejście do serwerowni jest naprawdę trudne.
> Ja tak naprawdę nie pytam o sposób zabezpieczenia/szyfrowania/etc. danych
> logowania lecz o to jak sensownie rozwiązać komunikację między programami.
> Czy coś na zasadzie klient-serwer czy inaczej?
>

Jakie jezyki skryptowe sa dostepne? Shell, Cshell, Bash, Perl, Python?

Pozdrawiam
Darek

do góry

Użytkownik "Darek" <d...@g...com> napisał w wiadomości grup
dyskusyjnych:140730d2-47da-41b9-b890-8e8e0995ddc4@z1
0g2000yqb.googlegroups.com...
> Hej,
>
>
> On 3 Sie, 19:19, "..:: sjf ::.." <s...@u...org.invalid> wrote:
>> Użytkownik "Segmentation Fault" <c...@o...eu> napisał w
>> wiadomości grup
>> dyskusyjnych:4c58038b$0$2603$6...@n...neostrada
.pl...> On 08/02/2010
>> 10:20 PM, ..:: sjf ::.. wrote:
>> >> Witam,
>>
>> >> Moje pytanie dotyczy skryptów uniksowych, więc gdzieniegdzie będę
>> >> odnosił się do cech tego systemu.
>> >> ...
>>
>> > A myślałeś o użyciu ssh i zapisaniu kluczy urządzeń na komputerze,
>> > z którego będą wołane skrypty?
>>
>> Tak, to mogłoby być rozwiązanie gdyby nie to, że do urządzeń mogę się
>> zalogować jedynie przez telnet.
>> Aha, problem podejrzenia haseł sniferem można pominąć gdyż chodzi o
>> wydzieloną sieć zarządzania, wejście do serwerowni jest naprawdę trudne.
>> Ja tak naprawdę nie pytam o sposób zabezpieczenia/szyfrowania/etc. danych
>> logowania lecz o to jak sensownie rozwiązać komunikację między
>> programami.
>> Czy coś na zasadzie klient-serwer czy inaczej?
>>
>
> Jakie jezyki skryptowe sa dostepne? Shell, Cshell, Bash, Perl, Python?
Na pewno Shell (sh), Bash, CShell (csh), Perl, Python, Tcl.

do góry

On 08/03/2010 07:19 PM, ..:: sjf ::.. wrote:
> Użytkownik "Segmentation Fault" <c...@o...eu> napisał w
> wiadomości grup dyskusyjnych:4c58038b$0$2603$6...@n...neostrada
.pl...
>> On 08/02/2010 10:20 PM, ..:: sjf ::.. wrote:
>>> Witam,
>>>
>>> Moje pytanie dotyczy skryptów uniksowych, więc gdzieniegdzie będę
>>> odnosił się do cech tego systemu.
>>> ...
>>
>> A myślałeś o użyciu ssh i zapisaniu kluczy urządzeń na komputerze,
>> z którego będą wołane skrypty?
> Tak, to mogłoby być rozwiązanie gdyby nie to, że do urządzeń mogę się
> zalogować jedynie przez telnet.
> Aha, problem podejrzenia haseł sniferem można pominąć gdyż chodzi o
> wydzieloną sieć zarządzania, wejście do serwerowni jest naprawdę trudne.
> Ja tak naprawdę nie pytam o sposób zabezpieczenia/szyfrowania/etc.
> danych logowania lecz o to jak sensownie rozwiązać komunikację między
> programami. Czy coś na zasadzie klient-serwer czy inaczej?
>

Rozumiem że to jest rozwiązanie na jeden komputer ( a nie np. paczka
ubuntu), dla komputera, do którego niepowołane osoby nie mają dostępu?

W takim razie bym nie kombinował i zrobił tak jak to opisałeś z plikiem
włączanym do skryptu. I rozbudował jeśli kiedyś będzie taka potrzeba ;)

do góry