From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.help Subject: Re: SSH blocks account when running within emacs Date: Tue, 20 Nov 2012 14:22:40 -0700 Message-ID: <20121120212240.GA16931@hysteria.proulx.com> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1353446575 28021 80.91.229.3 (20 Nov 2012 21:22:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Nov 2012 21:22:55 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Nov 20 22:23:06 2012 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TavHY-0006H9-7q for geh-help-gnu-emacs@m.gmane.org; Tue, 20 Nov 2012 22:23:00 +0100 Original-Received: from localhost ([::1]:36728 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TavHN-0006g7-TI for geh-help-gnu-emacs@m.gmane.org; Tue, 20 Nov 2012 16:22:49 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36779) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TavHH-0006fw-TR for help-gnu-emacs@gnu.org; Tue, 20 Nov 2012 16:22:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TavHG-0000Ub-HM for help-gnu-emacs@gnu.org; Tue, 20 Nov 2012 16:22:43 -0500 Original-Received: from joseki.proulx.com ([216.17.153.58]:42453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TavHG-0000UW-5n for help-gnu-emacs@gnu.org; Tue, 20 Nov 2012 16:22:42 -0500 Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id A4D7B211D5 for ; Tue, 20 Nov 2012 14:22:40 -0700 (MST) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 5D2A52DCC6; Tue, 20 Nov 2012 14:22:40 -0700 (MST) Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 216.17.153.58 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:87823 Archived-At: 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