Add workaround for buggy ssh password prompt behavior in macOS 10.15.4

[ralfdaniel]

Hi,
I am syncing my MacBook and iMac data folders with Unison 2.51.2 for several years now and it worked great.
But after updating macOS Catalina from version 10.15.3 to 10.15.4 released on 23rd March 2020 Unison is not able to connect to the second computer. It is just showing "Connecting..." and nothing more happens.
I already checked the SSH connection between both computer via Terminal and it is working in both directions. Also there was no change in the .prf-file.
Does some has any fix or idea how to solve this?

[samuel]

Have the same issue after upgrading to 10.15.4. Seems to be 2020-03-30 09:13:37.421 Unison[10125:80781] Unrecognized message from ssh:

Running the unison cli installed through homebrew works. So it seems to be something to do with the release build. I'm happy to help track this down. Currently trying to build the app to add more debugging.

Full output of -debug all doesn't seem to show anything useful.

Preferences:
ui = graphic
host = 
server = false
prefsdocs = false
doc = 
version = false
silent = false
dumbtty = false
testserver = false
showprev = false
selftest = false
confirmmerge = false
retry = 0
repeat = 
contactquietly = false
key = 
label = 
expert = false
height = 15
auto = false
maxthreads = 0
maxsizethreshold = -1
prefer = 
force = 
sortnewfirst = false
sortbysize = false
keeptempfilesaftermerge = false
diff = diff -u CURRENT2 CURRENT1
copyonconflict = false
backupdir = 
maxbackups = 2
backups = false
backupsuffix = 
backupprefix = .bak.$VERSION.
backuploc = central
copymax = 1
copyquoterem = default
copythreshold = -1
copyprogrest = rsync --partial --append-verify --compress
copyprog = rsync --partial --inplace --compress
rsync = true
fastcheck = default
ignorelocks = false
dumparchives = false
showarchive = false
rootsName = 
ignorearchives = false
fastercheckUNSAFE = false
fat = false
allHostsAreRunningWindows = false
someHostIsRunningWindows = false
confirmbigdel = true
batch = false
root = ssh://samuel@192.168.84.26//home/samuel/unison
root = /Users/samuel/unison
killserver = false
halfduplex = false
stream = true
addversionno = false
servercmd = 
sshargs = 
rshargs = 
rshcmd = rsh
sshcmd = ssh
xferbycopying = true
sshversion = 
clientHostName = mycomp.local
ignoreinodenumbers = false
links-aux = true
links = default
times = false
group = false
owner = false
numericids = false
dontchmod = false
perms = 1023
watch = true
rsrc-aux = false
rsrc = default
maxerrors = 1
unicodeCS = false
unicodeEnc = false
unicode = default
someHostIsInsensitive = false
ignorecase = default
timers = false
terse = false
logfile = /Users/samuel/unison.log
log = true
debugtimes = false
debug = all
addprefsto = 
[remote] Shell connection: ssh (ssh, -l, samuel, 192.168.84.26, -e, none, unison, -server)
2020-03-30 09:15:43.804 Unison[10150:81885] Unrecognized message from ssh: 

[samuel]

Using the text ui works but the mac ui doesn't. Seems to be maybe something with pipes and the ssh command but not totally sure. At least this is a work around for now.

$ /Applications/Unison.app/Contents/MacOS/Unison -ui text Home
2020-03-31 17:59:50.520 Unison[46737:626400] Calling nonGuiStartup
Unison 2.51.2 (ocaml 4.04.0): Contacting server...
password: 

$ /Applications/Unison.app/Contents/MacOS/Unison Home
2020-03-31 17:59:58.926 Unison[46750:626495] Unrecognized message from ssh: 

[ralfdaniel]

Great, thank you Samuel! This also did the job to sync my macs. So it must be something with the mac ui if command line entries are working.

[bcpierce00]

Using "-debug verbose” instead of “-debug all” will print the exact bytes that the client is getting from the ssh process. This may help understand whether the problem is something to do with the communication between the client and the ssh process or something else. - Benjamin

…

