Freesco, NND, CDN, EOS

Chciałem zdalnie administrować router NND. Po lekturze forum zainstalowałem nową paczkę openssh 4.3p2-2nnd, odblokowałem ssh w rc.config i restart.
Efekt po uruchomieniu putty "Server unexpectedly closed network connection".
W logu auth mam

_________________
Z wyrazami szacunku.
Cesik

to zainstaluj jeszcze nowa paczke openssl tylko nie rozumiem poco instalowales nowe wersje paczek??

Jak już wspomniałem najpierw czytałem wszystko na ten temat. W jednym z postów rozwiązanie problemu było zainstalowanie nowej paczki openssh.

_________________
Z wyrazami szacunku.
Cesik

Zaktualizowałem openssl do 0.9.8-4 i nadal jest taki sam objaw.

_________________
Z wyrazami szacunku.
Cesik

Problem rozwiązałem. Diabeł tkwił w kompatybilności pakietów.
Poprawne działanie zdalnej administracji zapewnia następująca konfiguracja :

openssl-0.9.8-4
openssh-4.2p1-1
proftpd-1.3.0-1

_________________
Z wyrazami szacunku.
Cesik

hmm a co ma z tym wspolnego proftpd??

Bo przy nowych paczkach stary proftpd chyba nie działa z tego co pamiętam

no oki ale kolegal pisal o SSH a nie o proftpd, zresztat temat topicu jest ssh

Oboje macie racę.
Dla potomnych dopisałem paczkę proftpd ponieważ po instalacji ssh serwer ftp przestał działać i tylko mojej dociekliwości powiązałem ten fakt z paczką ssh.
W przyszłości będę pisał temat ogólniej.

_________________
Z wyrazami szacunku.
Cesik

Ja rowniez mam problemy.
1.Pakiety ssl 0.9.8-5; SSH 4.3p2 (chyba najnowsze)
Proba polaczenia konczy sie komunikatem: "serwer unexpectedly closed network connection". W logach auth: "refused connection..."
2.Pakiety ssl 0.9.7e; ssh 4.1pl
Proba polaczenia konczy sie odrzuceniem kluczy: "Server refused our key". Nastepuje logowanie po autoryzacji uzytkownikiem i haslem. W logu "Accepted password for XXX from 192... port 1449 ssh2"
3.Pakiety ssl 0.9.8-4; ssh 4.1pl

Proba polaczenia konczy sie odrzuceniem kluczy: "Server refused our key". Nastepuje logowanie po autoryzacji uzytkownikiem i haslem. W logu "Accepted password for XXX from 192... port 1556 ssh2"

Klucze generowane kilka razy, za chwle sprobuje kolejny raz (zreszta mam to przecwiczone na Freesco 2.7, na ktorym kluczyki dzialaly ladnie.

Zrobilem eksperyment: Wywalilem pliki authorization_keys i... objaw jest identyczny co przedtem - czyli:
"Server refused our key". Nastepuje logowanie po autoryzacji uzytkownikiem i haslem. W logu "Accepted password for XXX from 192... port 1556 ssh2"

Oczywiscie odpowiednie pisy w sshd_config sa:

_________________
Tomek

Mialem problemy, po 2 dniach walki ZWYCIEZTWO.
Moze komus to pomoze.
Okazalo sie, ze klucze pub sa pobierane z pliku
/home/xxx/.ssh/authorized_keys (xxx - nazwa usera) a nie z pliku
/etc/ssh/authorized_keys

Na koncie 'xxx' tworze plik /home/xxx/.ssh/authorized_keys
(aby byc pewnym, ze sa nadane odpowiednie prawa do pliku i katalogu wykonuje polecenie ssh-keygen -t rsa ktore tworzy 2 pliki: id_rsa (klucz prywatny, ktory kasuje) oraz id_rsa.pub, do ktorego wkleja zawartosc mojego klucz prywatnego i zmieniam mu nazwe na authorized_keys).

Po tej operacji nastepuje autoryzacja kluczem, wylaczam wiec autoryzacje kontem uzytkownika, w sshd_config:
PasswordAuthentication no

_________________
Tomek

No tak od zawsze klucze były w katalogach domowych userów
Ale dlaczego klucz prywatny w pliku id_rsa.pub?? pub to chyba skrót od public(publiczny) czyli możesz go rozdać serwerom gdzie się logujesz. A prywatny sobie zostawiasz na kompie z którego się łączysz.

_________________
Ten post Ci pomógł? Zaznacz go jako pomocny .

No dobra zle to opisalem - chodzilo mi o to, zeby zapisac w utworzonym pliku, gdyz bedze on mial odpowiednie uprawnienia, ale oczywiscie nie trzeba tych kluczy tworzyc, mozna recznie utworzyc katalog w nim authorized_keys, tam wkleic wygenerowany klucz publiczny i nadac plikowi odpowiednie prawa.

_________________
Tomek