There are lots of potential configuration gotchas, but basically you can do it via ssh forwarding by using -X on the ssh command line. Another approach: If you know the IP address of your Mac and your Mac Xserver is at :0 (typically the default?), you should be able to do something similar to the following:
$ RpiBash: declare -X DISPLAY=macipaddress:0
If you want to develop C/C++, you can use Eclipse CDT, once installed and with the right toolchain you will be able to code on your PC, then compile on your PC, send the binary file and remote debug. All from your PC without touching the raspberry.
Raspberry Linux toolchain (if you can work on Windows there is SYSGCC toolchain)
It appears the issue was central to fish for some reason. Moving to bash caused ssh to work as expected. Returning to fish and typing out ssh firstname.lastname@example.org in full caused everything to work correctly; no idea why. Best guess is that something was wonky in the stored smart command stuff fish does.
Unfortunately I do not have a simple solution.
Generally I find Zero-conf
resolution works reliably, but I have encountered problems.
Indeed, at the moment, my Pi4 is not being resolved at MilliwaysPi4.local although I have an open ssh session to the Pi4.
Discovery works by sending a broadcast message (can't remember the address off the top of my head), ...
I finally figure out what the issue was - fail2ban banned my IP.
$ sudo iptables -L f2b-sshd -v -n --line-numbers [13:34:09]
Chain f2b-sshd (1 references)
num pkts bytes target prot opt in out source destination
1 44 2288 REJECT all -- * * 192.168.1.80 ...
First of all check firewalls.
Routers have an option to isolate clients.
Check if you have installed ufw and disabled ports.
Check if both pc and raspberry pi are in same network. aka network part of ip same.
Check if windows is not blocking connections. Now a days windows is preloaded with a restrictive firewall, after smbv1 apocalypse.
Check if you can ...
You need to narrow down the problem step by step. First use a fresh flashed Raspbian Buster Light for troubleshooting. The light version reduces possible error sources. The unmodified version is guaranteed to work if you do not have broken hardware. Before starting the fresh installation place an empty file ssh into the boot directory you have to mount on ...
You think that raspberrypi-zero-wh is that name of your Raspberry Zero WH, but as can be seen in the output of the ping command, that name resolves to 127.0.0.1.
So you don't try to connect to the Raspberry Zero WH, you try to connect to the computer running the ssh command.
It seems to be a problem with the assignment of the DNS name.
Which I assume is your hostname is meaningless.
Try raspberrypi-zero-wh.local which should be resolved by zero-conf on a standard Raspbian and is supported by most Linux distributions.
The problem is with the routing. You try to connect from remote to the PI, but the return packets are routed through the VPN. The port forwarding might work, you have to find out where it goes wrong.
A solution to the routing problem is policy routing. Create a rule:
ip rule add sport 22 table 222
This assumes that 22 is your SSH port, the table number ...
You must use 0.0.0.0 for translate an unknown IP address (because it can be dynamic). Redirect all TCP input traffic from all IP addr port 22 to your host to destination 192.168.0.2 (from my example) and port 22 (change this port for prevent mass scanning)
Where 92.x.x.x.x is PUBLIC IP and 192.168.0.2 is PRIVATE IP.
then use :
ssh -p 22 email@example.com
In my case Ubuntu 19.04 I didn't get IP address from Raspberrypi Zero
You can fix it easy just change "USB Ethernet" settings
Automatic (DHCP) --> Link-Local Only
After that you will get a 169.254.xxx.xxx IP address.