Powiedzcie mi czy to jest błąd?
Mam dwa serwery, w obu takie same procesory, podobne płyty główne i ilość RAM.
Różnica polega na wersji Debiana - w jednym jest 32-bit, w drugim 64-bit.
Na obu zainstalowane wszystkie możliwe aktualizacje (system instalowany na podstawowych pakietach więc żadnych X-ów, tylko to co niezbędne).
Problem pojawia się po edycji /etc/ssh/sshd_conf.
Na 32-bitowej wersji po otwarciu w iptables portu dla przykładu 2345 i restarcie firewalla oraz serwisu ssh wszystko śmiga. Mogę podłączyć się do serwera lokalnie jak i zdalnie na tym porcie.
Natomiast w przypadku wersji 64-bitowej nie mogę połączyć się zdalnie (connection refused), a lokalnie owszem. Odkryłem, że dzieje się to na dowolnym 4-cyfrowym porcie. Gdy zmieniłem go na 18 to dopiero zaczęło działać.
W czym tkwi problem? Mnie to wygląda na jakiś błąd w SSH lub IPTABLES w wersji 64-bit, bo robiłem wszystko identycznie na obu serwerach (i to zdalnie). Tylko do tego drugiego później nie mogłem się już podłączyć.
Debian 4.0 Etch,
2.6.18-6-amd64 kernel,
iptables v1.3.6
iptables + Etch i kernel 2.6.18-6-amd64 - czy to b
a próbowałeś potem wejść przez standardowy port ? może zmiany się nie zapisały. No i może iptables jakoś nie przepuszcza tego ? A na koniec jest jeszcze plik /etc/hosts.allow i deny ale to tak tylko teoretycznie bo według opisu nie były one modyfikowane.
Na Twoim miejscu bym przebugował problem. Zmień najpierw port używany przez ssh i ustaw iptables aby wszystko przepuszczał. Będziesz wiedział czy problem leży po stronie ssh czy iptables. PS: upewnij się że ssh w ogóle się podnosi po zmianie konfiguracji bo może jakiś krzaczek przez pomyłke wprowadziłeś.
Pozdrawiam
Na Twoim miejscu bym przebugował problem. Zmień najpierw port używany przez ssh i ustaw iptables aby wszystko przepuszczał. Będziesz wiedział czy problem leży po stronie ssh czy iptables. PS: upewnij się że ssh w ogóle się podnosi po zmianie konfiguracji bo może jakiś krzaczek przez pomyłke wprowadziłeś.
Pozdrawiam
Więc tak: gdy zmieniłem z powrotem na standardowy port SSH już nie działało, lokalnie owszem ale nie przez internet. Czyściłem regułki IPTABLES żeby wpuścić cały ruch i też nie działało (tylko lokalnie).
Adres publiczny przydzielony od dostawcy - jeden z pięciu od DSL.
- podaje mi że SSH chodzi, dziwne jest to że nawet próbując np. z innego komputera nie da się podłączyć do serwera choć port jest otwarty i Exim chodzi.
Podobnie wydane na serwerze nie chciał mi nic wyświetlić. Tak jakby wszystkie porty zostały zablokowane przez IPTABLES. A ponieważ wcześniej wszystko było dobrze i nic nie zmieniałem w firewallu oprócz tego portu to mnie to mocno zdziwiło. Na 32-bitowej wersji wszystko jest poprawnie. W 64-bitowej po zmianie portu SSH na 18 działa, a wcześniej gdy miałem ustawione dla SSH 2345 serwer był martwy i zdalnie w ogóle nie odpowiadał.
Firewall wzorowany na:
http://www.debian.org/doc/manuals/secur ... es.en.html
Adres publiczny przydzielony od dostawcy - jeden z pięciu od DSL.
Kod: Zaznacz cały
ps -A | grep sshKod: Zaznacz cały
telnet 192.168.1.1 25Podobnie
Kod: Zaznacz cały
nmap -A localhostFirewall wzorowany na:
http://www.debian.org/doc/manuals/secur ... es.en.html
to wrzuć nam jeszcze:
Kod: Zaznacz cały
iptables -t nat -LKod: Zaznacz cały
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere host.internetdsl.tpnet.pl tcp dpt:3389 to:192.168.0.59:3389
DNAT tcp -- anywhere host.internetdsl.tpnet.pl tcp dpt:5000 to:192.168.0.59:5000
DNAT tcp -- anywhere anywhere tcp dpt:www to:192.168.0.58:8080
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
192.168.0.58 - to adres mojego serwera w sieci LAN, chodzi na nim SQUID, jak widać.
192.168.0.59 - to jeden z komputerów, na który zrobiłem sobie przekierowanie.
Kolega zarządzający bramką powiedział, że wszystkie porty na mój adres są przekierowane z jednego z 5 dostępnych adresów publicznych jemu przydzielonych i faktycznie to działało do czasu aż zacząłem zmieniać port dla SSH.