On Mar 30, 2020, at 12:17 PM, Samuel Stauffer ***@***.***> wrote: Have the same issue after upgrading to 10.15.4. Seems to be 2020-03-30 09:13:37.421 Unison[10125:80781] Unrecognized message from ssh: Running the unison cli installed through homebrew works. So it seems to be something to do with the release build. I'm happy to help track this down. Currently trying to build the app to add more debugging. Full output of -debug all doesn't seem to show anything useful. Preferences: ui = graphic host = server = false prefsdocs = false doc = version = false silent = false dumbtty = false testserver = false showprev = false selftest = false confirmmerge = false retry = 0 repeat = contactquietly = false key = label = expert = false height = 15 auto = false maxthreads = 0 maxsizethreshold = -1 prefer = force = sortnewfirst = false sortbysize = false keeptempfilesaftermerge = false diff = diff -u CURRENT2 CURRENT1 copyonconflict = false backupdir = maxbackups = 2 backups = false backupsuffix = backupprefix = .bak.$VERSION. backuploc = central copymax = 1 copyquoterem = default copythreshold = -1 copyprogrest = rsync --partial --append-verify --compress copyprog = rsync --partial --inplace --compress rsync = true fastcheck = default ignorelocks = false dumparchives = false showarchive = false rootsName = ignorearchives = false fastercheckUNSAFE = false fat = false allHostsAreRunningWindows = false someHostIsRunningWindows = false confirmbigdel = true batch = false root = ***@***.***//home/samuel/unison root = /Users/samuel/unison killserver = false halfduplex = false stream = true addversionno = false servercmd = sshargs = rshargs = rshcmd = rsh sshcmd = ssh xferbycopying = true sshversion = clientHostName = mycomp.local ignoreinodenumbers = false links-aux = true links = default times = false group = false owner = false numericids = false dontchmod = false perms = 1023 watch = true rsrc-aux = false rsrc = default maxerrors = 1 unicodeCS = false unicodeEnc = false unicode = default someHostIsInsensitive = false ignorecase = default timers = false terse = false logfile = /Users/samuel/unison.log log = true debugtimes = false debug = all addprefsto = [remote] Shell connection: ssh (ssh, -l, samuel, 192.168.84.26, -e, none, unison, -server) 2020-03-30 09:15:43.804 Unison[10150:81885] Unrecognized message from ssh: — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#328 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVQQC65F7WVTSX2TWHLECLRKDAZBANCNFSM4LVAGYPA>.

[h2k82u]

Same problem here, Unison not working since the update to 10.15.4.
ssh seems to have a bug / different behaviour since the update:
https://tyler.io/so-uh-i-think-catalina-10154-broke-ssh/
BTW: I use port 22 for the ssh server

[h2k82u]

Still not working after 'macOS Catalina 10.15.4 Supplemental Update' on both machines
Unison gui is freezing and showing 'Connecting'
I would be glad to help testing and tracking that error

[samuel]

Using "-debug verbose” instead of “-debug all” will print the exact bytes that the client is getting from the ssh process. This may help understand whether the problem is something to do with the communication between the client and the ssh process or something else. - Benjamin

Using -debug verbose is showing the same output for me:

logfile = /Users/samuel/unison.log
log = true
debugtimes = false
debug = verbose
addprefsto = 
[remote] Shell connection: ssh (ssh, -l, samuel, 192.168.84.26, -e, none, unison, -server)
2020-04-09 11:54:55.755 Unison[2220:22793] Unrecognized message from ssh: 

[h2k82u]

log = true
debugtimes = false
debug = verbose
addprefsto =
[remote] Shell connection: ssh (ssh, -l, bs, 192.168.178.7, -e, none, /usr/local/bin/unison, -server)
2020-04-10 08:44:46.053 Unison[5178:185556] Unrecognized message from ssh:

[bcpierce00]

Looks like this message is coming from line 489 of uimac/MyController.m and the message from ssh that it can’t interpret is the empty string (or a string containing just blanks). If somebody wants to do a little objective C programming, one could try to protect all the calls to raisePasswordWindow with a little loop that throws away empty prompts from ssh.

…

On Apr 10, 2020, at 2:54 AM, h2k82u ***@***.***> wrote: log = true debugtimes = false debug = verbose addprefsto = [remote] Shell connection: ssh (ssh, -l, bs, 192.168.178.7, -e, none, /usr/local/bin/unison, -server) 2020-04-10 08:44:46.053 Unison[5178:185556] Unrecognized message from ssh: — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#328 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVQQC4D6KUG35PB2IK7QQTRL27DHANCNFSM4LVAGYPA>.

