DEV Community: Melissa

ssh from 3 places: Why TinyCore inside Oracle VM worked when PuTTY and PowerShell didn't

Melissa — Wed, 14 Oct 2026 13:03:15 +0000

VyOS SSH - L4 Handshake vs L7 Banner / Keys / Auth

VyOS eth0 (LAN) = 192.168.56.101
VyOS eth1 (WAN) = 10.0.3.15

1) SSH FROM PowerShell

A. While SSH DISABLED:
Error: ssh: connect to host 192.168.56.101 port 22: Connection timed out

B. Pre-checks (disabled):
nmap -p 22 VyOS_IP = NA
ncat -v VyOS_IP 22 =NA
Keys? = NA

C. Pre-checks (after enable):
nmap = NA
ncat banner = NA
Keys = NA

D. Login test (only if pre-checks green):
ssh user@VyOS_IP =
Result = NA

Conclusion:
L3/L4 Testing Limitation – Windows Host to VyOS LAN (192.168.56.101)

Objective: Verify SSH (TCP 22) access to VyOS LAN interface from Windows PowerShell using Test-NetConnection, nmap, and ncat.

Result: N/A – Failure at L3 (not L4)

L3 Test from Windows PowerShell (PS C:\Windows\system32>): ping 192.168.56.101 -> Request timed out. 100% loss (4/4)

Test-NetConnection 192.168.56.101 -Port 22
-> TcpTestSucceeded : False / No response

C:\Program Files (x86)\Nmap\nmap.exe -p 22 192.168.56.101
-> No output / hang – port state filtered (no L3 response)

ncat -v 192.168.56.101 22
-> No connection

L3 Test from VyOS:
ping 192.168.56.1 (Windows Host-Only adapter)
-> Destination Host Unreachable
Root Cause:
VirtualBox > VyOS > Settings > Network > Adapter 1 (eth0)
Current: Attached to: Internal Network
Required for Windows access: Attached to: Host-Only Adapter

Internal Network mode intentionally excludes the Windows host by design.
Therefore Windows can never reach Oracle VM at L3, so L4/L7 SSH tests from PowerShell are impossible.

Changing Adapter 1 to Host-Only Adapter is blocked – OK button greyed out while VM is running. Creating a new Host-Only adapter in VirtualBox Network Manager fails on this host. Powering off to change risks DHCP change of LAN/WAN IPs.

Conclusion: L3 unreachable between Windows and Oracle VM. Therefore L4 port 22 and L7 SSH app tests from PowerShell are N/A. This is a Windows/VirtualBox boundary issue, not a VyOS ssh service failure. Demonstrates effective isolation of management plane. SSH was verified locally on VyOS via show configuration and ss -tlnp.

2) SSH FROM PuTTY

A. While SSH DISABLED:
Error popup: [ ] NA

B. Pre-checks (disabled):
nmap (from PowerShell) = NA
ncat (from PowerShell) = NA

C. Pre-checks (after enable):
nmap = NA
ncat = NA

D. Login test (only if green):
PuTTY connection type: SSH, port 22
Result / auth: NA

Conclusion:

PuTTY SSH Test to VyOS LAN – Not Tested

PuTTY test to 192.168.56.101:22 – Not performed / Not Applicable.

Reason: See PowerShell L3 failure section. Windows host has no Layer 3 connectivity to Oracle VM VyOS LAN (eth0 attached to Internal Network, not Host-Only Adapter).

ping 192.168.56.101 = Request timed out (100% loss)
ping 192.168.56.1 from VyOS = Destination Host Unreachable

PuTTY requires L3 to establish TCP 22. As L3 is down at the Windows/VirtualBox boundary, any PuTTY attempt would timeout without ever reaching VyOS ssh service. Test would be irrelevant.

3) SSH FROM TinyCore VM inside Oracle VM

A. While SSH DISABLED:
Error: ssh not found

B. Pre-checks (disabled):
nmap -p 22 VyOS_IP = NA
ncat -v VyOS_IP 22 = NA
Keys? =

