SSH into a namespace, connection refused

Question

I have an Ubuntu Server with two network interfaces and a namespace named "bluewire" (named after the color of the Ethernet cable connected to it).

The bluewire namespace has the enp4s0 interface added to it and is isolated from the WAN (which is desired). I can SSH with PuTTY from my desktop into the server itself via 192.168.1.1:22, but PuTTY throws a "Connection Refused" error when I try to connect through 192.168.1.2:22. I suspect the namespace is not listening to any ports at all.

The Delimma: How do I enable listening within the namespace so I can SSH in through the blue wire? Or if it's something other than a listening issue, what do I need to do to get SSH working through the blue wire?

Additional info:

• The UFW is open both on the server side and ip netns exec bluewire side to OpenSSH.
• The iptables rules for the bluewire namespace are wide open (everything set to ACCEPT).
• The server is pingable from the .2 address, it's just refusing the connection. After running an ip netns exec bluewire tcpdump -n dst port 22, I can assume the server knows it's receiving a request from the desktop.
• Running netns -an reveals the server itself is listening to port 22, but ip netns exec bluewire netstat -an turns up an empty table. That's where I suspect the problem is.
• In case you're wondering why I have such a setup: The red wire connects the sever to the internet while the blue wire is blocked off from the internet. The reason being if I suspect my server is under attack (such as my private keys getting swiped), then I can disconnect or ifdown the red wire interface and restrict server access to the local network so I can SSH in only through the desktop to change the locks.

EDIT

Per Blerg's comment below, a screenshot of netstat -plunt

• Both interfaces are pingable through the Windows cmd on my Desktop.
• As far as I know the router isn't blocking any ports on the internal network; it just blocks all access from the outside world with the exception of 1194, which I use for OpenVPN. I can connect through the .1 interface without any problems using the desktop PuTTY so I doubt the router is the culprit... maybe.

• My /etc/ssh/sshd_config file

  [07:28]<~ @ > $ cat /etc/ssh/sshd_config
  # Package generated configuration file
  # See the sshd_config(5) manpage for details
  # What ports, IPs and protocols we listen for
  Port 22
  # Use these options to restrict which interfaces/protocols sshd will bind to
  #ListenAddress ::
  ListenAddress 192.168.1.1
  ListenAddress 192.168.1.2
  Protocol 2
  # HostKeys for protocol version 2
  HostKey /etc/ssh/ssh_host_rsa_key
  HostKey /etc/ssh/ssh_host_dsa_key
  HostKey /etc/ssh/ssh_host_ecdsa_key
  HostKey /etc/ssh/ssh_host_ed25519_key
  #Privilege Separation is turned on for security
  UsePrivilegeSeparation yes
  # Lifetime and size of ephemeral version 1 server key
  KeyRegenerationInterval 3600
  ServerKeyBits 1024
  # Logging
  SyslogFacility AUTH
  LogLevel INFO 
  # Authentication:
  LoginGraceTime 120
  PermitRootLogin prohibit-password
  StrictModes yes
  RSAAuthentication yes
  PubkeyAuthentication yes
  #AuthorizedKeysFile     %h/.ssh/authorized_keys
  # Don't read the user's ~/.rhosts and ~/.shosts files
  IgnoreRhosts yes
  # For this to work you will also need host keys in /etc/ssh_known_hosts
  RhostsRSAAuthentication no
  # similar for protocol version 2
  HostbasedAuthentication no
  # Uncomment if you don't trust ~/.ssh/known_hosts for 
  # RhostsRSAAuthentication
  #IgnoreUserKnownHosts yes
  # To enable empty passwords, change to yes (NOT RECOMMENDED)
  PermitEmptyPasswords no
  # Change to yes to enable challenge-response passwords (beware issues with
  # some PAM modules and threads)
  ChallengeResponseAuthentication no
  # Change to no to disable tunnelled clear text passwords
  PasswordAuthentication no
  # Kerberos options
  #KerberosAuthentication no
  #KerberosGetAFSToken no
  #KerberosOrLocalPasswd yes
  #KerberosTicketCleanup yes
  # GSSAPI options
  #GSSAPIAuthentication no
  #GSSAPICleanupCredentials yes
  X11Forwarding yes
  X11DisplayOffset 10
  PrintMotd no
  PrintLastLog yes
  TCPKeepAlive yes
  #UseLogin no    
  #MaxStartups 10:30:60
  Banner /etc/issue.net
  # Allow client to pass locale environment variables
  AcceptEnv LANG LC_*    
  Subsystem sftp /usr/lib/openssh/sftp-server    
  # Set this to 'yes' to enable PAM authentication, account processing,
  # and session processing. If this is enabled, PAM authentication will
  # be allowed through the ChallengeResponseAuthentication and
  # PasswordAuthentication.  Depending on your PAM configuration,
  # PAM authentication via ChallengeResponseAuthentication may bypass
  # the setting of "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

For those interested, I found the solution from here: https://blog.bofh.it/debian/id_446.

The trick is to start a separate sshd server in each namespace:

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

Of course firewall must allow tcp/ssh

 

Answer 2

From what I can tell from your post, you probably only have your SSH daemon listening on one interface. In your /etc/ssh/sshd_config file, make sure you have ListenAddress listed as this: #ListenAddress. If it is enabled, the OpenSSH server will only listen for incoming connections on the specified address(es). If you want to use ListenAddress for multiple IPs, then you will need to have them on separate lines, like this:

ListenAddress 192.168.1.1
ListenAddress 192.168.1.2