[eli-tziperman]

same problem for me... both using pre-compiled binary and macports version. and the text interface works for me too.

[g8u]

Open a shell and use ssh-add
This solves the issue for me.

[kevinashworth]

I'm on Catalina 10.15.4. I typed ssh-add at the command line, it added my identity. Then I tried to run Unison, but to no avail -- still just shows "Connecting...". But I can continue to use the command-line text version of Unison.
Hmm. Wonder why it worked for g8u but not me?

[g8u]

I'm on Catalina 10.15.4. I typed ssh-add at the command line, it added my identity. Then I tried to run Unison, but to no avail -- still just shows "Connecting...". But I can continue to use the command-line text version of Unison.
Hmm. Wonder why it worked for g8u but not me?

I am clueless. Just can mention I sync between Catalina 10.15.4 and Ubuntu 20.04.

[h2k82u]

@g8u:
can you try syncing between two Catalina machines?
As far as I understand the problem is what the second machine (in your case Ubuntu?) reports back over ssh

[g8u]

@g8u:
can you try syncing between two Catalina machines?
As far as I understand the problem is what the second machine (in your case Ubuntu?) reports back over ssh

(un)fortunately I haven't got a second Mac. As far as I understand Unison shows an error if it receives an unexpected answer (as I just experienced painfully until getting Unison working again in my environment)

[eli-tziperman]

I am synching with a previous version OS Mac and this solution unfortunately did not help. The identity was added, but the unison window is still stuck saying "connecting" and does not prompt for a password. the text version works well, fortunately.

[g8u]

I'm on Catalina 10.15.4. I typed ssh-add at the command line, it added my identity. Then I tried to run Unison, but to no avail -- still just shows "Connecting...". But I can continue to use the command-line text version of Unison.
Hmm. Wonder why it worked for g8u but not me?

To find out, whether this is an issue with RSA passphrase handling when
unison connects to the host or a problem occuring later on you might
want to test this by temporarily removing the passphrase from your RSA key:

$ ssh-keygen -p

https://stackoverflow.com/questions/112396/how-do-i-remove-the-passphrase-for-the-ssh-key-without-having-to-create-a-new-ke

[eli-tziperman]

SOLVED! for me...:

I ssh from a terminal on my laptop to the machine with which I would like to sync using unison (my.desktop.company.com). I have a setup (.ssh/config) that allows me to then ssh from a different terminal window with no password to that remote machine, as long as the first ssh command is active. more on that below.

I start Unison, graphic version, it connects without requiring a password and works well. The remote hostname in the .unison file needs to be the same name that I use for the first ssh command.

as for the .ssh/config setup on my laptop, here it is, probably only some of this is relevant:

Host my.desktop.company.com
	User myuserid
	HostName my.desktop.company.com
	ControlMaster auto
	ControlPath ~/.ssh/%r@%h:%p
	ServerAliveInterval 2400
   	ForwardAgent yes
    	ForwardX11 yes
    	ForwardX11Trusted yes
    	#Port 22
    	#Protocol 2
	XauthLocation /opt/X11/bin/xauth
    	GSSAPIDelegateCredentials no

[kevinashworth]

Thanks! This works for me, too, to sync my Mac laptop with my home desktop. Following your instructions, I ssh in first, using the same hostname as in my .prf file, and then the Unison graphical version works as before, and after syncing I end my ssh session after closing Unison.

The contents of my .ssh/config are just this:

Host *
   ControlMaster auto
   ControlPath ~/.ssh/%r@%h:%p

[kevinashworth]

Yes, my config is in ~/.ssh on my laptop Mac. I first type the ssh command on my laptop Mac, then I open Unison on my laptop and that's how I can sync my laptop with my desktop Mac.

On my laptop — in both the command line and in Unison settings — I'm using the ssh command that's shown under my desktop Mac's System Preferences > Sharing > Remote Login. So on the command line it's ssh myacount@10.0.1.7 and in Unison preferences it's root = ssh://myacount@10.0.1.7.

HTH!

[h2k82u]

