Cannot ssh into a fresh install of CentOS minimal on lan












3














I've downloaded CentOS 7 Minimal and installed on an old laptop. I want to be able to ssh to the machine from other machines on the same lan. But I keep getting this error ..



ssh: connect to host 192.168.0.17 port 2110: No route to host


192.168.0.17 .. Is the new CentOS machine.



rob@ciserver:~$ hostname
ciserver


192.168.0.11 .. Is the machine I'm trying to access from.



rob@work:~$ ifconfig | grep "inet addr" | tail -1
inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0
rob@work:~$ ping -vvv 192.168.0.17
PING 192.168.0.17 (192.168.0.17) 56(84) bytes of data.
From 192.168.0.11 icmp_seq=1 Destination Host Unreachable


These are the config steps and info from my CentOS install, hopefully someone can help identify when I cannot remotely access the machine?



rob@ciserver:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp14s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd xx:xx:xx:xx:xx:xx
3: wlp20s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd xx:xx:xx:xx:xx:xx
inet 192.168.0.17/24 brd 192.168.0.255 scope global dynamic wlp20s0
valid_lft 84703sec preferred_lft 84703sec
inet6 xxxx::xxxx:xxxx:xxxx:xxxx/xx scope link
valid_lft forever preferred_lft forever


I modified my ssh config to listen on a different port and not allow root access ..



rob@ciserver:~$ grep Port /etc/ssh/sshd_config 
Port 2110
rob@ciserver:~$ grep Root /etc/ssh/sshd_config
PermitRootLogin no
rob@ciserver:~$ sudo systemctl reload sshd.service
rob@ciserver:~$ sudo service sshd restart


I added a new rule to firewall for updated ssh port ..



sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --permanent --add-port=2110/tcp
sudo firewall-cmd --reload
sudo systemctl enable firewalld


/etc/hosts contents ..



127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain6
::1 localhost localhost.localdomain localhost4 localhost4.localdomain6









share|improve this question
























  • The next check: sudo netstat -tnlp | grep ssh. Also, can the other systems ping this server?
    – muru
    Feb 10 '15 at 2:07












  • can you ping your router from ciserver ? e.g. ping 192.168.0.1 ?
    – Archemar
    Feb 10 '15 at 8:07










  • @muru there is no output from sudo netstat -tnlp | grep ssh. ciserver cannot ping the router and other systems cannot ping ciserver either.
    – bobbyrne01
    Feb 10 '15 at 21:13










  • What is the IP address of the machine you are using to ssh to the new CentOS server? If it is a linux box try using ssh -vvv 192.168.0.17 and provide the output.
    – Alfonso
    Feb 11 '15 at 20:13










  • @Alfonso 192.168.0.11 is the IP of the source machine. I've updated question with results of ssh -vvv .. From 192.168.0.11 icmp_seq=1 Destination Host Unreachable
    – bobbyrne01
    Feb 16 '15 at 13:21
















3














I've downloaded CentOS 7 Minimal and installed on an old laptop. I want to be able to ssh to the machine from other machines on the same lan. But I keep getting this error ..



ssh: connect to host 192.168.0.17 port 2110: No route to host


192.168.0.17 .. Is the new CentOS machine.



rob@ciserver:~$ hostname
ciserver


192.168.0.11 .. Is the machine I'm trying to access from.



rob@work:~$ ifconfig | grep "inet addr" | tail -1
inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0
rob@work:~$ ping -vvv 192.168.0.17
PING 192.168.0.17 (192.168.0.17) 56(84) bytes of data.
From 192.168.0.11 icmp_seq=1 Destination Host Unreachable


These are the config steps and info from my CentOS install, hopefully someone can help identify when I cannot remotely access the machine?



rob@ciserver:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp14s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd xx:xx:xx:xx:xx:xx
3: wlp20s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd xx:xx:xx:xx:xx:xx
inet 192.168.0.17/24 brd 192.168.0.255 scope global dynamic wlp20s0
valid_lft 84703sec preferred_lft 84703sec
inet6 xxxx::xxxx:xxxx:xxxx:xxxx/xx scope link
valid_lft forever preferred_lft forever


