Improve SSH behavior in cider-connect

[cap10morgan]

As per the discussion in #1142, we should improve how and when CIDER decides it needs to try an SSH connection to a remote host in cider-connect.

The preferred option seems to be to do 2 things:

1. Add a custom variable for SSH files to sniff for ports, like '(~/.ssh/known_hosts ~/.ssh/config). It's value would default to '(~/.ssh/config).
2. Have a user level logical cider-sniff-for-ports-when-connected-only and use (file-remote-p file nil t) to check if there is already an emacs connection open outside of cider to that server.

This should serve to make cider-connect's behavior less surprising for users. Currently it tries to SSH to any hostname in ~/.ssh/known_hosts which is often incorrect behavior and is difficult to debug in those cases.

[Malabarba]

If someone is going to tackle this, I'd suggest looking into tramp too. Tramp is Emacs' default interface to ssh (and other protocols), and many aspects of Emacs (besides just visting files) are already integrated with it, like dired, M-x shell, and eww.

It might be overkill for us to offer this integration, but it might also be that tramp has some functions/variables we can reuse for deciding what ports to sniff.

[bbatsov]

Perhaps using tramp is the way to... I'm not sure...

1. should be pretty easy to do, but number 2. might turn out to be pretty complex.

[Frozenlock]

Is there a way to avoid this behavior?

I usually open an SSH connection with port forwarding if I want a secure interaction with a remote REPL.

Now I'm in a situation where I don't want SSH and yet cider-connect is trying on its own to use it.

Edit: After looking at the source, this looks like it happens automatically when the direct connection fails.
I was unable to see the "direct connection failed" message because the automatic SSH fallback was crashing my Emacs every time.

[Malabarba]

@Frozenlock maybe I misunderstood, but it looks like you're experiencing a genuine bug, while the current issued is really just a slightly related feature request. If that's the case, Could you file a separate issue describing how to reproduce your problem?

[Frozenlock]

Emacs crashing is indeed a bug unrelated to this issue.

However, I'd still prefer to have a way to disable the automatic SSH fallback, which is pertinent for this issue.

[Malabarba]

I see. Thanks for explaining. 👍

[aiba]

I also have a bit of trouble getting cider to avoid using ssh.

When I run M-x cider-connect, then enter a hostname, it immediately launches some kind of slow tramp ssh thing. I think it's trying to guess which port to connect to, but in my cases it doesn't ever find a port because nrepl-server is launched programmatically from within a clojure app, not using lein repl.

For now, I'm working around this by defining a function for each remote host that I commonly connect to. The functions call cider-connect with 3 args. This seems to avoid spending time having tramp ssh into the host.

(defun my-cider-connect-foo ()
  (interactive)
  (cider-connect "foo" foo-port "/path/to/local/git/repo"))

And then I use M-x my-cider-connect-foo.

Like @Frozenlock, in my situation I basically never want cider-connect to do anything with ssh. I don't want an ssh-tunnel, a tramp session, or anything ssh-related.

[cvillecsteele]

Having the same issue. Dockerized clojure process running on a container on my dev machine, with repl open on 55555... Connecting to it from emacs on the host, I see "nREPL: Establishing SSH tunneled connection ..." How do I make it NOT ssh?

[koddo]

Ok, just reporting. I figured out how to connect to a dockerized figwheel running an nrepl directly. In my case it was listening to the localhost connections only. Had this in the *Messages* buffer:

[nREPL] Establishing direct connection to 172.17.0.3:7888 ...
[nREPL] Direct connection failed
[nREPL] Establishing SSH tunneled connection ...

To make it listen on all interfaces, add this to figwheel configuration: :nrepl-host "0.0.0.0" :nrepl-port 7888

[bbatsov]

Seems I missed the last few comments. We should solve this simply by introducing a configuration option.

[bbatsov]

I've pushed a commit that changes the default behavior and furthermore - makes it configurable via a new defcustom. Try it out!

[Hodapp87]

I'm using nrepl-use-ssh-fallback-for-remote-hosts and it's still trying SSH first for a known host (without asking for port number and without ever attempting a direct connection), and seemingly never trying direct connection.

If I instead put in the IP address directly, it asks for port number and the direct connection works fine.

If I use a made-up hostname it's never seen before, it properly asks for port number, tries direct connection, fails, and then doesn't try SSH.

[bbatsov]

@Hodapp87 It just tries a direct connection first and ssh afterwards (if the fallback is enabled).

Are you saying that known hosts are not handled properly? If that's the cause this should be a different issue.

[Hodapp87]

Sorry, I said that wrong. I meant that I had disabled nrepl-use-ssh-fallback-for-remote-hosts, and then it was still trying SSH first (and never trying direct connection, nor even asking for a port) if I provided a known host.

The behavior goes away if I remove the host in question from ~/.ssh/known_hosts (or just supply an unknown host instead), and then it seems to behave as expected.