SSH em um namespace, conexão recusada

Question

Eu tenho um servidor Ubuntu com duas interfaces de rede e um namespace chamado "bluewire" (em homenagem à cor do cabo Ethernet conectado a ele).

Onamespacebluewiretemainterfaceenp4s0adicionadaaeleeéisoladodaWAN(queédesejada).EupossoSSHcomPuTTYdaminhaáreadetrabalhoparaopróprioservidorvia192.168.1.1:22,masPuTTYlançaumerro"Conexão recusada" quando tento conectar através de 192.168.1.2:22. Eu suspeito que o namespace não esteja escutando nenhuma porta.

O Delimma: Como habilito a escuta dentro do namespace para que eu possa fazer SSH através do fio azul? Ou se for algo diferente de um problema de audição, o que preciso fazer para que o SSH funcione através do fio azul?

Informação adicional:

• O UFW está aberto no lado do servidor e ip netns exec bluewire side no OpenSSH.
• As regras iptables para o namespace bluewire são totalmente abertas (tudo definido como ACCEPT ).
• O servidor é pingável a partir do endereço .2, apenas está recusando a conexão. Depois de executar um ip netns exec bluewire tcpdump -n dst port 22 , posso assumir que o servidor sabe que está recebendo uma solicitação da área de trabalho.
• A execução de netns -an revela que o próprio servidor está atendendo à porta 22, mas ip netns exec bluewire netstat -an exibe uma tabela vazia. É aí que eu suspeito que o problema é.
• Caso você esteja se perguntando por que eu tenho essa configuração: O fio vermelho conecta o servidor à internet enquanto o fio azul é bloqueado pela internet. O motivo é que, se eu suspeitar que meu servidor está sob ataque (como minhas chaves privadas sendo ignoradas), posso desconectar ou ifdown da interface de rede vermelha e restringir o acesso do servidor à rede local para que eu possa SSH somente através da área de trabalho para mudar as fechaduras.

EDITAR

O comentário de Per Blerg abaixo, uma captura de tela de netstat -plunt

• AmbasasinterfacessãoexecutáveisatravésdoWindowscmdnomeuDesktop.
• Atéondeeusei,oroteadornãoestábloqueandonenhumaportanaredeinterna;apenasbloqueiatodososacessosdomundoexterno,comexceçãodo1194,queeuusoparaoOpenVPN.Eupossomeconectaratravésdainterface.1semproblemasusandooPuTTYdaáreadetrabalho,entãoduvidoqueoroteadorsejaoculpado...talvez.

• Meuarquivo/etc/ssh/sshd_config

  [07:28]<~@>$cat/etc/ssh/sshd_config#Packagegeneratedconfigurationfile#Seethesshd_config(5)manpagefordetails#Whatports,IPsandprotocolswelistenforPort22#Usetheseoptionstorestrictwhichinterfaces/protocolssshdwillbindto#ListenAddress::ListenAddress192.168.1.1ListenAddress192.168.1.2Protocol2#HostKeysforprotocolversion2HostKey/etc/ssh/ssh_host_rsa_keyHostKey/etc/ssh/ssh_host_dsa_keyHostKey/etc/ssh/ssh_host_ecdsa_keyHostKey/etc/ssh/ssh_host_ed25519_key#PrivilegeSeparationisturnedonforsecurityUsePrivilegeSeparationyes#Lifetimeandsizeofephemeralversion1serverkeyKeyRegenerationInterval3600ServerKeyBits1024#LoggingSyslogFacilityAUTHLogLevelINFO#Authentication:LoginGraceTime120PermitRootLoginprohibit-passwordStrictModesyesRSAAuthenticationyesPubkeyAuthenticationyes#AuthorizedKeysFile%h/.ssh/authorized_keys#Don'treadtheuser's~/.rhostsand~/.shostsfilesIgnoreRhostsyes#Forthistoworkyouwillalsoneedhostkeysin/etc/ssh_known_hostsRhostsRSAAuthenticationno#similarforprotocolversion2HostbasedAuthenticationno#Uncommentifyoudon'ttrust~/.ssh/known_hostsfor#RhostsRSAAuthentication#IgnoreUserKnownHostsyes#Toenableemptypasswords,changetoyes(NOTRECOMMENDED)PermitEmptyPasswordsno#Changetoyestoenablechallenge-responsepasswords(bewareissueswith#somePAMmodulesandthreads)ChallengeResponseAuthenticationno#ChangetonotodisabletunnelledcleartextpasswordsPasswordAuthenticationno#Kerberosoptions#KerberosAuthenticationno#KerberosGetAFSTokenno#KerberosOrLocalPasswdyes#KerberosTicketCleanupyes#GSSAPIoptions#GSSAPIAuthenticationno#GSSAPICleanupCredentialsyesX11ForwardingyesX11DisplayOffset10PrintMotdnoPrintLastLogyesTCPKeepAliveyes#UseLoginno#MaxStartups10:30:60Banner/etc/issue.net#AllowclienttopasslocaleenvironmentvariablesAcceptEnvLANGLC_*Subsystemsftp/usr/lib/openssh/sftp-server#Setthisto'yes'toenablePAMauthentication,accountprocessing,#andsessionprocessing.Ifthisisenabled,PAMauthenticationwill#beallowedthroughtheChallengeResponseAuthenticationand#PasswordAuthentication.DependingonyourPAMconfiguration,#PAMauthenticationviaChallengeResponseAuthenticationmaybypass#thesettingof"PermitRootLogin without-password".
  # If you just want the PAM account and session checks to run without
  # PAM authentication, then enable this but set PasswordAuthentication
  # and ChallengeResponseAuthentication to 'no'.
  UsePAM yes
  [07:29]<~ @ > $
  

Answer 1

Para os interessados, encontrei a solução a partir daqui: link .

O truque é iniciar um servidor sshd separado em cada namespace:

ip netns exec mynamesapce /usr/sbin/sshd -o PidFile=/run/sshd-mynamespace.pid

Claro que o firewall deve permitir tcp / ssh

    

Answer 2

Pelo que eu posso dizer da sua postagem, você provavelmente só tem seu daemon SSH escutando em uma interface. No seu arquivo /etc/ssh/sshd_config , verifique se você tem ListenAddress listado como este: #ListenAddress . Se estiver habilitado, o servidor OpenSSH escutará apenas conexões de entrada no (s) endereço (s) especificado (s). Se você quiser usar ListenAddress para vários IPs, então você precisará tê-los em linhas separadas, como este:

ListenAddress 192.168.1.1
ListenAddress 192.168.1.2