Re: SSH blocks account when running within emacs

[Roel Sergeant <rsergeant@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4645 bytes --]

Thanks Bob,

On Tue, Nov 20, 2012 at 10:22 PM, Bob Proulx <bob@proulx.com> wrote:

> 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.


OK, that makes sense and they do indeed block it only for a short time.


> > 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.
>

I use user/password authentication, but it doesn't ask for a password when
within emacs, but it does so in a normal shell.

I tried setting it up with an rsa key, but it seems a cron job is running
that
removes authorized_keys from user profiles (or they are copying profiles
because they have multiple servers. I have to dig deeper into that after
this issue is fixed).

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.


I tried this on a non-production setup and up to now no solution,
but I did find the following using the verbose option on ssh:

debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: Device not configured
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
Permission denied, please try again.

So it seems from within emacs it can't read from /dev/tty. Outside emacs
this works (I'm assuming it either finds /dev/tty or uses the actual device
needed).

From env I have the following related to terminals..

In emacs:
TERM=dumb
SSH_TTY=/dev/pts/0

In a normal shell:
TERM=screen -or- TERM=linux
SSH_TTY=/dev/pts/0

Any ideas?

Thanks,
Roel.

[-- Attachment #2: Type: text/html, Size: 6478 bytes --]