C. Pre-checks (after enable):
nmap = NA
ncat banner = NA
Keys = NA

D. Login test (only if green):
ssh user@VyOS_IP =
Result = NA

TinyCore VM - Connectivity Tests to VyOS LAN (192.168.56.101)

L4 Tooling Issue on TinyCore:

I wanted to do an L4 port check from TinyCore to VyOS.

nmap - Attempted install via:
tce-load -wi nmap.tcz
Failed to install on the base TinyCore image.
Alternative L4 tool: ss - The tool you suggested in this chat, sudo ss -tlnp, was tried as an alternative to nmap. This also did not work as an L4 probe from the TinyCore side due to TinyCore's minimal base install.

As a result, we used ping for L3 and the ssh client itself as the L4 test.

L3 - Ping to VyOS LAN - SUCCESSFUL:
ping 192.168.56.101
Result: 3 packets transmitted, 3 received, 0% packet loss - L3 is up.

L4 - SSH from TinyCore while SSH is DISABLED on VyOS:
ssh vyos@192.168.56.101
Error message:
ssh: connect to host 192.168.56.101 port 22: Connection refused
L4/L7 - SSH from TinyCore AFTER SSH was enabled on VyOS - FAILED:

After enabling SSH on VyOS, the SSH attempt from TinyCore still did not succeed.
ssh vyos@192.168.56.101
Error message:
- still Connection refused / timed out]
Next Step: This failure, plus the observation that SSH doesn't appear to stay enabled on VyOS after a reboot/save, will be investigated in the next section on the VyOS VM.

## ssh from TinyCore finally succeeded, read on for details:

The client was missing

tc@box:~$ ssh -v vyos@192.168.56.101
-sh: ssh: not found

TinyCore doesn't include SSH. The fix was one command:

tce-load -wi openssh

After that, the same ssh command connected. That was my first ever SSH - TinyCore .102 to VyOS .101. While checking the ARP table I also found 192.168.56.20 alive and pingable on the same host-only wire. Three hosts, not two.

VyOS was innocent

I suspected VyOS for hours, but sudo ss -tlnp src 192.168.56.101 showed the truth: sshd pid 4670 LISTEN 192.168.56.101:22. The daemon was waiting the whole time. I just had no client to call it with.

Why VM-to-VM worked but PowerShell/PuTTY didn't

Both VMs live inside VirtualBox Host-Only 192.168.56.0/24 - same L2 cable. TinyCore .102 to VyOS .101 needs no firewall. PowerShell/PuTTY from Windows has to go through the 192.168.56.1 host adapter and Windows Firewall, which blocks the path. Same listener, different door.

Why Scapy Instead of Ping? - Layer Locking

Melissa — Mon, 12 Oct 2026 11:24:28 +0000

Reason for layer locking: More accurate result.
Operating systems are generic, Scapy frames are specific, so Scapy frames give troubleshooting accuracy.

Environment: VyOS router in Oracle VM VirtualBox.

LAYER 2 - Data Link Test

Steps:

Put listener on eth0 on VyOS
Run Scapy frame

Scapy frame to send (L2 broadcast - locks to L2):

Layer 2 Lock Test - Pure L2 - VyOS eth0

from scapy.all import *
p = Ether(dst="ff:ff:ff:ff:ff:ff")
hexdump(p)

0000 FF FF FF FF FF FF 00 00 00 00 00 00 90 00

Breakdown:
FF FF FF FF FF FF = dst - broadcast all MACs
00 00 00 00 00 00 = src - zero - Scapy default when no MAC bound
90 00 = type - Loopback - blank L2 frame

srp(p, iface="eth0", timeout=3)

Begin emission:
Finished sending 1 packets.
Received 0 packets, got 0 answers, remaining 1 packets

Result: L2 TX works - frame was put on wire, layer-locked, no IP.

LAYER 3 - Network Layer Test

