Jamf Remote stuck at Opening SSH Connection

[cbd4s]

I'm having a very weird issue with Jamf Remote and it's happening to two machines (10.15.4). The version is 10.20.1.

Basically it's stuck at Opening SSH Connnection when sending tasks to the remote machines. Sometimes I get one machine working and it will stay working. But the others are just no go.

Then I use terminal to ssh into those other machines. All went in perfectly fine. Then I use recon to remotely connect to those other machines and that was working as well.

I've tried using different network connection (wired/wireless) but it didn't help.

I've also tried attaching the same network connection (IP address) to another Mac that doesn't have this problem. Jamf Remote still works fine.

Any thoughts would be really appreciated.

[ITFRANCE]

Good morning, sir,

Same problem, we try to change the mdp of a user with Jamf Remote, it blocks on the SSH part, while the port is open, I ping the address of the target Mac without problem ...

Thank you.

[hdsreid]

I have a ticket open around this, the only real response I've been given is that jamf remote doesn't work across subnet...nevermind this had never been any issue before

i found a "workaround" for the moment...if i ssh into the machine on terminal and then initiate in jamf remote, it will connect. strange, but at least it works.

[GiveEmHelms]

I'm having the same issue.

I thought it was just me. Started happening about two weeks ago. 10.19.0

[cbrewer]

This is PI-008041.
Unable to SSH from Jamf Remote on 10.15.4 without Manually Accepting SSH Fingerprint.

[mrheathjones]

Having the same issue, I have an open case and PI-008041 was mentioned by support but even after accepting the SSH fingerprint, Jamf Remote is not functional. I've heard the issue is resolved in Jamf Pro v10.21.0, but I can't confirm that.

[jhuls]

I might be experiencing this as well as of today. I'm trying to use JAMF Remote to do nothing more than update inventory and it just hangs. In backtracking my steps I'm pretty sure that this was working fine up until the point that the 10.15.4 system rebooted. I can't say that with total confidence though.

[cbd4s]

Received from Jamf Support:

PI-008041
Description : Unable to SSH from Jamf Remote on 10.15.4 Beta without Manually Accepting
SSH Fingerprint
Steps to reproduce:
- Enroll a client in the JSS
- Download Jamf Remote on a 10.15.4 Beta host computer
- Open and authenticate into Jamf Remote
- Select the client from step 1 as a target computer
- Select any option (I attempted to install a PKG and DMG as well as run a script)
- Click 'Go'
Found during compatibility testing for the Spring Release. This will affect the first time any new
client is connected to via Jamf Remote from 10.15.4.
You must manually accept the fingerprint via Terminal to get Jamf Remote to Connect to any
client from a 10.15.4 host computer.
Expected Results:
- Jamf Remote connects to the client computer from the host via ssh
- PKG, DMG, and script are run against the client
Actual Results:
- Jamf Remote hangs at the "Attempting to SSH to client..." step
- PKG, DMG, Script never install
WORKAROUND: Manually accept the SSH Fingerprint for each client before using Jamf Remote
by doing
'ssh {user}@{client_ip}'

[cbd4s]

This is so ridiculous as it basically erased most of the Jamf Remote benefits (send tasks to managed machines in BULK using Jamf resources). Wasted the whole day pulling my hair out looking for the cause and fix. It's becoming more and more sensible to stay behind one major version for macOS in the enterprise environment.

[hdsreid]

@cbd4s thanks for clarifying some of this...
if its only impacting 10.15.4, it explains why only two of us have seen the issue in my environment lol

[GregE]

Thought it was just me as well but hadn't got around to logging another job for something all of a sudden not working any more. Around 10.15.3 and/or 10.19 is when I first noticed it.

[dlondon]

I've been seeing this too and until this week we were on Jamf Pro 10.16.1. Clients I've tested on are Mac OS 10.13.6 and all the way up to 10.15.4. I'm still seeing this behaviour using Jamf Pro 10.20.1.

[larry_barrett]

I'm not saying this is a solution to your problem, but, when manually trust (or not trust) a SSH connection, the text file you can nuke is user/user_name/ssh/known_hosts . Just delete everything in the file and save. Again, this probably won't help this specific problem, but it is a workaround I used to SSH into my Odroid when having a SSH problem.

[mvora]

I am having this same issue, started last week after updating to 10.15.4 on my computer (clients are all older OS). Makes Jamf Remote useless.

[bern]

Has anyone updated to 10.21.0 and test to see if this issue was resolved?

[a_holley]

Ok, I thought this was just me, so kind of relieved it’s happening to others. Jamf Remote is a must have in our environment, so until this is resolved we won’t be going to 10.15.4

[cbrewer]

@a.holley Push on Jamf to fix the issue or use the work-around. Don't hold back security updates.