I modified my ssh config to listen on a different port and not allow root access ..



rob@ciserver:~$ grep Port /etc/ssh/sshd_config 
Port 2110
rob@ciserver:~$ grep Root /etc/ssh/sshd_config
PermitRootLogin no
rob@ciserver:~$ sudo systemctl reload sshd.service
rob@ciserver:~$ sudo service sshd restart


I added a new rule to firewall for updated ssh port ..



sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --permanent --add-port=2110/tcp
sudo firewall-cmd --reload
sudo systemctl enable firewalld


/etc/hosts contents ..



127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain6
::1 localhost localhost.localdomain localhost4 localhost4.localdomain6









share|improve this question
























  • The next check: sudo netstat -tnlp | grep ssh. Also, can the other systems ping this server?
    – muru
    Feb 10 '15 at 2:07












  • can you ping your router from ciserver ? e.g. ping 192.168.0.1 ?
    – Archemar
    Feb 10 '15 at 8:07










  • @muru there is no output from sudo netstat -tnlp | grep ssh. ciserver cannot ping the router and other systems cannot ping ciserver either.
    – bobbyrne01
    Feb 10 '15 at 21:13










  • What is the IP address of the machine you are using to ssh to the new CentOS server? If it is a linux box try using ssh -vvv 192.168.0.17 and provide the output.
    – Alfonso
    Feb 11 '15 at 20:13










  • @Alfonso 192.168.0.11 is the IP of the source machine. I've updated question with results of ssh -vvv .. From 192.168.0.11 icmp_seq=1 Destination Host Unreachable
    – bobbyrne01
    Feb 16 '15 at 13:21














3












3








3







I've downloaded CentOS 7 Minimal and installed on an old laptop. I want to be able to ssh to the machine from other machines on the same lan. But I keep getting this error ..



ssh: connect to host 192.168.0.17 port 2110: No route to host


192.168.0.17 .. Is the new CentOS machine.



rob@ciserver:~$ hostname
ciserver


192.168.0.11 .. Is the machine I'm trying to access from.



rob@work:~$ ifconfig | grep "inet addr" | tail -1
inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0
rob@work:~$ ping -vvv 192.168.0.17
PING 192.168.0.17 (192.168.0.17) 56(84) bytes of data.
From 192.168.0.11 icmp_seq=1 Destination Host Unreachable


These are the config steps and info from my CentOS install, hopefully someone can help identify when I cannot remotely access the machine?



rob@ciserver:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp14s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd xx:xx:xx:xx:xx:xx
3: wlp20s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd xx:xx:xx:xx:xx:xx
inet 192.168.0.17/24 brd 192.168.0.255 scope global dynamic wlp20s0
valid_lft 84703sec preferred_lft 84703sec
inet6 xxxx::xxxx:xxxx:xxxx:xxxx/xx scope link
valid_lft forever preferred_lft forever


I modified my ssh config to listen on a different port and not allow root access ..



rob@ciserver:~$ grep Port /etc/ssh/sshd_config 
Port 2110
rob@ciserver:~$ grep Root /etc/ssh/sshd_config
PermitRootLogin no
rob@ciserver:~$ sudo systemctl reload sshd.service
rob@ciserver:~$ sudo service sshd restart


I added a new rule to firewall for updated ssh port ..



sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --permanent --add-port=2110/tcp
sudo firewall-cmd --reload
sudo systemctl enable firewalld


/etc/hosts contents ..



127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain6
::1 localhost localhost.localdomain localhost4 localhost4.localdomain6









share|improve this question















I've downloaded CentOS 7 Minimal and installed on an old laptop. I want to be able to ssh to the machine from other machines on the same lan. But I keep getting this error ..



ssh: connect to host 192.168.0.17 port 2110: No route to host


192.168.0.17 .. Is the new CentOS machine.



rob@ciserver:~$ hostname
ciserver


192.168.0.11 .. Is the machine I'm trying to access from.



