Re: SSH blocks account when running within emacs

[Bob Proulx <bob@proulx.com>]

Roel Sergeant wrote:
> I've have this weird issue with emacs. It seems since 3 days when I use ssh
> (or cvs over ssh) from within an emacs shell it blocks... It even makes my
> host appear on the black-list on the server (had to ask the admins of that
> machine several times to allow connection from my host again).

If the remote host is banning you then you are starting a connection
and failing to complete it.  This should not ever be a permanent ban.
That is always bad because it allows a denial of service attack.  The
most popular project is http://www.fail2ban.org/ which by default bans
an IP address for ten minutes and then enables it again.  A temporary
ban is the standard best practice to rate limit attacks while at the
same time avoiding denial of service for valid users.  If your remote
admins are permanently blacklisting based upon failures you might
remind them that doing it that way is a bad thing.  But if they are
enabling the IP again after a short delay then you simply must wait
for the short delay to expire so that you are automatically enabled
again.

> If I do the same thing outside of emacs it works fine (I did several
> connections to the server and even updated my source tree), but the first
> time I tried it again from within emacs it blocks me again.
> 
> I already deleted/moved/cleaned my .emacs.d directory and .emacs. I also
> removed the private keys from .ssh and removed the known_hosts, but none of
> these seems to solve this problem.
>
> Anything I can check that is emacs related? I'm using version 24.2.1 on
> NetBSD. Except for some modes for syntax highlighting and temp directories
> I have it pretty standard. Any pointer are welcome...

Is it asking you for a password?  Is it asking you for a passphrase?
Is it using a SSH_ASKPASS defined service?  Are you using an ssh rsa
key?  Why not?  I think it most likely that you are running into
problems during these phases.

The debug decision tree is somewhat complicated with several different
possibilities at several different levels in the debug tree.  This
makes pursuing all possible problems in one exchange difficult and
practically impossible.  But here are a few hints for the most common
problems.

While in your emacs shell at the same point that you would run the
command 'cvs up' or whatever look to see what environment variables
are defined.

  $ env | grep -i ssh
  SSH_AGENT_PID=6963
  SSH_AUTH_SOCK=/tmp/ssh-Et2xWGLY52jb/agent.6927

That is a normal output from my environment running the ssh-agent.  If
you have SSH_ASKPASS defined then I would unset it.  Try clearing all
variables from the environment using 'env -i'.  Note that cvs obtains
HOME from the password file.

  $ env -i PATH=$PATH cvs up
  Enter passphrase for key '/home/rwp/.ssh/id_rsa': 
  cvs update: Updating .

I would avoid debugging against your production remote machine.
Instead use a different victim machine that won't blacklist you for
repeated failures while debugging your problem.  Working against the
"localhost" machine seems reasonable.  Create a local repository and
then check it out from "localhost" using the remote ssh protocol.
Then debug your problem using it.  Once the problem has been found and
fixed then return to using your remote production machine.

Bob