Need help connecting to my orangepi

I currently have my orangepi connected to my router over ethernet and trying to ssh via my Fedora 36 desktop connected by wifi. I’m unable to ssh into my orangepi,

I have already asked chatgpt, but it seems to be going in a circle about enabling ssh

I’m following the instructions here

However I’m getting a connection refused error when I run the ssh command
ssh: connect to host orangepiIP port 22: Connection refused

I’ve already run arp -a

_gateway (ip) at routerMacAddress [ether] on wlo1
? (orangepiIP) at orangePiMacAddress [ether] on wlo1

I identified orangepi as it is the only other [ether]

Can you post the output from ssh -v [email protected] please?

Have you already tried the last steps listed?

You can enter the following command on the development board and try to
connect
root@orangepi:~# rm /etc/ssh/ssh_host_*
root@orangepi:~# dpkg-reconfigure openssh-serv

ssh -v root@orangepiIP    (base) 
OpenSSH_8.8p1, OpenSSL 3.0.5 5 Jul 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to orangepiIP [orangepiIP] port 22.
debug1: connect to address orangepiIP port 22: Connection refused
ssh: connect to host orangepiIP port 22: Connection refused
ssh -v root@orangepiIP    (base) 
OpenSSH_8.8p1, OpenSSL 3.0.5 5 Jul 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to orangepiIP [orangepiIP] port 22.
debug1: connect to address orangepiIP port 22: Connection refused
ssh: connect to host orangepiIP port 22: Connection refused

do I need to worry about removing addresses?

you don’t need to,t hey are just local addresses.

i can think of two possibilities preventing connection to ssh.

  1. the sshd server is not running on the rpi. start it with systemctl enable --now sshd.service (it could be called something else)

or there is a firewall in front of it that is refusing connections.

1 Like

looks like it, the only issue is that I don’t have a minihdmi to get into the orangepi.

I dd armbian onto a usb drive and plugged it in to try sshing into it but it seems to be refused. If I’m on wifi and the orangepi is connected on the router, are they technically on the same network?

On some distros sshd is configured by default to ignore remote connections, but that seems unlikely since remote connections are kind of the whole point here.

1 Like

ahh crap that complicates it

1 Like

a very stupid and complicated solution will be to pull the SD card (if it has one obvs, don’t know much aboput the RPI)

and mount the root partition on the card inside in another linux machine, chroot into it, and run systemctl enable sshd.service, it’ll make the necessary symlinks for systemd to start the service on boot

mount /dev/disk/by-id/your-sd-card-ext-partition /mnt
chroot /mnt

systemctl enable sshd.service
1 Like

wait is it because I’m on wifi?

Those are two different networks. If it’s only listening on one or them, then yeah that could do it.

2 Likes

oh that could be the issue. I just plugged in both my desktop and orangepi into ethernet. Now it’s a matter of waiting for them to both show up

 ssh -v [email protected]          (base) 
OpenSSH_8.8p1, OpenSSL 3.0.5 5 Jul 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to 192.168.1.148 [192.168.1.148] port 22.
debug1: connect to address 192.168.1.148 port 22: Connection refused
ssh: connect to host 192.168.1.148 port 22: Connection refused

hmmm ip didn’t change

arp -a

? (192.168.1.148) at xx:xx:xx:xx:xx:xx [ether] on enp34s0
_gateway (192.168.1.1) at xx:xx:xx:xx:xx:xx [ether] on enp34s0
? (192.168.122.0) at <incomplete> on virbr0

ifconfig

enp34s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.XXX netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::XXXX:XXXX:XXXX:XXXX prefixlen 64 scopeid 0x20<link>
ether XX:XX:XX:XX:XX:XX txqueuelen 1000 (Ethernet)
RX packets 14624 bytes 13247069 (12.6 MiB)
RX errors 0 dropped 26 overruns 0 frame 0
TX packets 9322 bytes 1746358 (1.6 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 92078 bytes 4635799 (4.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 92078 bytes 4635799 (4.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.122.XXX netmask 255.255.255.0 broadcast 192.168.122.255
ether XX:XX:XX:XX:XX:XX txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

virbr0 must be a bridge. Maybe that’s getting in the way. I’ve had similar problems trying to access VMs hosted on one machine from another.

maybe is there any other commands I can run to help debug this further. If not I might have to figure it out tomorrow

What model do you have of your OrangePI? (Full)
What distro have you installed on eMMC and/or SD-card?
Are WIFI and cabled Ethernet connected to the same router (and no other router etc on the network)?

Its coming back connection refused so the tcp handshake packets are getting to the device just fine and getting bounced. Either because of firewall, not started, or sshd is listening on the bridge interface for some reason.

My money is on sshd not running at this stage

4 Likes

If no mini-hdmi to connect locally, how about USB?

Suggestion to connect via USB and connect as a device

sudo screen /dev/ttyACM0

As per sz4bo
On thread

Then trouble shoot all from the machine.
Some forum posts suggest there may be a hang on first boot as root, with default passphrase (1234 [?]) But ssh shouldn’t be dependent on that.
The USB thing could get around network routing /config issues, if it works

1 Like

What I used to do when using the official Pi images is creating a .ssh file in the boot folder of the machine and it would enable SSH.
Maybe it works the same way for your OrangePi. If you’re going to re-flash the OS, after it’s done, create that file in the boot partition and it should work.

Orange Pi Zero 2, 1GB Allwinner H616 Quad Core 64 Bit Open-Source 1000M Ethernet Single Board Computer, Support Android10, Ubuntu, Debian (Zero 2+ Black Case + Al Heat Sink)

Armbian 22.11 Bullseye on a usb key

Same network modem. Desktop is connected via powerline

On my desktop? Maybe, but I got the same error when I installed sshd on my desktop following this guide

Will have to look at it tomorrow too tired rn

Will have to ask chatgpt for instructions. I used dd to flash onto my usb key. Honestly I’m not sure if armbian is being used or if orangepi’s default is being used at this point.

I’m very tempted to buy a microhdmi and microsd at this point

no, on the orangepi. sshd is the daemon server that runs on the thing you’re connecting to.

Yeah probably not. I don’t have access to the pi because I don’t have a microhdmi