rob@work:~$ ifconfig | grep "inet addr" | tail -1
inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0
rob@work:~$ ping -vvv 192.168.0.17
PING 192.168.0.17 (192.168.0.17) 56(84) bytes of data.
From 192.168.0.11 icmp_seq=1 Destination Host Unreachable


These are the config steps and info from my CentOS install, hopefully someone can help identify when I cannot remotely access the machine?



rob@ciserver:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp14s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd xx:xx:xx:xx:xx:xx
3: wlp20s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd xx:xx:xx:xx:xx:xx
inet 192.168.0.17/24 brd 192.168.0.255 scope global dynamic wlp20s0
valid_lft 84703sec preferred_lft 84703sec
inet6 xxxx::xxxx:xxxx:xxxx:xxxx/xx scope link
valid_lft forever preferred_lft forever


I modified my ssh config to listen on a different port and not allow root access ..



rob@ciserver:~$ grep Port /etc/ssh/sshd_config 
Port 2110
rob@ciserver:~$ grep Root /etc/ssh/sshd_config
PermitRootLogin no
rob@ciserver:~$ sudo systemctl reload sshd.service
rob@ciserver:~$ sudo service sshd restart


I added a new rule to firewall for updated ssh port ..



sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --permanent --add-port=2110/tcp
sudo firewall-cmd --reload
sudo systemctl enable firewalld


/etc/hosts contents ..



127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain6
::1 localhost localhost.localdomain localhost4 localhost4.localdomain6






ssh centos






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 16 '15 at 13:20

























asked Feb 10 '15 at 0:11









bobbyrne01

11615




11615












  • The next check: sudo netstat -tnlp | grep ssh. Also, can the other systems ping this server?
    – muru
    Feb 10 '15 at 2:07












  • can you ping your router from ciserver ? e.g. ping 192.168.0.1 ?
    – Archemar
    Feb 10 '15 at 8:07










  • @muru there is no output from sudo netstat -tnlp | grep ssh. ciserver cannot ping the router and other systems cannot ping ciserver either.
    – bobbyrne01
    Feb 10 '15 at 21:13










  • What is the IP address of the machine you are using to ssh to the new CentOS server? If it is a linux box try using ssh -vvv 192.168.0.17 and provide the output.
    – Alfonso
    Feb 11 '15 at 20:13










  • @Alfonso 192.168.0.11 is the IP of the source machine. I've updated question with results of ssh -vvv .. From 192.168.0.11 icmp_seq=1 Destination Host Unreachable
    – bobbyrne01
    Feb 16 '15 at 13:21


















  • The next check: sudo netstat -tnlp | grep ssh. Also, can the other systems ping this server?
    – muru
    Feb 10 '15 at 2:07












  • can you ping your router from ciserver ? e.g. ping 192.168.0.1 ?
    – Archemar
    Feb 10 '15 at 8:07










  • @muru there is no output from sudo netstat -tnlp | grep ssh. ciserver cannot ping the router and other systems cannot ping ciserver either.
    – bobbyrne01
    Feb 10 '15 at 21:13










  • What is the IP address of the machine you are using to ssh to the new CentOS server? If it is a linux box try using ssh -vvv 192.168.0.17 and provide the output.
    – Alfonso
    Feb 11 '15 at 20:13










  • @Alfonso 192.168.0.11 is the IP of the source machine. I've updated question with results of ssh -vvv .. From 192.168.0.11 icmp_seq=1 Destination Host Unreachable
    – bobbyrne01
    Feb 16 '15 at 13:21
















The next check: sudo netstat -tnlp | grep ssh. Also, can the other systems ping this server?
– muru
Feb 10 '15 at 2:07






The next check: sudo netstat -tnlp | grep ssh. Also, can the other systems ping this server?
– muru
Feb 10 '15 at 2:07














can you ping your router from ciserver ? e.g. ping 192.168.0.1 ?
– Archemar
Feb 10 '15 at 8:07




can you ping your router from ciserver ? e.g. ping 192.168.0.1 ?
– Archemar
Feb 10 '15 at 8:07












@muru there is no output from sudo netstat -tnlp | grep ssh. ciserver cannot ping the router and other systems cannot ping ciserver either.
– bobbyrne01
Feb 10 '15 at 21:13




@muru there is no output from sudo netstat -tnlp | grep ssh. ciserver cannot ping the router and other systems cannot ping ciserver either.
– bobbyrne01
Feb 10 '15 at 21:13












What is the IP address of the machine you are using to ssh to the new CentOS server? If it is a linux box try using ssh -vvv 192.168.0.17 and provide the output.
– Alfonso
Feb 11 '15 at 20:13




What is the IP address of the machine you are using to ssh to the new CentOS server? If it is a linux box try using ssh -vvv 192.168.0.17 and provide the output.
– Alfonso
Feb 11 '15 at 20:13












@Alfonso 192.168.0.11 is the IP of the source machine. I've updated question with results of ssh -vvv .. From 192.168.0.11 icmp_seq=1 Destination Host Unreachable
– bobbyrne01
Feb 16 '15 at 13:21




@Alfonso 192.168.0.11 is the IP of the source machine. I've updated question with results of ssh -vvv .. From 192.168.0.11 icmp_seq=1 Destination Host Unreachable
– bobbyrne01
Feb 16 '15 at 13:21










3 Answers
3






active

oldest

votes


















1














I think by default selinux is enabled and is only configured to allow port 22 for ssh. have you either disabled it or added an exception for the new port?



semanage port -a -t ssh_port_t -p tcp 2110





share|improve this answer



















  • 1




    will never understand why people change ssh ports, security by obscurity does not work.
    – Rui F Ribeiro
    Nov 15 '15 at 14:33






  • 1




    @RuiFRibeiro - you can often stop the probes by simply moving the port. Attacks follow economic theory. The majority of attackers don't perform a full port scan because its more expensive and risky than a simple port 22 probe. When they don't find anything on port 22, they will often move on to another victim. Ironically, bobbyrne01 and user164448 probably won't be a victim as often as you :) The economic theory also explains why phishing is so popular.
    – jww
    Jun 12 '16 at 3:00










  • @RuiFRibeiro It doesn't protect against a targeted attack, but emperical evidence is pretty strong on the side of what jww says. Running on a different port will reduce probes by an astounding factor (at least a thousandfold).
    – mattdm
    Mar 5 '17 at 12:26










  • I would never run an ssh port open to the Internet. As purely empirical tale, I once forgot to firewall an ssh entry when setting up an ISP, and in that single night, had 200k+ ssh probes.
    – Rui F Ribeiro
    Mar 5 '17 at 15:40



















0














I am a necromancer, but if this should save some other poor soul the trouble:



In nmcli setup, I had applied the wrong subnet mask.



nmcli con add type ethernet con-name $CONNAME ifname $IFNAME 
ip4 192.168.1.20 gw4 192.168.1.1


...gave me a mask of 255.255.255.255, with a brd (broadcast) equal to the server's IP. That server wasn't going to be talking to anyone.



