1

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 [email protected] 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.
Improve this question
6
  • Do you have openssh-server or any other ssh server installed on your Ubuntu? You can check if openssh-server is installed and running with sudo service ssh status Commented Jun 29, 2017 at 6:37
  • ssh.service - OpenBSD Secure Shell server Commented Jun 29, 2017 at 6:41
  • Please put the complete error log. Have you allowed ssh through firewall with sudo ufw allow 22 Commented Jun 29, 2017 at 6:45
  • 2
    sudo ufw allow 22. Worked for me.Thanks @GilsonVarghese Commented Jun 29, 2017 at 6:53
  • You are welcome. Please add the answer and close. Commented Jun 29, 2017 at 7:03

2 Answers 2

Reset to default
0

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.

Improve this answer
0
0

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.

Improve this answer
2
  • 2
    ping is almost never a valid troubleshooting tool. If you need to debug SSH connections do a tcptraceroute to port 22 since SSH uses TCP on port 22. You have even discovered yourself in the last sentence how much time you can use relying on ping being fine, but not the rest. So DO NOT USE ping to troubleshoot TCP/UDP connection problems. Commented Sep 6, 2019 at 18:19
  • Indeed. My faith in ping is misplaced. tcptraceroute is how I finally figured out there was weirdness happening. The O/P also could ping but not SSH, so I would offer tcptraceroute as an enhancement to diagnosis. Commented Sep 7, 2019 at 20:57

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.