Numărul total de postări: 812
Buna ziua tovarășii, primul mesaj pentru care sa făcut înregistrarea pe acest forum sau pe insula minunată Unix juzverej. Problema este curiozitatea muncii IPTables în general. Există două mașini pe Deb8, virtuale, una dintre ele are acces direct, la cealaltă numai SSH. Scopul este de a închide toate porturile, cu excepția 22, 80, 160, 161, 443. Dar aici e freca: munca peste SSH, prin ea. Și din cauza acestei înfrângeri, nu puteți lăsa lanțurile, în caz contrar SSH dispare, precum și controlul asupra acesteia. Am observat un paradox (sau sunt prost): Când prescriu toata gama de port să scadă (INPUT ACCEPT lanț implicit), cu 444 prescriptii: 65535 - SSH cădea, și se întâmplă pe orice mașină. Deși portul 22 este deschis, dar SSH nu funcționează. Firește că mergem direct, ștergem ultima regulă - totul începe să funcționeze. Eliminăm regulile și facem același lucru, doar într-un sens ușor opus. Anume - lăsați lanțul și permiteți aceste porturi - funcționează SSH. Aici nu este clar modul în care se întâmplă acest lucru, care poate să-mi explice logica, în general, atunci când facem același lucru, doar în moduri diferite, și funcționează, așa cum sa dovedit în mod diferit. Sau poate că sunt prost și nu înțeleg nimic, am folosit recent Debian fără un GUI.
Vreau să am acces SSH la numărul 89.108.01.215 prin portul 22 și la 89.108.01.10 la 443. pentru că 443 portul de la 89.108.01.215 este deja utilizat https
Întrebarea este cum fac acest lucru, unde să săpat? Acest sprijin nu era în vigoare
există un server cu Debian 6, a fost instalat ssh. Setare minimă: PermitRootLogin nr. În plus față de rădăcină, pe server există doar un utilizator de 1 superroot. Încerc să intru pe server în sine, scrie
Permisiunea a fost respinsă, încercați din nou.
Dacă deschideți rădăcina, ssh root @ localhost sau de pe alt computer din rețeaua ssh -l din rețea
$ ssh superroot @ localhost
parola superroot @ localhost:
Permisiunea a fost respinsă, încercați din nou.
parola superroot @ localhost:
Permisiunea a fost respinsă, încercați din nou.
parola superroot @ localhost:
Permisiunea a fost refuzată (cheie publică, parolă).
Am instalat un nou sistem CentOS 7 pe server.
M-am dus sub rădăcină și am executat comenzile:
Creat de: # adduser stas # passwd stas # gpasswd -a stas roata
Editați fișierul / etc / ssh / sshd_config - la începutul fișierului adăugat trei linii: Port 1559 PermitRootLogin no AllowUsers stas
ssh -p 1559 [email protected]
ssh: conectați la gazdă 12.345.678.910 port 1559: Nici un traseu pentru a găzdui
ssh -p 22 [email protected]
ssh: conectați la gazdă 12.345.678.910 port 22: Conexiunea a fost refuzată
Conectez prin Putty, am configurat intrarea pe chei. Dar funcționează oarecum ciudat să se conecteze la server poate numai atunci când am pe server am introdus login-ul și parola de la utilizatorul meu, apoi mi-au permis să-l pe SSH. Dacă nu v-am conectat la sistem pe serverul propriu-zis, atunci când mă conectez la ssh (prin Putty), am o eroare: nu s-au conectat metode de autentificare acceptate (server sent publickey). Am o cheie privată pe server (cheia privată este adăugată pe pagină și, desigur, este în format Putty). Care e problema? Ajută-mă, spune-mi ce fișiere trebuie să oferiți pentru a mă ajuta să rezolv problema.
Punct important: există un singur utilizator pe tablă - rădăcină. Poate influențează cumva?
Am avut nevoie să configurez mountul SSH în numele utilizatorului curent, unde autentificarea pe serverul SSH se face folosind kerberos. Montarea în manual funcționează bine, dar nu am reușit să automatizez acest proces.
1. afuse) Folosesc metoda standard
Dacă contactați serverul
/sshfs/srv.local/, apoi, în principiu funcționează, dar dacă te duci la SSHFS folderul, apoi începe frânele sălbatice în bash și în X. bănuiesc că afuse încercarea de a monta un director non-existente, dar nu știu cum ostanovt .
2. systemd) Peste tot este descrisă fie montarea din rădăcină, fie folosind cheile, încă nu înțeleg dacă este posibil să se implementeze mount cu kerberos în acest sistem?
3. Poți mânca în alte moduri? Știu că există autofs, dar unii scriu că ssh conduce este mai bine să nu o monteze.
Sistem de operare: Debyan Jessie
Există un router, acesta formează o subrețea locală 192.168.0.1/24 Există mai multe mașini pe rețea, toate pe Linux. Uneori folosesc ssh pentru a controla o mașină pe cealaltă și nu există nici o problemă.
Dar pentru ssh, trebuie să cunoașteți com-ul IP, deoarece ssh nu înțelege numele gazdei dacă nu există în / etc / hosts. Deoarece este un router, este dinamic IP.
afișează numai rețelele IP active în rețea și
de asemenea, nu ajută, chiar de la rădăcină
Acum mă uit la adresa IP și numele de gazdă din panoul de administrare al routerului, ceea ce nu este foarte convenabil. Desigur, pot să le dau tuturor o IP statică și apoi să configureze / etc / hosts, dar este un fel de cârjă.
Aveți nevoie de o comandă care afișează o listă a tuturor IP-urilor active pe subrețeaua 192.168.0.1/24 și numele de gazdă. Google a încercat acest lucru, dar confundă numele de gazdă c netbios, și o parte din comenzile de sub Windows, și fără a specifica acest lucru.
Articole similare
Trimiteți-le prietenilor: