Unable to SSH but able to ping it

Question

I am using Ubuntu 16.04. The problem is I am able to SSH other machines from my system but I am unable to SSH my system from another machine. However, I am able to ping my system from other machines.

For example, my system's IP address is 192.168.103.32 and another machine which runs CentOS has IP address 192.168.170.52. So I am able to SSH on 192.168.170.52 from 192.168.103.32 but vice-versa fails. Also, I am able to ping 192.168.103.32 from 192.168.170.52.

Output of ssh from 192.168.170.52:

ssh -v bhavya@192.168.103.32
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.103.32 [192.168.103.32] port 22.

Output for:

sudo service ssh status

is:

ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: ena
   Active: active (running) since Thu 2017-06-29 11:39:00 IST; 39min ago
  Process: 3064 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCE
 Main PID: 1142 (sshd)
   CGroup: /system.slice/ssh.service
           └─1142 /usr/sbin/sshd -D

Jun 29 11:39:37 bhavya systemd[1]: Reloading OpenBSD Secure Shell server.
Jun 29 11:39:37 bhavya sshd[1142]: Received SIGHUP; restarting.
Jun 29 11:39:37 bhavya systemd[1]: Reloaded OpenBSD Secure Shell server.
Jun 29 11:39:37 bhavya sshd[1142]: Server listening on 0.0.0.0 port 22.
Jun 29 11:39:37 bhavya sshd[1142]: Server listening on :: port 22.
Jun 29 11:39:37 bhavya systemd[1]: Reloading OpenBSD Secure Shell server.
Jun 29 11:39:37 bhavya sshd[1142]: Received SIGHUP; restarting.
Jun 29 11:39:37 bhavya sshd[1142]: Server listening on 0.0.0.0 port 22.
Jun 29 11:39:37 bhavya sshd[1142]: Server listening on :: port 22.
Jun 29 11:39:37 bhavya systemd[1]: Reloaded OpenBSD Secure Shell server.

Answer 1

I would run through standard network connectivity testing.

If the ssh server is supposed to be on the same network as you, then try to ping it. If the ping is successful, however, it does not necessarily mean that you have full IP connectivity. Check, especially if the server is a VM, that the MAC address of the network interface (virtual or real) is in the same vLAN as the client. If you are running any form of packet tagging, rather than switchport tagging, then there are circumstances when a switch will correctly pass ICMP packets, but not TCP/UDP ones. That one has been driving me mad all day.

Answer 2

Executing

sudo ufw allow 22

worked for me.

Explanation:--

UFW, or Uncomplicated Firewall, is a front-end to iptables. Its main goal is to make managing your firewall drop-dead simple and to provide an easy-to-use interface. It’s well-supported and popular in the Linux community—even installed by default in a lot of distros.

One of the things that will make setting up any firewall easier is to define some default rules for allowing and denying connections. UFW’s defaults are to deny all incoming connections and allow all outgoing connections. This means anyone trying to reach your cloud server would not be able to connect, while any application within the server would be able to reach the outside world.

Actually, yesterday I was having hard time configuring nfs ,so I was trying to configure my firewall.And today when I booted my computer the firewall settings might have set to default.So this might be the problem.