L3 Test - Hardcoded MAC + Static IP - VyOS eth0

Goal: Exclude DHCP and ARP to prove L3 TX.

STEP 1 - Find MAC (Linux command)
$ cat /sys/class/net/eth0/address
08:00:27:bf:9a:64

STEP 2 - Put static IP (VyOS config)
configure
set interfaces ethernet eth0 address 192.168.56.10/24
commit
save
exit

STEP 3 - Put listener in background (same terminal)
$ sudo tcpdump -i eth0 -e -n icmp &
[1] 3047
tcpdump: listening on eth0, link-type EN10MB

STEP 4 - Scapy - hardcode MAC and IP to kill ARP
$ sudo python3

from scapy.all import *
my_mac = "08:00:27:bf:9a:64"
my_ip = "192.168.56.10"
p = Ether(dst=my_mac, src=my_mac) / IP(dst=my_ip, src=my_ip) / ICMP()
hexdump(p)

0000 08 00 27 BF 9A 64 08 00 27 BF 9A 64 08 00 45 00..'.d..'.d..E.
0010 00 1C 00 01 00 00 40 01 89 7B C0 A8 38 0A C0 A8......@..{..8...
0020 38 0A 08 00 F7 FF 00 00 00 00 8.........

Breakdown:
08 00 27 BF 9A 64 = dst MAC = your eth0 (hardcoded)
08 00 27 BF 9A 64 = src MAC = your eth0 (hardcoded)
08 00 = Type = IPv4
45 00 = IP version / header
C0 A8 38 0A = hex for 192.168.56.10 src
C0 A8 38 0A = hex for 192.168.56.10 dst
08 00 = ICMP Echo Request

srp(p, iface="eth0", timeout=3)

Begin emission:
Finished sending 1 packets.
13:38:43.976853 08:00:27:bf:9a:64 > 08:00:27:bf:9a:64, ethertype IPv4 (0x0800), length 42: 192.168.56.10 > 192.168.56.10: ICMP echo request
.
Received 0 packets, got 0 answers, remaining 1 packets

RESULT:
L3 TX UP - Confirmed.
tcpdump saw the frame on eth0 (line above), proving Layer 2 and Layer 3 headers were built correctly and transmitted with no DHCP/ARP.

Received 0 is EXPECTED here because we pinged ourselves (src=dst). Linux routes self-pings via lo, not eth0, so no Echo Reply is generated on eth0. This is not L3 down.

For full L3 up with reply, ping gateway 192.168.56.1 with its MAC, and srp will show "got 1 answers".

LAYER 4 - Transport Layer Test

L4 Test - UDP Port 50001

Why put a listener on port 50001?

We use 50001 because it is in the clean dynamic range 49152-65535. Nothing else on VyOS uses it, so there is no L5-L7 app interfering. If something arrives there, we know it is pure L4 Transport being tested. We also need a listener (nc -l -u -p 50001) otherwise the OS would drop the UDP and we would see nothing.

The listener was run in one terminal as:
sudo nc -l -u -p 50001 > /tmp/udp.txt &
The frame we sent:

L4 must be carried inside L3, so we still need an IP. We used loopback because we are sending from VyOS to itself:
from scapy.all import *
udp_clean = IP(dst="127.0.0.1")/UDP(dport=50001)/Raw(load="L4-TEST")
send(udp_clean)
Breakdown:

IP(dst="127.0.0.1") = L3 part - VyOS lo loopback
/UDP(dport=50001) = L4 part - clean port
/Raw(load="L4-TEST") = payload to prove delivery

Sent with:
sudo python3 -c "from scapy.all import *; send(IP(dst='127.0.0.1')/UDP(dport=50001)/Raw(load='L4-TEST'), verbose=1)"
The result:
cat /tmp/udp.txt
L4-TEST
And tcpdump -i lo -n port 50001 showed the packet on lo.

Conclusion: Payload L4-TEST was delivered to clean port 50001. No other service uses this port. This proves L4 UDP is UP.