@ETZ1 and @kevinashworth: thank you for your fast response, I really appreciate it!
I followed Kevin's instructions but without any success.
Do you use a passphrase for ssh (thats what I do) or an authentication key?

What I don't understand is that Unison was working in the exact setting for more than 5 years until the last Catalina update

[eli-tziperman]

If you follow these instructions, login from the laptop to the remote computer, and then open another terminal on the laptop and ssh, does it require a pw? It should not...
It seems there is a problem with unison now, this procedure gets around it by eliminating the need for a pw rather than solving it

[h2k82u]

ok, that seems to be the problem.
I ssh to my desktop using a password without any problem ('ssh myacount@10.0.1.7').
After opening a second terminal window I repeat the ssh command but I am asked for the password again.
As suggested I created a 'config' file in ~/.ssh (I only had a file named 'ssh_config' in /etc/ssh/) before. It contains the following lines only:

Host *
   ControlMaster auto
   ControlPath ~/.ssh/%r@%h:%p

I guess, I have to learn more about ssh usage and pitfalls...

[h2k82u]

finally got it working!
The key is to multiplex ssh connections as suggested by @ETZ1 and @kevinashworth.
I had to modify the ssh config a bit differently and created a subdirectory for the 'ControlPath' as described here in detail (https://www.anchor.com.au/blog/2010/02/ssh-controlmaster-the-good-the-bad-the-ugly/)
After that I was able to establish a second ssh connection without being asked for a password and the unison gui was working as well (but I have to ssh in before).
Thank you for you help!
Maybe someone with programming skills is able to fix unison completely...

[mkeitsch]

My solution was to simply add my public ssh key of my "main unison sync mac" (where I start the GUI) to the ~/.ssh/authorized_keys file of my "slave unison sync mac".

For this solution working on my Macs...

• no password entering needed anymore
• no text sync needed
• no unison install via brew or macports or something else needed
• no .ssh/config needed
• no SSHing before in a terminal or via script
• no ssh multiplexing needed

If this simple solution does not work for others, maybe a combination of the different approaches may help.

(both installations Unison version 2.51.2, ocaml version 4.04.0, binaries directly donwloaded from website)

I think unison has some issues with piping/recognizing the password prompt of the ssh connection/command or something like this. But I'm not that familiar with GUI programming and connecting GUIs to cli commands. So it is very speculative.

[thetrial]

Sorry to say …
a265ec9, again has the error:
Unrecognized message from ssh: '2022-01-20 17:35:18.956 Unison[32668:336170] Calling nonGuiStartup '

[tleedjarv]

Well this is interesting... As you can see in the commit, the message Calling nonGuiStartup is clearly disabled; this binary should never output this message. So where is it coming from? I guess you have multiple binaries around?

[thetrial]

I have the working 2.51.4 and its cli binary under /usr. I did not delete them before. I started the test version from the download directory directly. I did not export its cli binary to /usr. But those don’t bring up this message. So … it’s strange?!

[tleedjarv]

I wonder if there is some binary mixup going on here. Even if you as a user don't see it, all versions without commit a265ec9 are outputting the message Calling nonGuiStartup with NSLog(...). The issue that we're trying to fix now is that starting from 2.51.5 there was a change in ssh child process fd redirections and since then the NSLog output seems to be polluting ssh's stderr somehow (see also @gdt's comment above). But a265ec9 itself never outputs this message so there is no way it could be polluting ssh's stderr with it, but any other version will output that message.

[thetrial]

So what shall we do now?

[tleedjarv]

