It's been a while since I've needed to connect to a server via SSH. When I tried to connect today, Little Snitch gave me this warning:

The program "ssh" has been modified

Previously, the program had the identifier "com.apple.openssh", but now it's "com.apple.ssh". This probably means that Apple decided to rename the process. But please inspect the names! If a process has been replaced with a script interpreter such as Python, its rules may be hijacked by a script virus.

Apple SSH warning

And this is probably nothing, but looking at the binary in a code editor, I noticed the first 8 characters say "cafe babe". Strange, right?

Apple SSH binary 'cafe babe'

I couldn't find any info about it online, so I installed openssh via Homebrew. But when I run that, Little Snitch warns that the process has no signature.

Homebrew SSH unsigned warning

Anyway, I checked the signature on the Apple binary using codesign -db --verbose=4 /usr/bin/ssh, but I can't find anything online to compare the output against.

So how can I be sure this binary is legit before allowing it to connect?

BTW, I'm running Ventura 13.1.

Edit: Here's the output of codesign -dv --verbose=4 /usr/bin/ssh:

Format=Mach-O universal (x86_64 arm64e)
CodeDirectory v=20400 size=6182 flags=0x0(none) hashes=183+7 location=embedded
Platform identifier=14
Hash type=sha256 size=32
CandidateCDHash sha256=d19d6f7a19eb7178c68fc67c197bc8d8fbeda7e7
CandidateCDHashFull sha256=d19d6f7a19eb7178c68fc67c197bc8d8fbeda7e791bd5a9e96f67e9b2169eb16
Hash choices=sha256
Executable Segment base=0
Executable Segment limit=671744
Executable Segment flags=0x1
Page size=4096
Launch Constraints:
Signature size=4442
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Signed Time=Nov 5, 2022 at 12:44:29 AM
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=64

Output of 'uname -a':

Darwin MacBook-Pro.local 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:08:47 PST 2022; root:xnu-8792.61.2~4/RELEASE_X86_64 x86_64
  • 3
    cafebabe is the Java & Mach-O magic number, so that alone is no indicator.
    – Tetsujin
    Jan 20, 2023 at 8:38
  • 1
    xxd /usr/bin/ssh|head also showscafe babe in my Big Sur machine.
    – lhf
    Jan 20, 2023 at 11:04
  • 1
    Hmm, interesting. Can you run /sbin/md5 /usr/bin/ssh and see whether you get 28dae2824341539a9e4d073b28bc0b89 ?
    – nohillside
    Jan 20, 2023 at 18:42
  • @nohillside Yes, I get that same hash.
    – thingEvery
    Jan 20, 2023 at 18:52
  • 1
    @nohillside Awesome. Then I'll go ahead and let it run. Thank you very much for your help!
    – thingEvery
    Jan 20, 2023 at 19:00

3 Answers 3


If you indeed are running /usr/bin/ssh and didn't play around with SIP or SSV then you can assume that the binary is legit.

SSV (Sealed System Volume) ensures that your macOS install can't be tampered with (the system simply refuses to boot if somebody tries).

PS: For Ventura 13.1 I get the following hash for ssh:

$ uname -a
Darwin Sumtri.local 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:04:44 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T8103 arm64
$ /sbin/md5 /usr/bin/ssh
MD5 (/usr/bin/ssh) = 28dae2824341539a9e4d073b28bc0b89

The output of codesign in the question lists the certificates used to assert the executable's chain of trust:

  • Software Signing
  • Apple Code Signing Certification Authority
  • Apple Root CA

This chain suggests the software has been signed directly by Apple. Unfortunately these certificates' signatures are not shown inline. Apple's certificates are published on Apple PKI.

If you trust Apple, then this signature's chain of trust suggests the ssh executable can also be trusted.

Verifying a Code Signature on macOS

Apple recommend the following command to verify a code signature:

codesign --verify -vvv --deep --strict <path>

Apple's documentation limits the meaning of a successful verification:

Be careful how you interpret this output. It isn’t saying that the code is fit for some specific purpose, like running on your Mac or installing on your iPhone. Rather, it says that the code is internally consistent, that is:

  • All of the expected files are present.
  • There are no extra files.
  • None of the files have been modified. To learn how code signing checks for changes, read TN3126: Inside Code Signing: Hashes.
  • A basic X.509 trust evaluation of the leaf certificate succeeded.
  • The code satisfies its own designated requirement (DR). To learn more about code signing requirements in general, and the significance of the DR in particular, see TN3127: Inside Code Signing: Requirements.

Apple's documentation archive contains a useful section entitled Examining a Code Signature.

Using codesign to Investigate a Code Signature

You use the codesign command to interrogate an app or other signed entity about its signature. To verify the signature on a signed binary, use the -v option with no other options:

codesign -v <code-path>

This command confirms whether the code binaries at are actually signed, the signature is valid, all the sealed components are unaltered, and the signature passes some basic consistency checks. It does not by default check that the code satisfies any requirements except its own designated requirement. To check a particular requirement, use the -R option. For example, to check that the Apple Mail application is identified as Mail, signed by Apple, and secured with Apple’s root signing certificate:

codesign -v -R="identifier com.apple.mail and anchor apple" /Applications/Mail.app

A later section discusses how to test against System Policies:

Using spctl to Test a Code Signature Against System Policies

The basic syntax for code signing assessment is shown below:

# Assess an application or tool
spctl --assess --type execute myTool
# Assess an installer package
spctl --assess --type install myInstallerPackage.pkg

If your application or package signature is valid, these tools exit silently with an exit status of 0. (Type echo $? to display the exit status of the last command.) If the signature is invalid, these tools print an error message and exit with a nonzero exit status.

For more detailed information about why the assessment failed, you can add the --verbose flag.


The hash value mentioned in the answers/comments is not sufficient to proof if your ssh is corrupted. It is only helpful if you btrust the hash value mentioned here and it matches. If not it is just an indicator, that maybe a deeper look is necessary.

The example hash is from an Intel machine. If this is not an universal binary the hash may vary by version. The pointer at SSV (Sealed System Volume) is also not sufficient, as you may have a different binary in the path taking precedence over the system ssh.

  • 2
    This is close to a proper answer if you can make this stand on its own. Are you pointing out a problem with how the questioner asked about security or the answer provided? Also note, anyone can edit a post to correct an oversight but this seems more an answer than a comment which here is for clarifying a post and not generally rebutting it.
    – bmike
    Apr 2 at 11:52
  • 3
    Can you elaborate with an edit why a hash isn’t sufficient to check for a corrupted ssh - the OP knows about paths and should be fine with technical details since they mention two binaries they hope to clear for use. Also is btrust a typo or a process?
    – bmike
    Apr 2 at 11:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .