Fedora: SSH connection refused

7,659

Solution 1

I am assuming you want to connect to the enp2s0f0 interface of the server (all other interfaces (except loopback) are DOWN).

From the logs you can see that DHCP requests on that interface are timing out. From the output of ip a you can see that the interface only has an IPv6 link-local address.

You should either fix DHCP or manually assign an IPv4 address to the interface (ip addr add x.x.x.x/24 dev enp2s0f0). Alternatively you can use IPv6.

EDIT: More questions:

  • Are the 2 machines directly connected?
  • Can you tell us more about the client? What do ip a, ip r, and iptables-save output on the client?
  • What does iptables-save output on the server? Note that iptables -vnL doesn't print all the rules.
  • Can you ping the server from the client? (e.g. ping 192.168.10.10)
  • Can you arp ping the server from the client? (e.g. arping -I eth0 192.168.10.10) do you get a reply? is the MAC address in the reply correct? (it should be 20:89:84:77:4b:2a).
  • If you run tcpdump on the server (tcpdump -n -i any port 22) and try ssh-ing in what does tcpdump output?

EDIT 2: Your client and server should have different IP addresses. Make the client 192.168.10.9 and the server 192.168.10.10.

Solution 2

I think you're trying to connect to the wrong IP.

In the ss command you see something like 'Local Address' 192.168.122.1, but you try to connect to the IP 192.168.10.10.

Would you please give us the network configuration of the server? It would be enough if you paste the whole output of executing ip a in the server.

Solution 3

I think that your rule is never reached because of the REJECT rule (just before), which is applied to all the packets that don't match preceding rules.

What happen if you use :

iptables-I INPUT 1-p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

(i.e. insert the rule at the beginning of the table)

Edit : some more suggestions

  • Check that sshd is actually listening :

    ss --tcp --listening -n -p
    
  • Add the -v option when showing the iptables (this adds a packet count for each rule, so that you can see which one are used)

  • try both IPv4 and IPv6 (with -4 and -6 options for the ssh command)

Share:
7,659
user6039980
Author by

user6039980

Updated on September 18, 2022

Comments

  • user6039980
    user6039980 over 1 year

    I'm trying to connect my Ubuntu host to a fedora laptop via ssh in order to share files over Ethernet. I have OpenSSH server started on fedora (via service sshd start) and I already executed the command iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT in order to allow incoming ssh connections. Moreover the IPv4 address on the server is set by ifconfig enp2s0f0 192.168.10.10 netmask 255.255.255.0 up. But whenever I type ssh -A -Y 192.168.10.10 or ssh -4 192.168.10.10; I get always an error message showing "ssh: connect to host 192.168.10.10 port 22: Connection refused", even after having the firewall disabled using service iptables stop.

    iptables -n -L -v output on fedora shows:

    Chain INPUT (policy ACCEPT 11652 packets, 2859K bytes) pkts bytes target prot opt in out source destination

    Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination

    Chain OUTPUT (policy ACCEPT 11759 packets, 1665K bytes) pkts bytes target prot opt in out source destination

    iptables -n -L -v output on ubuntu shows:

    Chain INPUT (policy ACCEPT 210K packets, 16M bytes) pkts bytes target prot opt source destination

    Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt source destination

    Chain OUTPUT (policy ACCEPT 209K packets, 15M bytes) pkts bytes target prot opt source destination

    Executing route -n within the server, gives the following output:

    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 enp2s0f0
    192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
    

    executing sudo route -n within the Ubuntu client machine, gives the following output:

    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         192.168.10.1    0.0.0.0         UG    100    0        0 enp14s0
    169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp14s0
    192.168.10.0    0.0.0.0         255.255.255.0   U     100    0        0 enp14s0
    

    ip r on client machine:

    default via 192.168.10.1 dev enp14s0  proto static  metric 100 
    169.254.0.0/16 dev enp14s0  scope link  metric 1000 
    192.168.10.0/24 dev enp14s0  proto kernel  scope link  src 192.168.10.10  metric 100 
    

    arping -I enp14s0 192.168.10.10 on client machine, got stuck at:

    ARPING 192.168.10.10 from 192.168.10.10 enp14s0
    

    output of sudo tcpdump -n -i any port 22:

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
    01:09:28.363302 IP 192.168.10.10.58906 > 192.168.10.10.22: Flags [S], seq 506055200, win 43690, options [mss 65495,sackOK,TS val 33913 ecr 0,nop,wscale 7], length 0
    01:09:28.363357 IP 192.168.10.10.58906 > 192.168.10.10.22: Flags [R.], seq 0, ack 506055201, win 0, length 0
    01:09:28.354895 IP 192.168.10.10.58906 > 192.168.10.10.22: Flags [S], seq 2349767060, win 43690, options [mss 65495,sackOK,TS val 34911 ecr 0,nop,wscale 7], length 0
    01:09:28.354948 IP 192.168.10.10.22 > 192.168.10.10.58908: Flags [R.], seq 0, ack 2349767061, win 0, length 0
    

    Does anyone have any idea?

    Your help will be much appreciated.

  • user6039980
    user6039980 over 7 years
    the error still occurs after executing that command.
  • MariusMatutiae
    MariusMatutiae over 7 years
    I cannot see any REJECT in the OP: am I blind or mad?
  • bwt
    bwt over 7 years
    @MariusMatutiae the question was edited, there is now more info and the firewall is completely disabled (so this is not a firewall problem as I thought at first)
  • user6039980
    user6039980 over 7 years
    please check my question's last update.
  • user6039980
    user6039980 over 7 years
    I was wrongly thinking that the ipv4 settings on the client interface points to the server ip, while it is supposed to be the client ip. changing the ip solved the problem. Thanks.