On my Debian server I have a eth0 interface (192.168.10.x) and I just added eth1 (176.31.36.x). I would like to set up a public access for ssh, web, ..etc.

allow-hotplug eth1
iface eth1 inet static
        address 176.31.36.x
        network 176.31.36.x
        broadcast 171.31.36.x
        gateway 176.31.36.x
        dns-search mydomain.com

I added these routes:

iptables -I INPUT -p tcp --dport 80 -j ACCEPT -m comment --comment "Allow HTTP"
iptables -I INPUT -p tcp --dport 443 -j ACCEPT -m comment --comment "Allow HTTPS"
iptables -I INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT -m comment --comment "Allow SSH"

The server was rebooted after that. Pinging the machine is working but neither ssh nor web are responding.


ssh -v 176.31.36.x
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 176.31.36.x [176.31.36.x] port 22.
debug1: Connection established.
debug1: identity file /home/admin/.ssh/id_rsa type -1
debug1: identity file /home/admin/.ssh/id_rsa-cert type -1
debug1: identity file /home/admin/.ssh/id_dsa type -1
debug1: identity file /home/admin/.ssh/id_dsa-cert type -1
debug1: identity file /home/admin/.ssh/id_ecdsa type -1
debug1: identity file /home/admin/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/admin/.ssh/id_ed25519 type -1
debug1: identity file /home/admin/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-3ubuntu1
debug1: match: OpenSSH_6.0p1 Debian-3ubuntu1 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 10:59:34:f5:bb:bb:6b:3f:7a:39:1b:26:24:45:18:cb
debug1: Host '176.31.36.x' is known and matches the ECDSA host key.
debug1: Found key in /home/admin/.ssh/known_hosts:57
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/admin/.ssh/id_rsa
debug1: Trying private key: /home/admin/.ssh/id_dsa
debug1: Trying private key: /home/admin/.ssh/id_ecdsa
debug1: Trying private key: /home/admin/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).

Update: The outout of netstat:

sudo netstat -lpn | grep ^tcp
tcp        0      0  *               LISTEN      508/beam        
tcp        0      0*               LISTEN      508/beam        
tcp        0      0    *               LISTEN      10968/sshd      
tcp        0      0  *               LISTEN      846/exim4       
tcp        0      0  *               LISTEN      508/beam        
tcp        0      0*               LISTEN      443/memcached   
tcp6       0      0 :::80                   :::*                    LISTEN      906/apache2     
tcp6       0      0 ::1:25                  :::*                    LISTEN      846/exim4       
tcp6       0      0 :::443                  :::*                    LISTEN      906/apache2    
  • Are the server processes (sshd, httpd, &c) listening on this new interface? Try sudo netstat -lpn | grep ^tcp and see if any of them are bound to the old (192.168.10.x) interface only. – The Sidhekin Sep 21 '15 at 13:36
  • @TheSidhekin I added the output of netstat to the message. – 4m1nh4j1 Sep 23 '15 at 13:54
  • That looks fine. Both sshd and apache are listening to all interfaces, best as I can tell. And I now see that the output from your ssh -v indicates it has established a connection to some 176.31.36.x. Is it the right host? Does the host key (ECDSA 10:59:34:f5:bb:bb:6b:3f:7a:39:1b:26:24:45:18:cb) match what you get from ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub? If not, it looks like it's routed to some other host claiming the 176.31.36.x address. (If it does match, it looks like you're connecting to the right host, but none of the keys work.) – The Sidhekin Sep 23 '15 at 19:46
  • The ecdsa key in the server is different from the one that the client found ! Strange! As you say it may be routed. I removed all keys and reconfigured ssh. Won't work as well ! – 4m1nh4j1 Sep 24 '15 at 10:01

After our comment exchange, it seems clear to me this is a routing problem. Some other host is answering to 176.31.36.x, and ssh establishes a connection to that host.

Check (preferably from clients on two or more nets) that your connections are indeed routed to the correct LAN: sudo traceroute 176.31.36.x, with variations sudo traceroute -I 176.31.36.x, sudo traceroute -T 176.31.36.x can be useful here.

And check that you don't have any other units on the (176.31.36.x) LAN grabbing that address.

If everything still seems correct, check the setup of the (176.31.36.x) LAN router; it may for instance have port forwarding configured that takes ssh connections elsewhere.

By now I'm pretty sure it's one of these. Or a failure of my imagination, but that seems less and less probable. ;-)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.