Znalezienie poniższych informacji nie jest banalnie proste (choć też nie jakoś niesamowicie skomplikowane), więc po własnych owocnych poszukiwaniach postanowiłem napisać mały poradnik (może komuś się kiedyś przyda ).

Założenia:
- w jednej sieci LAN są (co najmniej) dwa routery pracujące pod kontrolą OpenWRT (router A (z którego chcemy się łączyć) 192.168.1.1 i router B (na który chcemy się łączyć) 192.168.1.2)
- chcemy mieć możliwość łączenia się pomiędzy nimi po ssh bez konieczności podawania hasła (np w celu wykorzystania tego w skryptach, lub dla zwykłej wygody)
- klucze przechowujemy w katalogu /etc/dropbear/ (niech ktoś napisze, jeżeli konwencje w tej kwestii są inne)

Niby w sieci jest pełno poradników jak to zrobić ale zdecydowana większość z nich zakłada posiadanie na maszynie klienckiej openSSH (lub czegoś posiadającego polecenie ssh-keygen), a pod OpenWRT domyślnie jest dropbear (owszem, można zmienić, tylko po co?).
Nawet na wiki OpenWRT znalazłem tylko informacje o logowaniu się bez hasła na router.

Do rzeczy.

1. Generowanie kluczy (router A)

Do wygenerowania kluczy służy polecenie dropbearkey. Można się nim posłużyć np w następujący sposób:Otrzymujemy klucz prywatny (key.priv), który należy trzymać w tajemnicy, oraz publiczny (key.pub), który trzeba przekazać maszynie, na którą chcemy się logować.

Skopiowanie klucza publicznego na drugi router można wykonać poleceniem (tym razem jeszcze trzeba podać hasło ):
2. Dodawanie autoryzowanych kluczy publicznych (router B)

Skopiowany do /tmp klucz publiczny routera A należy dodać do listy kluczy autoryzowanych (druga linijka nie jest konieczna przy dodawaniu kolejnych kluczy):
3. Logowanie przy pomocy klucza (router A)

dropbear wymaga każdorazowego wyspecyfikowania, że chcemy połączyć się używając wygenerowanego klucza. Służy do tego opcja -i:Jeżeli nie chcemy podawać tego za każdym razem, możemy zrobić sobie alias:Można też sprawić, by zawsze tworzył się automatycznie (ponownie - nie znam konwencji - jeśli nie jest to dobre miejsce na aliasy, niech ktoś podpowie lepsze):Po tej operacji wystarczy zwykłeTo samo można zrobić np dla scp.


Oczywiście nic nie stoi na przeszkodzie by skonfigurować takie połączenia także w drugą stronę (z routera B na router A), lub dla większej ilości maszyn (na każdej klucze generujemy tylko raz, za to kopiujemy je (i dodajemy do listy autoryzowanych) na wszystkie, na które chcemy się logować).

I to właściwie tyle (prawda, ze proste?).
Wszelkie uwagi i sugestie mile widziane.

----- Dodano ----- 11 maja 2011, o 23:51 -----

4. SSH wywoływane automatycznie

Wszystko działa ładnie, gdy ssh (lub skrypt je zawierający) wywoływane jest "ręcznie" z linii poleceń. Jednak gdy chcemy, by wywołanie nastąpiło automatycznie (start routera, cron, zdarzenie hotplug, plugin exec z lcd4linux, itp) mogą pojawić się problemy.

4a. Plik /root/.ssh/known_hosts i zmienna $HOME
ssh szuka identyfikatorów znanych hostów w pliku $HOME/.ssh/known_hosts. Gdy logujemy się na router, zmienna $HOME zostaje ustawiona tak, jak jest to zapisane w pliku /etc/passwd (np "/root" dla użytkownika root). cron robi to samo przed uruchomieniem poleceń, ale np hotplug już nie (zawartość tej zmiennej jest ustawiona na "/"). Powoduje to, że ssh szuka hostów w pliku /.ssh/known_hosts (a nie w /root/.ssh/known_hosts gdzie zostały zapisane hosty zatwierdzone przez użytkownika w trybie interaktywnym), nie znajduje ich i rozłącza połączenie.
Można temu zapobiec na kilka sposobów:
- ustawiając zmienną $HOME na odpowiednią wartość przed wywołaniem ssh
- tworząc link /.ssh/known_hosts wskazujący na plik /root/.ssh/known_hosts (lub na odwrót)
- dodając do polecenia ssh opcję -y (zezwala na połączenie, gdy host jest nieznany)

