Puncte:0

SSH funcționează prin IP, dar după nume

drapel rs

Context general:

Am un server cu mai multe containere LXD și având un HAPROXY deasupra pentru a redirecționa traficul către un container bun în ceea ce privește adresa URL dată.

Containerul ascuțit este gitlab.

Serverul principal

Portul 22 este deschis

server# iptables -L -n |grep 22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22

server# netstat -plnt | grep 22
tcp 0 0 0.0.0.0:22 0.0.0.0:* ASCULTĂ 2536/sshd           
tcp6 0 0 :::22 :::* ASCULTĂ 2536/sshd  

Configurarea serverului Gitlab

gitlab# cat /etc/hosts
127.0.0.1 gitlab.pub-domain.com gitlab
127.0.0.1 localhost
127.0.1.1 s-302-gitlab # nume mașină
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

gitlab# cat /etc/resolv.conf 
caută pub-domain.com
caută priv-domain.ovh
server de nume 8.8.8.8

# netstat -tulpn | grep 22
tcp 0 0 127.0.0.1:9229 0.0.0.0:* ASCULTĂ 583/gitlab-workhors 
tcp 0 0 0.0.0.0:22 0.0.0.0:* ASCULTĂ 5094/sshd           
tcp6 0 0 :::22 :::* ASCULTĂ 5094/ssh

Ping totul

Lansat în containere gitlab și lucrări:

gitlab# # ssh -T https://[email protected]
Parola https://[email protected]:
gitlab# ssh -T https://[email protected]
Parola lui https://[email protected]:

Acum mergeți la o altă mașină (să spunem un server pentru a face totul simplu) și faceți ping:

server# ping pub-domain.com
PING pub-domain.com (31.7.xx.yy) 56(84) octeți de date.
64 de octeți de la 31.7.xx.yy (31.7.xx.yy): icmp_seq=1 ttl=64 time=0,588 ms
--- statistici ping pub-domain.com ---
1 pachet transmis, 1 primit, 0% pierdere de pachete, timp 0 ms

server# ping gitlab.pub-domain.com
PING pub-domain.com (31.7.xx.yy) 56(84) octeți de date.
64 de octeți de la 31.7.xx.yy (31.7.xx.yy): icmp_seq=1 ttl=64 time=0,588 ms
--- statistici ping pub-domain.com ---
1 pachet transmis, 1 primit, 0% pierdere de pachete, timp 0 ms

SSH

server# ssh git@s-302-gitlab
ssh: conectați-vă la gazda s-302-gitlab portul 22: conexiune refuzată
server# ssh -T https://[email protected]
ssh: conectează-te la portul 22 de gazdă gitlab.pub-domain.com: conexiune refuzată
server# ssh -T [email protected]
Autenticitatea gazdei „192.168.3.200 (192.168.3.200)” nu poate fi stabilită.
Amprenta cheii ECDSA este SHA256:Pe2vY/8GyG3o6ZkDErTN8Ko+k9veJA9S4wnHvQXSYJk.
Sigur doriți să continuați conectarea (da/nu)? 

Aveți idee de ce mă pot conecta numai folosind IP și nu domeniul/URL-ul?

Răspunzând la comentarii

# dig +scurt s-302-gitlab
# dig +scurt gitlab.pub-domain.com
pub-domain.com.
31.7.xx.aa

Mulțumiri,

digijay avatar
drapel mx
Pe `server`, care este rezultatul lui `dig +short s-302-gitlab`? Încercați același lucru pentru `gitlab.pub-domain.com`.
drapel rs
@digijay: primul nimic, al doilea domeniu pub și IP extern. Vezi editarea mea în postarea originală.
anx avatar
drapel fr
anx
Adăugați opțiunea `-v` la apelul dvs. ssh de mai multe ori pentru a crește gradul de verbozitate. Apoi ssh va spune, mai precis, ce conexiune a fost refuzată. Apropo, numele dvs. de utilizator este probabil o greșeală. De obicei, `https://` ar desemna o conexiune care folosește HTTP, în timp ce numele de utilizator ssh, în general, nu conțin bare oblice sau două puncte.
Michael Hampton avatar
drapel cz
`s-302-gitlab` este definit în fișierul dvs. `/etc/hosts`. Ce adresa IP te asteptai sa aiba? Pentru că imediat ați încercat să trimiteți ssh la `192.168.3.200`, care nu este aceeași adresă IP.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.