[mvora]

10.21.0 has quietly fixed this issue!

[easyedc]

This sounds like something I've experienced for a long time. When you've tested connecting, are you using the same credentials for your JAMF administrator account? For me the only resolution has been to delete the service account JAMF creates and recreate it.

[hdsreid]

@mvora confirmed fixed? i do not get upgraded until next weekend, and did not see it in the change notes either

[mvora]

@hdsreid Yes confirmed fixed in 10.21.0. But you don't need to actually upgrade your JAMF server, we're still on 10.17.1. Just the 10.21.0 version of Remote.

[mrheathjones]

@ITFRANCE I have also confirmed that simply updating the Jamf Remote app to 10.21.0 resolves this issue, we are still running JamfPro v10.20.1

[hdsreid]

@mvora @mrheathjones awesome, didnt even think about that!

[jhalvorson]

@ITFRANCE When using Jamf Remote 10.21.0 with Macs that have an older Jamf binary agent, such as 10.20.1, doesn't it generate an error that there was a mis-match between Jamf versions after installing packages or running scripts on the Mac?

[cbrewer]

@jhalvorson It sounds like Jamf Remote no longer does this.

From the 10.21.0 release notes:
"Jamf Remote no longer attempts to install or update the jamf binary on remotely connected client computers. "

[WhippsT]

Jamf Remote 10.21.0 doesn't fix the issue. We just began factory resetting our Macbook Airs to 10.15.5 and I'm unable to connect to any of them via Remote. Our JSS is also on 10.21.0.

Does anyone have any solid workarounds until Jamf fixes yet another issue that Apple created in the name of security?

[cbd4s]

Hi, @WhippsT , we are on 10.21.0 and just tested with the smart group of all 10.15.5 machines. Jamf Remote seems to be connecting and authenticating fine.

[cnelson]

I'm on 10.21.0 and can confirm that I still have this problem. Any thoughts?

And when I try to ssh with jamf agent account, it instantly closes the connection.

Computer trying to remote to is on 10.15.3.

[sardesm]

I am on 10.20.1 and have this problem as well, just tested against a OSX10.14.6 and it failed until I accepted the fingerprint.

[luke_reagor]

I can confirm the problem still exists on Jamf 10.20.1 with Catalina 10.15.5.

[agetz]

You can change the ssh config for your user account and bypass the additional security. Not recommended for security reasons but seems to work if you're in a pinch. Hopefully this issue will be resolved soon without the need for tweaks like this.

Create or edit ~/.ssh/config and add the following lines:

Host 10.*.*.*
   StrictHostKeyChecking no

Edit the "Host" IP to represent the subnets you want to bypass.

[cnelson]

So I tried something on my machines and Jamf Remote started to work again.
I already have Remote Login enabled on all machines.
I am on Jamf Pro 10.25.1 and running the command with ARD on Catalina.
I ran the following command:

dseditgroup -o edit -t user -a "jamf_mgmt_account_name" com.apple.access_ssh

I'm wondering if when the OS does it's security updates, if it's wiping the contents of com.apple.access_ssh.
Anyway, for now, Jamf Remote seems to be working. Yay!

[Jordan_Hare]

Same issue. Just started yesterday. Thought it was my VPN. I can use Apple Remote Desktop just fine.

[nielandj]

Running into the same issue on 10.15.6, with 10.26.0 Jamf Remote.

[nielandj]

Follow up from my post yesterday: The only way I could get this to work was to delete the computer record and re-enroll. Joy.

[luke_jaeger]

I'm having the same issue on 10.29.2. My computer and the remote Mac are both running os 10.15.
When I try it with a remote Mac running 10.14, it works fine.

[Nozumi]

Currently I am testing this, I am on 10.30.2 for cloud instance and using 10.30.3 Remote app, I cannot connect to any of the Big Sur Macs, have not test the previous OS ones

[rjtort86]

We've been experiencing this issue as well, and figured out what the solution was, at least in our setup. 

It all boiled down to our admin account password needing to be reapplied to the affected machines. 

We set our PreStage configuration create a local administrator account before the Setup Assistant, then skip account creation. This way it bypasses most of the Welcome screen prompts. Every new computer we were setting up, or if we performed a wipe/refresh of the OS would fail when trying to issue commands via JAMF Remote, SSH through terminal, or even run JAMF Recon remotely. 

What fixed it was creating a policy where under "Management Accounts", setting "Change Account Password" to reapply the password for that administrator account, then setting it to run at startup (I'm sure once this runs through all of our machines, we could change it to once after enrollment). 

Hopefully this helps others experiencing this issue. I'm going to test altering the PreStage configuration to see if not skipping account creation stops this from being an issue in the first place soon, but thought I'd share what I've found so far.