Ta ostatnia opcja może być nieco niebezpieczna, ale też może się przydać, gdy chcemy się łączyć z hostami, których nie zatwierdziliśmy wcześniej (z lenistwa, lub braku możliwości) w trybie interaktywnym.

4b. stdout i stderr
Rozwiązanie tego problemu zajęło mi więcej czasu i szczerze mówiąc nadal nie do końca rozumiem przyczynę. Ale skoro się udało, to może ktoś z tego skorzysta.
Jeżeli chcemy tylko wykonać komendę na zdalnym rządzeniu, nie ma problemu, np:(komenda wykona się - zostanie utworzony plik)

Jeżeli jednak interesuje nas to, co dana komenda zwraca (na standardowe wyjście, lub na wyjście błędów), sprawa robi się nieco bardziej skomplikowana.
Np. polecenie:spowoduje utworzenie pustego pliku (0 bajtów).

Jak nadmieniłem, nie do końca rozumiem przyczynę (ale ponoć ma to coś wspólnego z tym, że ssh wywołane w ten sposób przekierowuje swoje wejście, co powoduje też przekierowanie wyjść).
W przypadku "pełnego" ssh podobno wystarczy dodanie opcji -n (zakaz przekierowywania), ale dropbear, jako klient, nie posiada jej.
Rozwiązaniem jest ręczne przekierowanie wejścia np na /dev/zero (z /dev/null nie dizała): Teraz już dostaniemy zarówno stdout, jak i stderr ze zdalnie wykonanej komendy.

Jest to jedyny sposób, jaki znalazłem (np proba wymuszenia emulacji pty, poprzez wielokrotną opcję -t nie pomaga) i, choć może nie najbardziej elegancki, to jednak skuteczny.

Jak zwykle chętnie przyjmę wszelkie uwagi, pomysły i opinie.

Pewnie że proste . Główna różnica to taka, że dropbear szuka kluczy w innym miejscu (/etc/dropbear), nie .ssh jak to zwykle ma miejsce.

dodaj do tematu [howto], łatwiej będzie szukać i późniejszym czasie nam sortować takie posty. Dzięki.

Witam
jak powinno wyglądać polecenie do skopiowania pliku tmp/test.txt


coś takiego ?

/usr/bin/ssh -i /etc/dropbear/key.priv root@192.168.1.99 "/tmp/test.txt > /tmp/test.txt "

Skopiowania skąd?

z routera (192.168.1.1 tmp/test.txt) na którym zostanie wykonany skrypt
lub polecenie z crona chce wysłać plik lub jego zawartość do routera (192.168.1.99 tmp/test.txt)

lub odwrotnie wykonać skrypt na 192.168.1.99 odczytujący zawartość pliku test.txt w katalogu tmp na routerze 192.168.1.1

scp /tmp/test.txt root@192.168.1.99:/tmp/test.txt
scp root@192.168.1.99:/tmp/test.txt /tmp/test.txt

?

ale to wymaga podania hasła

Czemu nie podałeś -i /etc/dropbear/key.priv?

bo:
/usr/bin/ssh -i /etc/dropbear/key.priv root@192.168.1.99:/tmp/test.txt /tmp/test.txt

zgłasza:
/usr/bin/ssh: Exited: Error resolving '192.168.1.99:' port 'tmp/test.txt'. Servname not supported for ai_socktype

a z kolei
/usr/bin/ssh -i /etc/dropbear/key.priv scp root@192.168.1.99:/tmp/test.txt /tmp/test.txt
daje:
/usr/bin/ssh: Exited: Error resolving 'scp' port '22'. Name or service not known


i nie bardzo wiem co jest nie tak

Serio?

