Cum să permiteți doar anumitor utilizatori să se conecteze la un server SSH de la o anumită interfață de rețea?
De ex.
- eth0 este „exterior”, eth1 este „interior”.
- Utilizatorul1 este autorizat să se conecteze de oriunde
- utilizatorului2 i se permite să se conecteze numai din „interior”.
Nu se poate utiliza AllowUsers [email protected] deoarece AllowUsers acceptă un nume de gazdă, nu un nume de interfață.
Alte răspunsuri de pe acest site sugerează ceva de genul:
Match address 1.2.3.4/16 # eth0's network
AllowUsers user1
Match address 2.3.4.5/16 # eth1's network
AllowUsers user1,user2
Match address 0.0.0.0/0 # Match's equivalent of a closing brace?
Cu toate acestea, dacă eth0 folosește un server DHCP pentru a-și obține adresa, atunci nu știe dinainte că 1.2.3.4 este adresa corectă pentru a o introduce în sshd_config.
(OpenSSH pe Ubuntu 12.04, dacă acest lucru face vreo diferență).
- De fapt, AllowUsers nici măcar nu este un lucru valid de pus în interiorul unui bloc Match, conform manualului lui sshd_config – > Por OJW.
Nu știu cum să fac acest lucru în cadrul unui bloc de Match bloc, iar comentariul dvs. de mai sus sugerează că nu este posibil (la fel ca și, după cum observați, și man pagina).
Dar dacă sunteți sigur că doriți să faceți restricția utilizatorului prin interfață – ceea ce întrebările dvs. spun că doriți – ați putea rula două sshds, fiecare având un sshd_config care îl direcționează să asculte doar pe o singură interfață, controlată de către ListenAddress directivă.
sshd care ascultă pe interfața internă ar putea avea în configurație AllowUsers user1 user2, , în timp ce cel care ascultă pe interfața externă ar putea avea AllowUsers user1. Probabil că aș face-o în funcție de apartenența la un grup și aș avea AllowGroups internal / AllowGroups internal external în schimb, dar asta e doar părerea mea.
Editați: imo, modul corect de a face acest lucru este să rulați /usr/sbin/sshd -f /etc/ssh/sshd_config_inside și /usr/sbin/sshd -f /etc/ssh/sshd_config_outside. Aranjarea modului în care acest lucru funcționează la pornire și asigurarea faptului că fișierele de pornire/oprire a serviciului dvs. fac ceea ce trebuie, este într-adevăr important, dar este, de asemenea, un lucru perfect normal pentru un administrator de sistem care trebuie să facă și să facă. Acesta este cu siguranță necesar să aveți două binare, sau chiar același binar cu două nume diferite, pentru a face acest lucru.
Comentarii
- Preocuparea mea aici este că instrucțiunile tipice pentru rularea a 2 x SSHD ar putea să vă lase cu un sistem în care una dintre instanțele SSH nu primește actualizări de securitate de la managerul de pachete al distribuției. – > .
- Nu ați înțeles ce vreau să spun. Nu două seturi de binare; un set de binare, două seturi de fișiere de configurare. Actualizări de securitate foarte rareori se ating de fișierele de configurare, nu în ultimul rând pentru că acestea tind să distrugă multe dintre personalizările oamenilor. – > .
- Mă uitam la fixunix.com/ssh/… care sugerează „ln -s /bin/othersshd /bin/sshd” ca și cum ar avea nevoie de două nume diferite pentru executabil – utilizarea aceluiași fișier real pare un început bun, dar actualizatorul ar putea face un „killall -s HUP sshd” sau „service restart sshd” și să rateze unul dintre ele. – > .
- @OJW Nu are niciun rost să folosiți un binar diferit sau chiar o legătură simbolică. Folosirea unui fișier de configurare diferit este partea importantă aici. – > .
- @OJW și asigurați-vă că aveți două scripturi init care să facă start/stop/status pentru această instanță specifică. Cele mai multe scripturi furnizate de sistemul de operare vor trebui modificate pentru a lua în considerare două instanțe diferite (și aveți nevoie de două dintre ele – desigur). Dacă trebuie să modificați scriptul sshd-init-script, faceți două copii și dezactivați-l pe cel original, deoarece acesta va fi modificat de sshd-updates (ceea ce ar distruge modificările dumneavoastră). – > .
Știu că este o întrebare veche, dar căutam o soluție fără a fi nevoie să pornesc 2 instanțe de sshd.
Referindu-mă la întrebarea dvs. specifică și la sub-rețeaua 1.2.3.4/16 și la sub-rețeaua 2.3.4.5/16, ați putea utiliza următoarele:
AllowUsers [email protected]* [email protected]* [email protected]*
Referință: http://www.unixlore.net/articles/five-minutes-to-even-more-secure-ssh.html
Pentru rețeaua mea, folosesc următoarele pentru a permite utilizatorului chris să facă ssh de oriunde, dar permit doar utilizatorului1, utilizatorului2 și utilizatorului3 să facă ssh în rețeaua mea internă (192.168.0.0/24):
AllowUsers chris [email protected]* [email protected]* [email protected]*
Versiunea: SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3 pe Ubuntu 14.04.3 LTS
Match address 1.2.3.4/16 nu este valid, trebuie să fie Match address 1.2.0.0/16. Adresele de rețea ale interfețelor nu se schimbă, nu-i așa? Deci nu contează ce IP primești.
O altă opțiune ar putea fi (nu am experiență personală în acest sens) să creați două interfețe virtuale cu o adresă statică, să aveți două instanțe sshd, fiecare legată doar la una dintre aceste adrese și să faceți DNAT de la interfața DHCP la cea virtuală.
Comentarii
- da, unele dintre adresele de rețea se pot schimba. de exemplu, un aparat care este preconfigurat astfel încât să poată fi conectat la orice rețea „exterioară” cu un server DHCP. – > .
- Nu mă refer la dispozitivele mutate. Interfața dvs. internă este conectată la un anumit server DHCP prin intermediul unui comutator, iar acest server DHCP oferă tuturor dispozitivelor o adresă de la 2.3.0.0/16, nu-i așa? Trebuie să vă fie teamă că interfața dvs. internă este 2.3.8.9 astăzi și va fi 1.2.8.9 mâine? Probabil că nu. Așadar, tot ceea ce se conectează de la 2.3.0.0/16 intră prin interfața internă. – > .
Poate că ați putea scrie un mic script pentru a obține adresa eth0 curentă (din ifconfig?) și pentru a o seta în sshd_config (folosind sed); dacă îmi amintesc corect, este posibil să scrieți scripturi de tip cârlig care să fie executate de fiecare dată când o interfață ethernet se oprește/se ridică (acest lucru ar putea rezolva necesitatea de a actualiza manual sau prin crontab fișierul sshd_config).
Comentarii
- Sau, există vreun motiv întemeiat pentru care nu puteți seta o adresă statică pe interfața „inside”? – > .
- chrskly ar putea fi pe linia corectă aici – o modalitate de a identifica rețeaua exterioară ar putea fi „o regulă care nu se potrivește cu niciuna dintre rețelele interioare cunoscute” – -. > .
Match Adress și Match User ar trebui să funcționeze și de câteva luni, de la OpenSSH 7.7, cel puțin dacă dăm crezare rapoartelor de erori aici puteți avea, de asemenea, meciuri negatoare.
Dacă doriți să vă blocați SSH cu sshd_config, , avertismentul este că ar trebui să dezactivați autentificările bazate pe parolă și pubkey pentru oricine altcineva.
De exemplu:
- permiteți accesul root numai din interior (192.168.1.0/24, pivind intervalul „office”).
- permiteți accesul unui utilizator special din VPN (10.10.10.10.0/24, intervalul privat „VPN”).
- permiteți numai accesul cu cheie publică pentru alți utilizatori neprivilegiați de oriunde, nu contează dacă este în interior, în exterior sau în VPN.
sshd_config
[...]
PasswordAuthentication no #
PubkeyAuthentication no # to disable access for all other users
[...]
Match Address 192.168.1.0/24
PermitRootLogin yes
PasswordAuthentication yes
PubkeyAuthentication yes
Match User vpnuser Address 10.10.10.0/24
PasswordAuthentication yes
PubkeyAuthentication yes
Match User sarah peter robert Address *
PasswordAuthentication no
PubkeyAuthentication yes
În acest fel, nu contează câte interfețe are serverul dvs. și ce adresă DHCP primesc acestea – contează de unde se conectează utilizatorii, ceea ce ar trebui să vă preocupe.
Răspunsul scurt: Nu puteți.
Răspunsul lung: Nu aveți voie.
Este doar un pseudo-avans în materie de securitate. Ar trebui să vă gândiți mai întâi la conceptul de securitate.
Dar, în interesul unei discuții profesionale, puteți cu hack-uri de doi bani:
- Așteptați până când veți obține IP-urile DHCP (Yikes! Nu aș face non-static pe un server).
- Configurați două sshd-uri diferite cu ListenAddress’es corespunzătoare, atribuind fiecăruia dintre ele un set diferit de utilizatori autorizați. (editare: A fost descris în celelalte răspunsuri de aici)
- Porniți cele două daemoni separate.