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.
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.
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.
Received from Jamf Support:
Description : Unable to SSH from Jamf Remote on 10.15.4 Beta without Manually Accepting
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.
- Jamf Remote connects to the client computer from the host via ssh
- PKG, DMG, and script are run against the client
- 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
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.
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.
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.
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.
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?
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.
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.
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!
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.