The proper setup (this is minimal install, so it's important) would be



nmcli con add type ethernet con-name $CONNAME ifname $IFNAME 
ip4 192.168.1.20/24 gw4 192.168.1.1


Of course, check the CIDR prefix of your subnet mask for your own network. But this solved the problem for me.






share|improve this answer





























    -2














    as root:



    -A INPUT -m state --state NEW -m tcp -p tcp --dport 2110 -j ACCEPT


    restart ssh service checks the ssh connection, or restart the system.






    share|improve this answer





















    • The question makes clear that OP added a firewall rule for this port...
      – jasonwryan
      Jun 12 '16 at 5:18











    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f183926%2fcannot-ssh-into-a-fresh-install-of-centos-minimal-on-lan%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1














    I think by default selinux is enabled and is only configured to allow port 22 for ssh. have you either disabled it or added an exception for the new port?



    semanage port -a -t ssh_port_t -p tcp 2110





    share|improve this answer



















    • 1




      will never understand why people change ssh ports, security by obscurity does not work.
      – Rui F Ribeiro
      Nov 15 '15 at 14:33






    • 1




      @RuiFRibeiro - you can often stop the probes by simply moving the port. Attacks follow economic theory. The majority of attackers don't perform a full port scan because its more expensive and risky than a simple port 22 probe. When they don't find anything on port 22, they will often move on to another victim. Ironically, bobbyrne01 and user164448 probably won't be a victim as often as you :) The economic theory also explains why phishing is so popular.
      – jww
      Jun 12 '16 at 3:00










    • @RuiFRibeiro It doesn't protect against a targeted attack, but emperical evidence is pretty strong on the side of what jww says. Running on a different port will reduce probes by an astounding factor (at least a thousandfold).
      – mattdm
      Mar 5 '17 at 12:26










    • I would never run an ssh port open to the Internet. As purely empirical tale, I once forgot to firewall an ssh entry when setting up an ISP, and in that single night, had 200k+ ssh probes.
      – Rui F Ribeiro
      Mar 5 '17 at 15:40
















    1














    I think by default selinux is enabled and is only configured to allow port 22 for ssh. have you either disabled it or added an exception for the new port?



    semanage port -a -t ssh_port_t -p tcp 2110





    share|improve this answer



















    • 1




      will never understand why people change ssh ports, security by obscurity does not work.
      – Rui F Ribeiro
      Nov 15 '15 at 14:33






    • 1




      @RuiFRibeiro - you can often stop the probes by simply moving the port. Attacks follow economic theory. The majority of attackers don't perform a full port scan because its more expensive and risky than a simple port 22 probe. When they don't find anything on port 22, they will often move on to another victim. Ironically, bobbyrne01 and user164448 probably won't be a victim as often as you :) The economic theory also explains why phishing is so popular.
      – jww
      Jun 12 '16 at 3:00










    • @RuiFRibeiro It doesn't protect against a targeted attack, but emperical evidence is pretty strong on the side of what jww says. Running on a different port will reduce probes by an astounding factor (at least a thousandfold).
      – mattdm
      Mar 5 '17 at 12:26










    • I would never run an ssh port open to the Internet. As purely empirical tale, I once forgot to firewall an ssh entry when setting up an ISP, and in that single night, had 200k+ ssh probes.
      – Rui F Ribeiro
      Mar 5 '17 at 15:40














    1












    1








    1






    I think by default selinux is enabled and is only configured to allow port 22 for ssh. have you either disabled it or added an exception for the new port?



    semanage port -a -t ssh_port_t -p tcp 2110





    share|improve this answer














    I think by default selinux is enabled and is only configured to allow port 22 for ssh. have you either disabled it or added an exception for the new port?



    semanage port -a -t ssh_port_t -p tcp 2110






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Feb 17 '15 at 20:28









    HalosGhost

    3,70592235




    3,70592235










    answered Feb 17 '15 at 20:24









    user164448

    111




    111








    • 1




      will never understand why people change ssh ports, security by obscurity does not work.
      – Rui F Ribeiro
      Nov 15 '15 at 14:33






    • 1




      @RuiFRibeiro - you can often stop the probes by simply moving the port. Attacks follow economic theory. The majority of attackers don't perform a full port scan because its more expensive and risky than a simple port 22 probe. When they don't find anything on port 22, they will often move on to another victim. Ironically, bobbyrne01 and user164448 probably won't be a victim as often as you :) The economic theory also explains why phishing is so popular.
      – jww
      Jun 12 '16 at 3:00










    • @RuiFRibeiro It doesn't protect against a targeted attack, but emperical evidence is pretty strong on the side of what jww says. Running on a different port will reduce probes by an astounding factor (at least a thousandfold).
      – mattdm
      Mar 5 '17 at 12:26










    • I would never run an ssh port open to the Internet. As purely empirical tale, I once forgot to firewall an ssh entry when setting up an ISP, and in that single night, had 200k+ ssh probes.
      – Rui F Ribeiro
      Mar 5 '17 at 15:40














    • 1




      will never understand why people change ssh ports, security by obscurity does not work.
      – Rui F Ribeiro
      Nov 15 '15 at 14:33






    • 1




      @RuiFRibeiro - you can often stop the probes by simply moving the port. Attacks follow economic theory. The majority of attackers don't perform a full port scan because its more expensive and risky than a simple port 22 probe. When they don't find anything on port 22, they will often move on to another victim. Ironically, bobbyrne01 and user164448 probably won't be a victim as often as you :) The economic theory also explains why phishing is so popular.
      – jww
      Jun 12 '16 at 3:00










    • @RuiFRibeiro It doesn't protect against a targeted attack, but emperical evidence is pretty strong on the side of what jww says. Running on a different port will reduce probes by an astounding factor (at least a thousandfold).
      – mattdm
      Mar 5 '17 at 12:26










    • I would never run an ssh port open to the Internet. As purely empirical tale, I once forgot to firewall an ssh entry when setting up an ISP, and in that single night, had 200k+ ssh probes.
      – Rui F Ribeiro
      Mar 5 '17 at 15:40








    1




    1




    will never understand why people change ssh ports, security by obscurity does not work.
    – Rui F Ribeiro
    Nov 15 '15 at 14:33




    will never understand why people change ssh ports, security by obscurity does not work.
    – Rui F Ribeiro
    Nov 15 '15 at 14:33




    1




    1




    @RuiFRibeiro - you can often stop the probes by simply moving the port. Attacks follow economic theory. The majority of attackers don't perform a full port scan because its more expensive and risky than a simple port 22 probe. When they don't find anything on port 22, they will often move on to another victim. Ironically, bobbyrne01 and user164448 probably won't be a victim as often as you :) The economic theory also explains why phishing is so popular.
    – jww
    Jun 12 '16 at 3:00




    @RuiFRibeiro - you can often stop the probes by simply moving the port. Attacks follow economic theory. The majority of attackers don't perform a full port scan because its more expensive and risky than a simple port 22 probe. When they don't find anything on port 22, they will often move on to another victim. Ironically, bobbyrne01 and user164448 probably won't be a victim as often as you :) The economic theory also explains why phishing is so popular.
    – jww
    Jun 12 '16 at 3:00












    @RuiFRibeiro It doesn't protect against a targeted attack, but emperical evidence is pretty strong on the side of what jww says. Running on a different port will reduce probes by an astounding factor (at least a thousandfold).
    – mattdm
    Mar 5 '17 at 12:26




    @RuiFRibeiro It doesn't protect against a targeted attack, but emperical evidence is pretty strong on the side of what jww says. Running on a different port will reduce probes by an astounding factor (at least a thousandfold).
    – mattdm
    Mar 5 '17 at 12:26












    I would never run an ssh port open to the Internet. As purely empirical tale, I once forgot to firewall an ssh entry when setting up an ISP, and in that single night, had 200k+ ssh probes.
    – Rui F Ribeiro
    Mar 5 '17 at 15:40




    I would never run an ssh port open to the Internet. As purely empirical tale, I once forgot to firewall an ssh entry when setting up an ISP, and in that single night, had 200k+ ssh probes.
    – Rui F Ribeiro
    Mar 5 '17 at 15:40













    0














    I am a necromancer, but if this should save some other poor soul the trouble:



    In nmcli setup, I had applied the wrong subnet mask.



    nmcli con add type ethernet con-name $CONNAME ifname $IFNAME 
    ip4 192.168.1.20 gw4 192.168.1.1


    ...gave me a mask of 255.255.255.255, with a brd (broadcast) equal to the server's IP. That server wasn't going to be talking to anyone.



    The proper setup (this is minimal install, so it's important) would be



    nmcli con add type ethernet con-name $CONNAME ifname $IFNAME 
    ip4 192.168.1.20/24 gw4 192.168.1.1


    Of course, check the CIDR prefix of your subnet mask for your own network. But this solved the problem for me.






    share|improve this answer


























      0














      I am a necromancer, but if this should save some other poor soul the trouble:



      In nmcli setup, I had applied the wrong subnet mask.



      nmcli con add type ethernet con-name $CONNAME ifname $IFNAME 
      ip4 192.168.1.20 gw4 192.168.1.1


      ...gave me a mask of 255.255.255.255, with a brd (broadcast) equal to the server's IP. That server wasn't going to be talking to anyone.



      The proper setup (this is minimal install, so it's important) would be



      nmcli con add type ethernet con-name $CONNAME ifname $IFNAME 
      ip4 192.168.1.20/24 gw4 192.168.1.1


      Of course, check the CIDR prefix of your subnet mask for your own network. But this solved the problem for me.






      share|improve this answer
























        0












        0








        0






        I am a necromancer, but if this should save some other poor soul the trouble:



        In nmcli setup, I had applied the wrong subnet mask.



        nmcli con add type ethernet con-name $CONNAME ifname $IFNAME 
        ip4 192.168.1.20 gw4 192.168.1.1


        ...gave me a mask of 255.255.255.255, with a brd (broadcast) equal to the server's IP. That server wasn't going to be talking to anyone.



        The proper setup (this is minimal install, so it's important) would be



        nmcli con add type ethernet con-name $CONNAME ifname $IFNAME 
        ip4 192.168.1.20/24 gw4 192.168.1.1


        Of course, check the CIDR prefix of your subnet mask for your own network. But this solved the problem for me.






        share|improve this answer












        I am a necromancer, but if this should save some other poor soul the trouble:



        In nmcli setup, I had applied the wrong subnet mask.



        nmcli con add type ethernet con-name $CONNAME ifname $IFNAME 
        ip4 192.168.1.20 gw4 192.168.1.1


        ...gave me a mask of 255.255.255.255, with a brd (broadcast) equal to the server's IP. That server wasn't going to be talking to anyone.



        The proper setup (this is minimal install, so it's important) would be



        nmcli con add type ethernet con-name $CONNAME ifname $IFNAME 
        ip4 192.168.1.20/24 gw4 192.168.1.1


        Of course, check the CIDR prefix of your subnet mask for your own network. But this solved the problem for me.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 16 at 10:40









        Chaim Eliyah

        1013




        1013























            -2














            as root:



            -A INPUT -m state --state NEW -m tcp -p tcp --dport 2110 -j ACCEPT


            restart ssh service checks the ssh connection, or restart the system.






            share|improve this answer





















            • The question makes clear that OP added a firewall rule for this port...
              – jasonwryan
              Jun 12 '16 at 5:18
















            -2














            as root:



            -A INPUT -m state --state NEW -m tcp -p tcp --dport 2110 -j ACCEPT


            restart ssh service checks the ssh connection, or restart the system.






            share|improve this answer





















            • The question makes clear that OP added a firewall rule for this port...
              – jasonwryan
              Jun 12 '16 at 5:18














            -2












            -2








            -2






            as root:



            -A INPUT -m state --state NEW -m tcp -p tcp --dport 2110 -j ACCEPT


            restart ssh service checks the ssh connection, or restart the system.






            share|improve this answer












            as root:



            -A INPUT -m state --state NEW -m tcp -p tcp --dport 2110 -j ACCEPT


            restart ssh service checks the ssh connection, or restart the system.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jun 12 '16 at 2:37









            israelmp

            1




            1












            • The question makes clear that OP added a firewall rule for this port...
              – jasonwryan
              Jun 12 '16 at 5:18


















            • The question makes clear that OP added a firewall rule for this port...
              – jasonwryan
              Jun 12 '16 at 5:18
















            The question makes clear that OP added a firewall rule for this port...
            – jasonwryan
            Jun 12 '16 at 5:18




            The question makes clear that OP added a firewall rule for this port...
            – jasonwryan
            Jun 12 '16 at 5:18


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f183926%2fcannot-ssh-into-a-fresh-install-of-centos-minimal-on-lan%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Morgemoulin

            Scott Moir

            Souastre