scp -i /etc/dropbear/key.priv /tmp/test.txt root@192.168.1.99:/tmp/test.txt

scp to jest oddzielne polecenie.

Dzięki wszystko działa

Tutorial spoko, normalne SSH z crona przy mojej konfiguracji działa, tylko jest jeden problem. Gdy tylko dodaję do linijki w cronie przełącznik -t (zakładam że wtedy serwer docelowy zanotuje zalogowanie się, a nie zignoruje taką sesję jak w przypadku -T czy braku przełącznika), to przestaje. Próbowałem przerzucać stdin z /dev/zero, a stderr na stdout i potem oba na lokalny plik, celem zdiagnozowania, ale ten ostatni jest pusty. Ktoś coś?

OpenWrt 21.02-SNAPSHOT, r16263-4003eeab35

ssh z crona? Tzn co właściwie robisz?

Próbuję zalogować się raz dziennie na serwer i wykazać aktywność.

Przełącznik -T mi takiej możliwości nie daje, choć polecenie wykonywane jest bez problemów (więc klucz publiczny jest czytany, polecenia są wykonywane i ich wynik jest OK). Z kolei wymuszenie sesji interaktywnej parametrem -t w ogóle nie jest wykonywane poprawnie, tzn. nie dochodzi nawet do połączenia SSH - nie jestem jednak w stanie stwierdzić co jest nie tak.

Dodam, że wykonuję operację z użytkownika innego niż root, jeśli to coś zmienia.

Polecenie, którego używam w cronie:

Nie wiem co robiłeś, ale to działa tak po prostu. Z crona w OpenWrt:

10.1.1.1 jest zwykłym debianem, tworzy się plik i normalnie odkłada w nim podany tekst. Bez żadnego kombinowania.

Tak, taka konstrukcja działa. Ale jeśli dodam przełącznik -t do polecenia (tak jak wskazałem wyżej), to już plik nie jest uzupełniany. Dodam, że w miejscu 'INTERACTIVE SHELL TEST' wcześniej był zestaw poleceń lokalnie generujących bieżący czas, nazwę hosta i adres IP interfejsu WAN - i bez przełącznika -t (albo z -T) każda taka konfiguracja działa, ale nie wykazuje wtedy aktywności, tj. docelowy system operacyjny nie uwzględnia tego logowania w swojej historii. Dlatego chciałem posłużyć się parametrem -t, ale wówczas żadne polecenie nie jest wykonywane po stronie zdalnej. Próba przekierowania wejścia z /dev/zero i wyjścia/błędów na plik lokalny generuje pusty plik (bądź nic nie dopisuje). System docelowy w moim przypadku to FreeBSD 12.2, powłoką po zalogowaniu jest bash.

Generalnie chciałbym logować się na koncie, na którym trzymam swoje rzeczy, ale nielogowanie się na nim przez jakiś czas powoduje blokadę i późniejsze usunięcie go, bo traktowane jest to tak jakby nie było używane. A że ja go używam ostatnio dość często, tylko nie od strony SSH, i obawiam się że mogę czasem zapomnieć się zalogować, to wolałbym to robić z automatu, z miejsca które kontroluję i mam pod ręką. Jeśli kiedyś okaże się że ten automat już nie działa, to będzie najpewniej równoznaczne z tym, że już tego konta nie potrzebuję, i wtedy słusznie nie będzie do niego dostępu.

A zamiast tych poleceń jak wykonasz skrypt który wykonuje te polecenia?

Mam taki wpis w /etc/crontabs/koz (zmienione nazwy i godziny, ale reszta taka sama) - nie działa:


Ale jeśli usunę z niego -t, to jest teoretycznie OK, tylko system zdalny nie uwzględnia tego jako logowanie - ergo: nie przedłuża mi czasu aktywności konta. Wariant z -t działa z wiersza poleceń OpenWrt.

//edit: Inna sprawa, że dzięki takim poleceniom mogę np. wykonywać jakieś backupy na dysku podłączonym do rutera, tylko wolałbym żeby to się odbywało właśnie z uwzględnieniem logowania w historii. Pamiętam że kiedyś mi to działało, nie mam niestety już tamtego polecenia.