Can you start the GUI app in the terminal? (I don't know how it works in macOS) Can you try redirecting it's stderr to a file? By Apple's documentation, this should redirect NSLog's output also to that file. Let's see if it makes any difference.

[tleedjarv]

Another thing to try is to temporarily move away all other binaries, make sure that the tested binary really is the one with commit a265ec9, and then try again.

[thetrial]

Before doing that (I don’t know how yet) I deleted my working Unison, replaced it, exported the cli binary to /usr/local/bin. Still same error with a265ec9.
Check:

~ > unison -version
unison version 2.51.5 (ocaml 4.11.2)

Starting from terminal:

~ > unison -ui graphic
2022-01-20 18:06:51.431 Unison[22449:812176] Unrecognized message from ssh: '2022-01-20 18:06:51.436 Unison[32933:347498] Calling nonGuiStartup
'

How would you redirect the stderr to a file with bsd, unix oder linux? I’d try that way here.

[thetrial]

Oh … I found out this with locate unison:

/usr/bin/unison
/usr/local/bin/unison

Hm, which one is right, which one is wrong?!

[thetrial]

No, no, forget ist, I guess the locate database is old. There is only /usr/local/bin/unison!

[thetrial]

I redirected … but it’s the same output as in the terminal …

I tried three profiles to the second Mac. The first did not give an error (!), the second and third gave:

2022-01-20 18:17:18.816 Unison[26003:825265] Unrecognized message from ssh: '2022-01-20 18:17:18.825 Unison[32990:349954] Calling nonGuiStartup
'
2022-01-20 18:17:28.654 Unison[26003:825265] Unrecognized message from ssh: '2022-01-20 18:17:28.663 Unison[32994:349984] Calling nonGuiStartup
'

[thetrial]

Now I’m back again to 2.51.4 – and everything works.

[tleedjarv]

I have to say, I'm at a loss here.

The Calling nonGuiStartup message is output by the startup code here (the code is very short, you can just read through it):
https://github.com/bcpierce00/unison/blob/3ac6a7f44e678148c47aed3a2a1a06d2cf30330f/src/uimac/main.m
more specifically:

unison/src/uimac/main.m

Line 38 in 3ac6a7f

NSLog(@"Calling nonGuiStartup");

The same code will then start the real GUI, here:

unison/src/uimac/main.m

Line 52 in 3ac6a7f

return NSApplicationMain(argc, argv);

which will then in turn request starting the ssh process and then interact with it. The code for that is here:

unison/src/uimac/MyController.m

Lines 407 to 519 in 3ac6a7f

	- (void)unisonInit1Complete:(id)ignore
	{
	@try {
	OCamlValue *prompt = ocamlCall("@@", "openConnectionPrompt", preconn);
	if (!prompt) {
	// turns out, no prompt needed, but must finish opening connection
	ocamlCall("x@", "openConnectionEnd", preconn);
	// NSLog(@"Connected.");
	waitingForPassword = NO;
	[self afterOpen];
	return;
	}
	waitingForPassword = YES;
	[self raisePasswordWindow:[prompt getField:0 withType:'S']];
	} @catch (NSException *ex) {
	NSRunAlertPanel(@"Connection Error", @"%@", @"OK", nil, nil, [ex description]);
	[self chooseProfiles];
	return;
	}
	// NSLog(@"Connected.");
	}
	- (void)raisePasswordWindow:(NSString *)prompt
	{
	// FIX: some prompts don't ask for password, need to look at it
	/* NSLog(@"Got the prompt: '%@'",prompt); */
	if ((long)ocamlCall("iS", "unisonPasswordMsg", prompt)) {
	[passwordPrompt setStringValue:@"Please enter your password"];
	[NSApp beginSheet:passwordWindow
	modalForWindow:mainWindow
	modalDelegate:nil
	didEndSelector:nil
	contextInfo:nil];
	return;
	}
	if ((long)ocamlCall("iS", "unisonPassphraseMsg", prompt)) {
	[passwordPrompt setStringValue:@"Please enter your passphrase"];
	[NSApp beginSheet:passwordWindow
	modalForWindow:mainWindow
	modalDelegate:nil
	didEndSelector:nil
	contextInfo:nil];
	return;
	}
	if ((long)ocamlCall("iS", "unisonAuthenticityMsg", prompt)) {
	NSInteger i = NSRunAlertPanel(@"New host",@"%@",@"Yes",@"No",nil,prompt);
	if (i == NSAlertDefaultReturn) {
	ocamlCall("x@s", "openConnectionReply", preconn, "yes");
	prompt = ocamlCall("S@", "openConnectionPrompt", preconn);
	if (!prompt) {
	// all done with prompts, finish opening connection
	ocamlCall("x@", "openConnectionEnd", preconn);
	waitingForPassword = NO;
	[self afterOpen];
	return;
	}
	else {
	[self raisePasswordWindow:[NSString
	stringWithUTF8String:String_val(Field(prompt,0))]];
	return;
	}
	}
	if (i == NSAlertAlternateReturn) {
	ocamlCall("x@", "openConnectionCancel", preconn);
	return;
	}
	else {
	NSLog(@"Unrecognized response '%ld' from NSRunAlertPanel",(long)i);
	ocamlCall("x@", "openConnectionCancel", preconn);
	return;
	}
	}
	NSLog(@"Unrecognized message from ssh: '%@'",prompt);
	ocamlCall("x@", "openConnectionCancel", preconn);
	NSRunAlertPanel(@"Connection Error", @"Unrecognized message from ssh: '%@'", @"OK", nil, nil, prompt);
	[self chooseProfiles];
	}
	// The password window will invoke this when Enter occurs, b/c we
	// are the delegate.
	- (void)controlTextDidEndEditing:(NSNotification *)notification
	{
	NSNumber *reason = [[notification userInfo] objectForKey:@"NSTextMovement"];
	int code = [reason intValue];
	if (code == NSReturnTextMovement)
	[self endPasswordWindow:self];
	}
	// Or, the Continue button will invoke this when clicked
	- (IBAction)endPasswordWindow:(id)sender
	{
	[passwordWindow orderOut:self];
	[NSApp endSheet:passwordWindow];
	if ([sender isEqualTo:passwordCancelButton]) {
	ocamlCall("x@", "openConnectionCancel", preconn);
	[self chooseProfiles];
	return;
	}
	NSString *password = [passwordText stringValue];
	ocamlCall("x@S", "openConnectionReply", preconn, password);
	OCamlValue *prompt = ocamlCall("@@", "openConnectionPrompt", preconn);
	if (!prompt) {
	// all done with prompts, finish opening connection
	ocamlCall("x@", "openConnectionEnd", preconn);
	waitingForPassword = NO;
	[self afterOpen];
	}
	else {
	[self raisePasswordWindow:[prompt getField:0 withType:'S']];
	}
	}

All of this is done in a proper Mac "app" (I don't know what's the proper way to call it), the one in Objective C. The unison that you invoke on the command line is a "regular" Unix executable, the plain C code for which is here (the code is very short, you can just read through it): https://github.com/bcpierce00/unison/blob/3ac6a7f44e678148c47aed3a2a1a06d2cf30330f/src/uimac/cltool.c
All it does is look for the "app" and start it.

I suspect that somehow an incorrect copy of the "app" is found... ?? Is there a way to start the "app" directly, skipping the unison binary completely? There must be, because the unison binary from cltool.c is provided for convenience only, not as a required component.

All possible versions mixups aside, what's more strange is that the Calling nonGuiStartup message is output first and only then the GUI is started and all the ssh init sequence begins. I guess it's possible that NSLog is buffering or has some delay.

[thetrial]

What do you mean with incorrect copy of the "app"? Which app? The "thing" that is packed and has an icon to click on it? Why should this be incorrect? And why is version 2.51.4 starting without any problems?
I don’t start unison via terminal the normal way, I start the "app". I thought this graphical app starts the unison binary "inside" itself. And the unix binary under /usr/local/bin (/local!) is just used by the incoming unison connection of another machine.

Well, I don’t understand why it works with one and not with the other. What is the diff?

[tleedjarv]

Yes, that's what I mean by "app", that "thing" :) I don't know the correct terminology. I have zero experience with macOS. @gdt maybe you have some guidance here?

When downloading the binary that includes commit a265ec9, a simple search for string Calling nonGuiStartup returns nothing in that binary (the one named Unison, not unison). So that binary does not produce that output. A search in other binaries (without this commit), easily shows that the string Calling nonGuiStartup is present.

Another thing that I didn't notice before because the error message from the GUI contained less information, in the messages like this:

2022-01-20 18:17:18.816 Unison[26003:825265] Unrecognized message from ssh: '2022-01-20 18:17:18.825 Unison[32990:349954] Calling nonGuiStartup
'

the process IDs 26003:825265 and 32990:349954 are different. Also, what I didn't notice before, the timestamp of the embedded message is later than that of the outer error message! This is significant because the embedded message causes the outer error and should never have a later timestamp (even with potential buffering going on). So I'm wondering if these are really separate processes on the same machine or could the embedded message come from the other machine (???).

When you receive this error in the GUI, before closing the message window, could you take a snapshot of the process list to see if these are processes on the same machine and what commands are behind them. Sorry, I can't tell you how to view a process list on macOS. Also, you could snapshot the process list on the other machine to see if the other process ID is present there.

[gdt]

The only really reliable way to be sure one is testing the right code is to remove every single vestige of unison except for what it is being tested. Also, I think it's best to test with command line unison if that can exhibit the bug.

Also, it makes sense to do the same purge and install only the testing version on the remote side too.

[tleedjarv]

I finally figured out what's going on. The "unrecognized message" is in fact coming from the remote machine's stderr. I'll see if I can find a fix.

[tleedjarv]

I've opened a PR with a proposed fix. @thetrial could you please test a build from https://github.com/bcpierce00/unison/actions/runs/1728155694
I don't have any access to macOS, so I am doing the fix completely in the blind. Your testing is very important to get the fix merged.

If you can, please test as follows:

1. local machine with the fixed build --> remote machine with 2.51.5
2. local machine with the fixed build --> remote machine with 2.51.4
3. local machine with the fixed build --> remote machine with the fixed build

Note to others willing to test -- this issue and the fix applies only to the uimac GUI, which is the native Mac GUI. It does not affect the GTK GUI.

[thetrial]

I’m going to check these setups in the next two days. Hold the line.

[thetrial]

Fresh from the lab …

local machine with the fixed build --> remote machine with 2.51.5
OK. In return: OK.
local machine with the fixed build --> remote machine with 2.51.4
OK. In return: OK.
local machine with the fixed build --> remote machine with the fixed build
OK. In return: OK.

I made some more tests in series from the second Mac as local:

local machine with 2.51.5 --> remote machine with the fixed build¹
OK. In return: OK.
local machine with 2.51.5 --> remote machine with 2.51.5
Error. In return: Error.
local machine with the fixed build --> remote machine with the fixed build¹
OK. In return: OK.

¹ This was an intended repetition to ensure.

And finally I tried:

local machine with the fixed build --> remote Linux with unison version 2.51.3 (ocaml 4.11.1)
Error: Unrecognized message from ssh: 'ssh_dispatch_run_fatal: Connection to [IP address]² Operation timed out'

Only once. Linux machine crashed. After reboot: OK.

² Here was an IPv6 address.

I guess the Linux crash was bad luck. I don’t know if this could be important or become a caveat, so I mention it here.

[tleedjarv]

Thank you for your testing efforts. Based on the results, I will mark the PR as ready to merge.

The Linux crash most likely is unrelated, but it is good to know that real error messages from ssh are properly presented to the user.

[reagle]

This issue is closed, but I'm experiencing this issue with 2.51.5 (from homebrew). Is there a fix pending in the next version? Thanks to this thread, if I ssh to the other server in a separate terminal first, it works, but otherwise I can only use the text UI.

╰─➤  unison -ui graphic
2022-01-28 15:36:20.108 Unison[49055:369136] Calling nonGuiStartup
╰─➤  unison -version
2022-01-28 15:36:30.367 Unison[49067:369291] Calling nonGuiStartup
unison version 2.51.5 (ocaml 4.12.0)

[tleedjarv]

Yes, the fix is not released yet. If you want, you can try out the fix by downloading a pre-built binary at https://github.com/bcpierce00/unison/actions/runs/1733125753 and you have to follow guidelines at https://github.com/bcpierce00/unison/wiki/CI-Binary-instructions
If this works for you then you can keep using this unreleased version. If this doesn't fix your issue then please report more details about your exact issue.

[reagle]

Which one of those many files would I download? I'm running macOS 12.2 21D49 arm64 -- and my ocaml version is above.

[tleedjarv]

The macOS GUI: https://github.com/bcpierce00/unison/suites/5026190466/artifacts/148102599
The "normal" Unix binary and GTK GUI (just FYI, you don't need this, the one above should be all you need): https://github.com/bcpierce00/unison/suites/5026190466/artifacts/148102598

[reagle]

Thank you. Using that version I no longer receive the "Unrecognized message from ssh".

[gdt]

Homebrew not having the latest release is not a unison bug.