Unable to SSH to one client that I used to connect to

Question

Level 1

35 points

Unable to SSH to one client that I used to connect to

Running Sonoma 14.6.1 and trying to SSH into a Raspberry Pi that I last used ~2 years ago. The Pi had been off and unused but is now on my network and patched and up to date.

I can successfully SSH to other clients. I've troubleshooted on the Pi and SSH is enabled and I can SSH from another client, just not from my laptop running Sonoma.

I've checked known_hosts and there is an entry for the old Pi. I've tried `sudo ssh-keygen -R host` to remove the entry but I get `Cannot stat /Users/Chris/.ssh/known_hosts: No such file or directory'

I can open that file and see contents so it does exist.

If I look at the mail that is generated by trying the command, it's really confusing. I've cleared this file completely so I'm only looking at entries created by me trying to ssh-keygen or to ssh user@host. All of the items recorded in Mail refer to something I've not had on this laptop in years and years.

From Chris@MacBook-XXXX-XX.local Tue Mar 11 11:17:03 2025

Return-Path: <XXXX@MacBook-XXX-XX.local>

X-Original-To: XXXX

Delivered-To: XXXX@MacBook-XXX-XX.local

Received: by MacBook-XXXX-XX.local (Postfix, from userid 501)

id 35FFE6445F48; Tue, 11 Mar 2025 11:17:01 +1100 (AEDT)

From: XXXX@MacBook-XXXX-XX.local (Cron Daemon)

To: XXXX@MacBook-XXXX-XX.local

Subject: Cron <XXXX@MacBook-XXXX-XX> chmod 777 /Applications/World\ of\ Warcraft/.build.info

X-Cron-Env: <SHELL=/bin/sh>

X-Cron-Env: <PATH=/usr/bin:/bin>

X-Cron-Env: <LOGNAME=XXXX>

X-Cron-Env: <USER=XXXX>

Message-Id: <20250311001703.35FFE6445F48@MacBook-XXXX-XX.local>

Date: Tue, 11 Mar 2025 11:17:01 +1100 (AEDT)

chmod: /Applications/World of Warcraft/.build.info: No such file or directory

Can someone please help me understand how to fix this so I can get SSH working again please with this one client?

Posted on Mar 10, 2025 05:26 PM

Reply

Answer 1

Mar 11, 2025 09:56 AM in response to Enigmatic

Based on your post, I think you are looking at two different issues.

Pre-issue

If you are a local admin and you are going to use Terminal in your workflow, please make sure that you have granted the Terminal application Full Disk Access. Go to System Settings > Privacy & Security > Full Disk Access and add Terminal to the list. If Terminal is running, you must quit and relaunch for the right to be respected.

Issue 1: The event recorded to mail

This looks like you have a crontab file that had a script of directive to change permissions on a World of Warcraft (go Alliance) folder. In Terminal, run crontab -l to see if you created a user crontab. Otherwise, look in /etc for a crontab file. (less /etc/crontab) If the file exists, does it contain you chmod command for the path to the WoW folder? If so, either comment the line (assumes you have other items in the crontab) or delete the crontab file (requires sudo escalation).

Issue 2: SSH to Pi

Use a command line editor to modify the known_hosts file and remove the old entry (vi or pico). Then attempt the SSH again, allowing a fresh key exchange. Also, you did not post the error you are getting when you try to SSH. What is returned in the Terminal when you attempt to connect? Does it prompt for password? Does it error immediately?

Ok, hope this helps. The full disk access will likely resolve the issue with the ssh-keygen. However, if you are trying to modify the file that you already own, why are you escalating to root (sudo)?

Reply

Answer 2

Enigmatic Author

Level 1

35 points

Mar 11, 2025 09:50 PM in response to Strontium90

Thanks for the response.

After posting I did some more digging into the mail and that seems to have resolved itself. Not sure how there was a CRON job or why it was doing stuff with WOW because I've not had that on the laptop in 14+ years

I had tried editing the known_hosts file to remove that entry but it made no difference. I ended up renaming the file so I started with a fresh known_hosts but no progress/change.

There is no error, just straight up refuses to connect. Looking at logs on the Pi I don't think the connection is even reaching the server:

ssh -v USERNAME@XXX.XXX.XXX.248

OpenSSH_9.7p1, LibreSSL 3.3.6

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files

debug1: /etc/ssh/ssh_config line 54: Applying options for *

debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling

debug1: Connecting to XXX.XXX.XXX.248 [XXX.XXX.XXX.248] port 22.

debug1: connect to address XXX.XXX.XXX.248 port 22: Connection refused

ssh: connect to host XXX.XXX.XXX.248 port 22: Connection refused

No idea what "Authenticator provider $SSH_SK_PROVIDER" is or where it's being invoked. Never found reference to this in any config file and I've never implemented anything like this.

Reply

Answer 3

Mar 12, 2025 12:09 PM in response to Enigmatic

The last two lines would suggest a firewall rule or something else preventing communication like an approved host file on the Pi. Without providing the actual IP, is it a LAN address or a WAN address? I will assume all devices are on the same LAN. Can you ping the Pi (ping x.x.x.253)? Can you handshake with port 22 on the Pi (nc -v x.x.x.253)? If other devices on the Lan are able to connect, can you review the network of those devices. For example, do you have a wired LAN and a wireless LAN that use different subnets? Different VLANs?

It would appear the Pi is denying the connection before authentication. Did you customize SSH on the Pi to only accept connections from certain addresses (ranges). (hosts.deny/hosts.allow files, Match Address in sshd_config, or in the pi's firewall config)

Very silly and stupid test. If you have another Mac that connects, then turn it off, force this Mac to assume its IP address and then try from the troublesome Mac. If you are able to connect, then you have a rule somewhere limiting which IP can connect.

Reply

Answer 4

Enigmatic Author

Level 1

35 points

Mar 13, 2025 01:25 AM in response to Strontium90

All addresses are local LAN addresses. All devices are on the same LAN and I can ping the machine I want to SSH into no issue. If I run trace route it's just one line returned. All same IP range, all same subnet & VLAN.

The only difference is that the laptop is on wireless whereas everything else is wired.

Looking at this more I don't think my SSH request is leaving the laptop. There is nothing on the logs of the Pi to even suggest a connection has been requested from the laptop. Have never touched hosts.deny/hosts.all.

It's not a big issue but I've reimaged the Pi with a new OS so everything is brand new on the Pi. I still cannot SSH to it and there is nothing to show the request is actually being declined by the Pi - all signs point to locally on the laptop.

Reply

Answer 5

Enigmatic Author

Level 1

35 points

Mar 13, 2025 03:29 AM in response to Enigmatic

Have tried using the laptop with a wired connection and still no change. Cannot ssh to this one device

Reply