Emacs / CVS / OpenSSH: preventing password popup

Question

I'm using GNU Emacs on my Ubuntu netbook in fullscreen mode. When I edit files that are under version control and hit C-x v v to commit the latest changes, an OpenSSH popup window will open and ask me for my password for the server on which my repository lives.

Unfortunately, because of the fullscreen mode, the popup window will not come up front and I cannot enter my password. But it's still somehow modal, so I also can't go back to emacs and, say, leave fullscreen mode either (or do anything else, like C-g). I'm basically trapped.

As an emacs user, I find the idea of popup windows disgusting anyway ;-) so ideally, I'd like to be asked for the ssh password in the minibuffer. How can I tweak my setup to make that happen? (I prefer to type in my password every time instead of storing a keypair in ~/.ssh/).

Kanaka

You've added a bounty, but you never responded to any of the suggestions that people made the first time around. We don't know whether you even attempted those solutions. – Jestude

@phils: Good point (I did comment on one, though). Your own answer was a good hint, but it wasn't exactly an answer to my question. I think sanityinc's answer, which you heavily commented on, too (thanks for that), is going the right direction. It's not a "solution" though. – Kanaka

Answer 1

You could use ssh-agent before launching emacs (or in another shell).

Corwin

The original poster prefers entering passwords to using key based authentication. However I agree ssh-agent and key pairs is the better solution. – Spicy

Answer 2

I'm speculating here, as I neither use CVS or vc within Emacs, however I presume that Emacs is shelling out to the appropriate program to perform the commit, and the password prompt is something entirely external to Emacs. So I suspect what you want to do is firstly find out which options are needed to do a GUI-less commit from your shell without Emacs, and then modify vc-checkin-switches (or define vc-cvs-checkin-switches) in Emacs to match (see defun vc-switches).

Jestude

Answer 3

It's probably the ssh-askpass program kicking in, which I think looks at the DISPLAY environment variable to decide how to request the password. If set, it pops up a graphical window, and if not, it asks the TTY.

If the vcs subsystem detects when passwords are requested from the user (which is likely), then it's possible that you can unset $DISPLAY for subprocesses:

(setenv "DISPLAY" nil)

This might have other negative side-effects, though, so also check out "man ssh-askpass" in case something there might help.

(Disclaimer: I personally use a solution based on ssh-agent, which I strongly recommend.)

Asteroid

You could use advice or hooks to apply that to only the necessary code. I see that vc-before-checkin-hook and vc-checkin-hook (after) are defined, but I'm guessing you would need to do this for more than just commits? For (solely) the case of C-x v v, the following advice would cover it: (defadvice vc-next-action (around my-ssh-prompt-fix-for-vc-next-action activate) (let ((backup (getenv "DISPLAY"))) (setenv "DISPLAY" nil) ad-do-it (setenv "DISPLAY" backup))) – Jestude

If the environment that cvs runs in does affects this, then another option would be to over-ride the cvs command. vc-cvs-command hard-codes "cvs" as the command and passes it to vc-do-command, so one option would be to write a wrapper script for cvs (outside of Emacs) to execute the real command in a modified environment. That might affect non-Emacs calls to cvs though, so you could name the wrapper something other than "cvs" and create some before advice for vc-do-command to change the value of its command arg to match when it is "cvs". – Jestude

or maybe just use the advice approach from my first comment on vc-do-command instead of vc-next-action ? – Jestude

Globally setting DISPLAY to nil does prevent the popup. However, now I also need a way to redirect ssh-askpass' asking for the password to the minibuffer. Currently, it just prints "Permission denied" to the *vc* buffer and aborts. – Kanaka

Answer 4

You can get ssh to multiplex all new connections to a server through existing connections. This means that as long as you have opened an ssh connection (say in a shell) new ones to the same remote host will not ask for a password. I use

Host *
    ControlPath ~/.ssh/master-%r@%h:%p
    ControlMaster auto
    ServerAliveInterval 30

in ~/.ssh/config to set this up.

Armyworm

Cool technique, but not exactly what I'm looking for here. But still good to know! – Kanaka

Answer 5

Try setting this in your environment somehow:

export CVS_RSH='ssh -o PreferredAuthentications="password"'

That should get it to stop attempting publickey authentication, which will also suppress the display of the graphical ssh-askpass. This works by specifying the SSH command that CVS will use for connecting to the remote server. Please note that this will apply to all CVS commands run from the context in which you set the environment variable.

You may also want to look into setting it up in your ~/.ssh/config. You can set options for each host separately. Here's a page that roughly shows how, although for forcing publickey auth. Please note that this will affect all SSH usage for your user account, not just for CVS. That may very well be what you're looking for, since you seem to prefer avoiding publickey auth. Here's an example of the block you'd add in ~/.ssh/config:

Host cvs

  Hostname cvs.your.corp
  User yourCVSusername
  PreferredAuthentications password

Alternately, you could change Host cvs to Host cvs.your.corp if your existing means of accessing this uses a FQDN instead of just a hostname.

Lastly, you could have your ~/.ssh/config file by just this one line (or add it to the top of your existing one):

PreferredAuthentications password

That will make the preference apply to all SSH connections to remote hosts.

Best of luck. I hope this gets you out of the modal dialog trap.

Stickweed

Thanks, but I'm not using SVN. – Kanaka

The same solution works for CVS, by just setting the CVS_RSH environment variable instead of the SVN_SSH variable. I updated the answer to reflect that. Please note that the second solution, modifying ~/.ssh/config, will work for all programs that use SSH, even if they don't support environment variables like CVS_RSH and SVN_RSH – Stickweed

I also added examples for the second solution. – Stickweed

@justis: Thanks a lot for the update! But do these solutions actually work for you? For me, the first solution (setting CVS_RSH) gives me cvs [commit aborted]: cannot exec ssh -o PreferredAuthentications="password": No such file or directory while the second one (editing ~/.ssh/config) has no effect, the popup window still appears. – Kanaka

@thomas Yeah, the second one definitely works for me. You might need to use PreferredAuthentications keyboard-interactive instead, if password auth is disabled on the remote SSH host. – Stickweed

The reason that the popup window is appearing is because your client and the remote host have determined that publickey is the method that you both prefer most. Then, it sees that there is no value for SSH_TTY and that there is a value for SSH_ASKPASS or that the default value is present and executable. So, it pops up a window in the X11 environment in lieu of writing to a terminal that doesn't exist. – Stickweed

I just realized that PubkeyAuthentication no in your ~/.ssh/config could also work. – Stickweed

The CVS_RSH trick doesn't work because it's treating the whole string as the executable. You should still be able to fix this by changing values in ~/.ssh/config. I'm still not sure where the SSH_TTY is going to go, though. I don't use emacs, I just know a decent bit about SSH and am trying to help with that part. – Stickweed

Answer 6

While researching my main answer (above), I came across psvn for emacs. See this SO question/answer for more details: SVN for Emacs: how do you set author name and save password?

I thought you might also appreciate knowing about psvn, but I think the one about setting the PreferredAuthentications value on SSH is more directly applicable to the question you originally asked.

Stickweed