[SOLVED] Problem in SSHing arch from a different machine

spandan.anupam · 2018-12-25 06:46:52

So Have recently installed arch on one of my machines. I do not know if it is a problem of my router, or the OS, but I cannot SSH into the arch machine from my MacBook. More so, I cannot even get a ping from the assigned IPs of the machines. I searched for this issue, most of them were firewall oriented, but I do not have ufw installed, and my MacBook can SSH into other machines.

EDIT:
Yes, sshd is running, I get no errors. I just cannot ping one machine from another on the same router.

By cannot ping, I mean I really cannot ping.

PING 192.168.1.37 (192.168.1.37) 56(84) bytes of data.
From 192.168.1.33 icmp_seq=1 Destination Host Unreachable
From 192.168.1.33 icmp_seq=5 Destination Host Unreachable
From 192.168.1.33 icmp_seq=8 Destination Host Unreachable
From 192.168.1.33 icmp_seq=11 Destination Host Unreachable
From 192.168.1.33 icmp_seq=12 Destination Host Unreachable
From 192.168.1.33 icmp_seq=14 Destination Host Unreachable
From 192.168.1.33 icmp_seq=15 Destination Host Unreachable
^C
--- 192.168.1.37 ping statistics ---
16 packets transmitted, 0 received, +7 errors, 100% packet loss, time 214ms
pipe 4

It seems as if they are not connected, but they are on the same router.

Attached is my results for ifconfig as well.

enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.33  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::2474:3c0d:9cfc:dbad  prefixlen 64  scopeid 0x20<link>
        ether 94:de:80:1f:76:37  txqueuelen 1000  (Ethernet)
        RX packets 106867  bytes 76025943 (72.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 85887  bytes 29715654 (28.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1817  bytes 180584 (176.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1817  bytes 180584 (176.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

And the error on putting in ssh:

ssh: connect to host 192.168.1.37 port 22: No route to host

And for further information, the sshd.service status:

   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2018-12-25 10:24:49 IST; 11h ago
 Main PID: 356 (sshd)
    Tasks: 1 (limit: 4317)
   Memory: 6.5M
   CGroup: /system.slice/sshd.service
           `-356 /usr/bin/sshd -D

Dec 25 10:24:49 MULTIVAC systemd[1]: Started OpenSSH Daemon.
Dec 25 10:24:51 MULTIVAC sshd[356]: Server listening on 0.0.0.0 port 22.
Dec 25 10:24:51 MULTIVAC sshd[356]: Server listening on :: port 22.
Dec 25 10:35:53 MULTIVAC sshd[2231]: Accepted password for spandan from ::1 port 47718 ssh2
Dec 25 10:35:53 MULTIVAC sshd[2231]: pam_unix(sshd:session): session opened for user spandan by (uid=0)
Dec 25 10:35:58 MULTIVAC sshd[2231]: pam_unix(sshd:session): session closed for user spandan
Dec 25 10:36:28 MULTIVAC sshd[2281]: Accepted password for spandan from ::1 port 47720 ssh2
Dec 25 10:36:28 MULTIVAC sshd[2281]: pam_unix(sshd:session): session opened for user spandan by (uid=0)

Below is the output of joutnalctl

-- Logs begin at Sun 2018-12-23 18:23:21 IST, end at Tue 2018-12-25 18:57:33 IST. --
Dec 23 18:23:21 archlinux kernel: Linux version 4.19.12-arch1-1-ARCH (builduser@heftig-21538) (gcc version 8.2.1 20181127 (GCC)) #1 SMP PREEMPT Fri Dec 21 13:56:54 UTC 2018
Dec 23 18:23:21 archlinux kernel: Command line: initrd=\initramfs-linux.img initrd=\initramfs-linux-fallback.img root=LABEL=arch_os rw
Dec 23 18:23:21 archlinux kernel: KERNEL supported cpus:
Dec 23 18:23:21 archlinux kernel:   Intel GenuineIntel
Dec 23 18:23:21 archlinux kernel:   AMD AuthenticAMD
Dec 23 18:23:21 archlinux kernel:   Centaur CentaurHauls
Dec 23 18:23:21 archlinux kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Dec 23 18:23:21 archlinux kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Dec 23 18:23:21 archlinux kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Dec 23 18:23:21 archlinux kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Dec 23 18:23:21 archlinux kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
Dec 23 18:23:21 archlinux kernel: BIOS-provided physical RAM map:
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] reserved
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x0000000020000000-0x00000000201fffff] reserved
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x0000000020200000-0x000000003fffffff] usable
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x0000000040000000-0x00000000401fffff] reserved
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x0000000040200000-0x00000000d982afff] usable
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000d982b000-0x00000000d9dc6fff] reserved
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000d9dc7000-0x00000000d9dc7fff] ACPI data
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000d9dc8000-0x00000000d9ee9fff] ACPI NVS
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000d9eea000-0x00000000da681fff] reserved
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000da682000-0x00000000da682fff] usable
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000da683000-0x00000000da6c5fff] ACPI NVS
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000da6c6000-0x00000000dadd5fff] usable
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000dadd6000-0x00000000dafdbfff] reserved
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000dafdc000-0x00000000daffffff] usable
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000db800000-0x00000000df9fffff] reserved
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
Dec 23 18:23:21 archlinux kernel: BIOS-e820: [mem 0x0000000100000000-0x000000011f5fffff] usable
Dec 23 18:23:21 archlinux kernel: NX (Execute Disable) protection: active
Dec 23 18:23:21 archlinux kernel: e820: update [mem 0xc8250018-0xc8260057] usable ==> usable
Dec 23 18:23:21 archlinux kernel: e820: update [mem 0xc8250018-0xc8260057] usable ==> usable
Dec 23 18:23:21 archlinux kernel: e820: update [mem 0xc823f018-0xc824f057] usable ==> usable
Dec 23 18:23:21 archlinux kernel: e820: update [mem 0xc823f018-0xc824f057] usable ==> usable
Dec 23 18:23:21 archlinux kernel: extended physical RAM map:
Dec 23 18:23:21 archlinux kernel: reserve setup_data: [mem 0x0000000000000000-0x000000000009efff] usable

ngoonee wrote:

You have a general network connectivity issue. If I were to guess, it would be that your router is somehow filtering traffic between your wired and wireless. This can happen if the wireless network is configured as a 'guest' network (at least for ASUS routers). Check your router's settings for similar, this is unlikely to be an Arch issue.

So it seems that this is not a problem in my arch machine, rather, it is some issue with my router, as pointed out by ngoonee.

Last edited by spandan.anupam (2018-12-26 07:25:06)

jasonwryan · 2018-12-25 07:29:23

Is sshd running? What errors do you get? What is printed to the journal? See https://bbs.archlinux.org/viewtopic.php?id=57855

spandan.anupam · 2018-12-25 13:33:20

jasonwryan wrote:

Is sshd running? What errors do you get? What is printed to the journal? See https://bbs.archlinux.org/viewtopic.php?id=57855

I edited my question. You may look at that.

Trilby · 2018-12-25 14:43:15

What do you mean you get no errors? Do ssh and ping commands just silently return you to another prompt? You say you cannot ssh and cannot ping. Don't tell us, show us:
https://bbs.archlinux.org/viewtopic.php?id=57855

(edit: I just realized this is the same link JWR pointed you too. You really should read it.)

Last edited by Trilby (2018-12-25 15:17:05)

spandan.anupam · 2018-12-25 16:03:49

Trilby wrote:

What do you mean you get no errors? Do ssh and ping commands just silently return you to another prompt? You say you cannot ssh and cannot ping. Don't tell us, show us:
https://bbs.archlinux.org/viewtopic.php?id=57855
(edit: I just realized this is the same link JWR pointed you too. You really should read it.)

Yep. So I put everything in my description, as much as I could think of.

Trilby · 2018-12-25 16:13:57

Thanks, that's a better start. Why are you ssh'ing to 192.168.1.37 when ifconfig is showing the IP as 192.168.1.33? That ifconfig output is from the arch machine, right?

Is the macbook also connected via wired ethernet to the lan, or is it on wireles wlan?

seth · 2018-12-25 16:18:44

That's at best the head of journalctl, also you're trying to connect 192.168.1.37, but the ifconfig (please switch to the ip tools) is from 192.168.1.33 (ie. your macbook?)

spandan.anupam · 2018-12-25 17:25:04

Trilby wrote:

Thanks, that's a better start. Why are you ssh'ing to 192.168.1.37 when ifconfig is showing the IP as 192.168.1.33? That ifconfig output is from the arch machine, right?
Is the macbook also connected via wired ethernet to the lan, or is it on wireles wlan?

My mac is connected via wifi. This is wired. 37 is for my macbook. 33 is the ip of my arch machine

spandan.anupam · 2018-12-25 17:26:42

seth wrote:

That's at best the head of journalctl, also you're trying to connect 192.168.1.37, but the ifconfig (please switch to the ip tools) is from 192.168.1.33 (ie. your macbook?)

The if config has been run from my arch machine. The 33 is the address of the arch. 37 is my mac's address. And about the journalctl, I will check again, but it just gave me this.

seth · 2018-12-25 17:29:41

So you're actually trying to ping and ssh into your macbook?

Trilby · 2018-12-25 17:31:01

But you are trying to ssh to 192.168.1.37? If what you say is correct, that's the IP of your macbook not the arch machine, and you are trying to ssh to that IP from the macbook.

However, there may be another problem: many routers have separate subnets for lan and wlan - often with a setting in the router to have them separate or together. If they are seperate, this will never work. From what you have told us of the IP addresses this may not be the case, but frankly not much of what you are telling us is adding up.

Last edited by Trilby (2018-12-25 17:31:47)

spandan.anupam · 2018-12-25 17:55:51

seth wrote:

So you're actually trying to ping and ssh into your macbook?

Yes. I am trying it both ways. Pinging and sshing from the macbook doesn't work either.

Trilby · 2018-12-25 17:56:49

Ok then, is sshd running on the macbook? What's the ifconfig output on the macbook?

Overall, we don't need to hear vague summaries of the things you've tried, we need to see raw results: commands and output. And we need to know what output is from what machine and specifically which command generated the output. We've been getting at-best mix-and-match output this whole thread.

Last edited by Trilby (2018-12-25 18:00:33)

spandan.anupam · 2018-12-25 18:00:01

Trilby wrote:

But you are trying to ssh to 192.168.1.37? If what you say is correct, that's the IP of your macbook not the arch machine, and you are trying to ssh to that IP from the macbook.
However, there may be another problem: many routers have separate subnets for lan and wlan - often with a setting in the router to have them separate or together. If they are seperate, this will never work. From what you have told us of the IP addresses this may not be the case, but frankly not much of what you are telling us is adding up.

I am trying it both ways. Pinging and sshing from the arch and from the mac both. Neither of them work. The output is pretty much the same, host unreachable. For the record, I have sshd my macbook and from my macbook from a different linux machine at work, and it does work. So it is either a problem of the OS or the router.

I searched for this, and thought maybe it is a problem of the router and it had access controls turned on, and isn't allowing devices to access each other. But it seems that the option SSH is not there in the router access control menu. So I am not sure if this is a problem from the router's part or of the OS

Trilby · 2018-12-25 18:01:40

Again, "pretty much the same" is not actual output. Those tiny differences you are ignoring matter. But if "pretty much the same" is all you'll give us after countless requests, starting from polite to getting much more demanding, then I guess you're "pretty much screwed".

spandan.anupam · 2018-12-25 18:05:41

Trilby wrote:

Again, "pretty much the same" is not actual output. Those tiny differences you are ignoring matter. But if "pretty much the same" is all you'll give us after countless requests, starting from polite to getting much more demanding, then I guess you're "pretty much screwed".

yep. I was just changing from my other machine. Here is the output:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
	inet 127.0.0.1 netmask 0xff000000 
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
XHC20: flags=0<> mtu 0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether d0:81:7a:ce:89:36 
	inet6 fe80::85d:ad86:5061:1433%en0 prefixlen 64 secured scopeid 0x5 
	inet 192.168.1.37 netmask 0xffffff00 broadcast 192.168.1.255
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
	ether 02:81:7a:ce:89:36 
	media: autoselect
	status: inactive
awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484
	ether e2:b9:81:13:e1:2e 
	inet6 fe80::e0b9:81ff:fe13:e12e%awdl0 prefixlen 64 scopeid 0x7 
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
	options=60<TSO4,TSO6>
	ether 9a:00:13:34:dc:00 
	media: autoselect <full-duplex>
	status: inactive
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=63<RXCSUM,TXCSUM,TSO4,TSO6>
	ether 9a:00:13:34:dc:00 
	inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
	inet6 fe80::9800:13ff:fe34:dc00%bridge0 prefixlen 64 scopeid 0x9 
	Configuration:
		id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
		maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
		root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
		ipfilter disabled flags 0x2
	member: en1 flags=3<LEARNING,DISCOVER>
	        ifmaxaddr 0 port 8 priority 0 path cost 0
	nd6 options=201<PERFORMNUD,DAD>
	media: <unknown type>
	status: inactive
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
	inet6 fe80::b9aa:40c8:924d:5fd4%utun0 prefixlen 64 scopeid 0xa 
	nd6 options=201<PERFORMNUD,DAD>
utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
	inet6 fe80::3e74:f989:4349:6ad%utun1 prefixlen 64 scopeid 0xb 
	nd6 options=201<PERFORMNUD,DAD>

I do not know the systemctl status counterpart here, so I did this instead:

spandan@spandan ~ $ ssh spandan@192.168.1.37
The authenticity of host '192.168.1.37 (192.168.1.37)' can't be established.
ECDSA key fingerprint is SHA256:jq+fIZyo3ODNE5uLhueDtuFE7PWXxD0bqjbSbtUvmco.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.37' (ECDSA) to the list of known hosts.

This should do. Please let me know if you need anything. I am new, so I do not have the idea of what exactly is needed. I will do that ASAP. Please do consider that I need to read your request before posting, as I really do not know what to post. Your reply came as I was answering Seth's question. I will come to it as soon as I see it.

Last edited by spandan.anupam (2018-12-25 18:08:39)

jasonwryan · 2018-12-25 18:07:19

Use the verbose switch -vvv from the mac to the arch box and paste the output here.

spandan.anupam · 2018-12-25 18:11:27

jasonwryan wrote:

Use the verbose switch -vvv from the mac to the arch box and paste the output here.

Could you please elaborate? It says verbose command doesn't exist or switch command doesn't exist. And what exactly is "from the Mac to arch box?" thanks.

jasonwryan · 2018-12-25 18:13:40

ssh -vvv spandan@archbox

spandan.anupam · 2018-12-25 18:17:40

jasonwryan wrote:

ssh -vvv spandan@archbox

It just stays at this:

spandan@spandan ~ $ ssh -vvv spandan@192.168.1.33
OpenSSH_7.8p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/spandan/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.1.33 is address
debug2: ssh_connect_direct
debug1: Connecting to 192.168.1.33 [192.168.1.33] port 22.
debug1: connect to address 192.168.1.33 port 22: Operation timed out
ssh: connect to host 192.168.1.33 port 22: Operation timed out

jasonwryan · 2018-12-25 18:23:12

Please paste the output of `systemctl list-unit-files --state=enabled` and `iptables -S` from 192.168.1.33

spandan.anupam · 2018-12-25 18:27:18

jasonwryan wrote:

Please paste the output of `systemctl list-unit-files --state=enabled` and `iptables -S` from 192.168.1.33

Both of these are from 192.168.1.33

For the first one:

UNIT FILE               STATE  
autovt@.service         enabled
dhcpcd.service          enabled
display-manager.service enabled
gdm.service             enabled
getty@.service          enabled
sshd.service            enabled
remote-fs.target        enabled

7 unit files listed.

For iptables:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Last edited by spandan.anupam (2018-12-25 18:29:51)

seth · 2018-12-25 19:31:26

Output of

route -n get default
route -n get 192.168.1.33
netstat -nr

on the Mac?

spandan.anupam · 2018-12-25 20:09:32

seth wrote:

Output of

route -n get default
route -n get 192.168.1.33
netstat -nr

on the Mac?

   route to: default
destination: default
       mask: default
    gateway: 192.168.1.1
  interface: en0
      flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0

and

   route to: 192.168.1.33
destination: 192.168.1.0
       mask: 255.255.255.0
  interface: en0
      flags: <UP,DONE,CLONING,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500       -65

and for netstat -nr

Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.1.1        UGSc           83        0     en0       
default            link#9             UCSI            0        0 bridge0      !
127                127.0.0.1          UCS             0        0     lo0       
127.0.0.1          127.0.0.1          UH              1     2514     lo0       
169.254            link#5             UCS             0        0     en0      !
192.168.1          link#5             UCS             1        0     en0      !
192.168.1.1/32     link#5             UCS             2        0     en0      !
192.168.1.1        e8:cc:18:c4:b2:a4  UHLWIir        15       69     en0   1169
192.168.1.37/32    link#5             UCS             0        0     en0      !
192.168.1.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        9     en0      !
192.168.2          link#9             UC              2        0 bridge0      !
192.168.2.255      ff.ff.ff.ff.ff.ff  UHLWbI          0        9 bridge0      !
224.0.0/4          link#5             UmCS            1        0     en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0       
255.255.255.255/32 link#5             UCS             0        0     en0      !

Internet6:
Destination                             Gateway                         Flags         Netif Expire
default                                 fe80::1%en0                     UGcI            en0       
default                                 fe80::%utun0                    UGcI          utun0       
default                                 fe80::%utun1                    UGcI          utun1       
::1                                     ::1                             UHL             lo0       
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0       
fe80::1%lo0                             link#1                          UHLI            lo0       
fe80::%en0/64                           link#5                          UCI             en0       
fe80::1%en0                             e8:cc:18:c4:b2:a4               UHLWIir         en0       
fe80::85d:ad86:5061:1433%en0            d0:81:7a:ce:89:36               UHLI            lo0       
fe80::%awdl0/64                         link#7                          UCI           awdl0       
fe80::e0b9:81ff:fe13:e12e%awdl0         e2:b9:81:13:e1:2e               UHLI            lo0       
fe80::%bridge0/64                       link#9                          UCI         bridge0       
fe80::9800:13ff:fe34:dc00%bridge0       9a.0.13.34.dc.0                 UHLI            lo0       
fe80::%utun0/64                         fe80::b9aa:40c8:924d:5fd4%utun0 UcI           utun0       
fe80::b9aa:40c8:924d:5fd4%utun0         link#10                         UHLI            lo0       
fe80::%utun1/64                         fe80::3e74:f989:4349:6ad%utun1  UcI           utun1       
fe80::3e74:f989:4349:6ad%utun1          link#11                         UHLI            lo0       
ff01::%lo0/32                           ::1                             UmCI            lo0       
ff01::%en0/32                           link#5                          UmCI            en0       
ff01::%awdl0/32                         link#7                          UmCI          awdl0       
ff01::%bridge0/32                       link#9                          UmCI        bridge0       
ff01::%utun0/32                         fe80::b9aa:40c8:924d:5fd4%utun0 UmCI          utun0       
ff01::%utun1/32                         fe80::3e74:f989:4349:6ad%utun1  UmCI          utun1       
ff02::%lo0/32                           ::1                             UmCI            lo0       
ff02::%en0/32                           link#5                          UmCI            en0       
ff02::%awdl0/32                         link#7                          UmCI          awdl0       
ff02::%bridge0/32                       link#9                          UmCI        bridge0       
ff02::%utun0/32                         fe80::b9aa:40c8:924d:5fd4%utun0 UmCI          utun0       
ff02::%utun1/32                         fe80::3e74:f989:4349:6ad%utun1  UmCI          utun1

/dev/zero · 2018-12-25 20:58:36

A simple way to test whether an ssh service is actually listening on a remote machine is to use telnet. If you run "telnet 192.168.1.33 22" you should see something like this:

$ telnet 192.168.1.33 22
Trying 192.168.1.33...
Connected to 192.168.1.33.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.9

Notice how the sshd service displays a banner showing its version. (Press '^]' followed by Ctrl-D to terminate the telnet session after checking the banner.)

The benefit of doing this is if you can't even get a telnet banner then you know it is either a network issue or a firewall issue.

Whereas, if telnet shows you the banner for your ssh server, then you know that the network and firewall are okay, and it will be better to focus on the ssh client and sshd service configurations.

Last edited by /dev/zero (2018-12-25 20:59:11)

Arch Linux

#1 2018-12-25 06:46:52

[SOLVED] Problem in SSHing arch from a different machine

#2 2018-12-25 07:29:23

Re: [SOLVED] Problem in SSHing arch from a different machine

#3 2018-12-25 13:33:20

Re: [SOLVED] Problem in SSHing arch from a different machine

#4 2018-12-25 14:43:15

Re: [SOLVED] Problem in SSHing arch from a different machine

#5 2018-12-25 16:03:49

Re: [SOLVED] Problem in SSHing arch from a different machine

#6 2018-12-25 16:13:57

Re: [SOLVED] Problem in SSHing arch from a different machine

#7 2018-12-25 16:18:44

Re: [SOLVED] Problem in SSHing arch from a different machine

#8 2018-12-25 17:25:04

Re: [SOLVED] Problem in SSHing arch from a different machine

#9 2018-12-25 17:26:42

Re: [SOLVED] Problem in SSHing arch from a different machine

#10 2018-12-25 17:29:41

Re: [SOLVED] Problem in SSHing arch from a different machine

#11 2018-12-25 17:31:01

Re: [SOLVED] Problem in SSHing arch from a different machine

#12 2018-12-25 17:55:51

Re: [SOLVED] Problem in SSHing arch from a different machine

#13 2018-12-25 17:56:49

Re: [SOLVED] Problem in SSHing arch from a different machine

#14 2018-12-25 18:00:01

Re: [SOLVED] Problem in SSHing arch from a different machine

#15 2018-12-25 18:01:40

Re: [SOLVED] Problem in SSHing arch from a different machine

#16 2018-12-25 18:05:41

Re: [SOLVED] Problem in SSHing arch from a different machine

#17 2018-12-25 18:07:19

Re: [SOLVED] Problem in SSHing arch from a different machine

#18 2018-12-25 18:11:27

Re: [SOLVED] Problem in SSHing arch from a different machine

#19 2018-12-25 18:13:40

Re: [SOLVED] Problem in SSHing arch from a different machine

#20 2018-12-25 18:17:40

Re: [SOLVED] Problem in SSHing arch from a different machine

#21 2018-12-25 18:23:12

Re: [SOLVED] Problem in SSHing arch from a different machine

#22 2018-12-25 18:27:18

Re: [SOLVED] Problem in SSHing arch from a different machine

#23 2018-12-25 19:31:26

Re: [SOLVED] Problem in SSHing arch from a different machine

#24 2018-12-25 20:09:32

Re: [SOLVED] Problem in SSHing arch from a different machine

#25 2018-12-25 20:58:36

Re: [SOLVED] Problem in SSHing arch from a different machine

Board footer