0

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.
  • 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 – Gilson Varghese Jun 29 '17 at 6:37
  • ssh.service - OpenBSD Secure Shell server – Bhavya Jain Jun 29 '17 at 6:41
  • Please put the complete error log. Have you allowed ssh through firewall with sudo ufw allow 22 – Gilson Varghese Jun 29 '17 at 6:45
  • 2
    sudo ufw allow 22. Worked for me.Thanks @GilsonVarghese – Bhavya Jain Jun 29 '17 at 6:53
  • You are welcome. Please add the answer and close. – Gilson Varghese Jun 29 '17 at 7:03
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.

  • 1
    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. – Patrick Mevzek Sep 6 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. – TRT 1968 Sep 7 at 20:57
-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.

  • Please explain, why this solves your problem. – countermode Jun 29 '17 at 8:06

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.