help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SSH blocks account when running within emacs


From: Roel Sergeant
Subject: Re: SSH blocks account when running within emacs
Date: Wed, 21 Nov 2012 07:15:21 +0100


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]