SSH blocks account when running within emacs

SSH blocks account when running within emacs

[Roel Sergeant]

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

Hi list,

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

Thanks in advance,
Kind regards,
Roel.

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

Re: SSH blocks account when running within emacs

[Bob Proulx]

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

Re: SSH blocks account when running within emacs

[Roel Sergeant]

[-- 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 --]

OT: Allowing PAM auth and reverting authorized_keys?! (Was: SSH blocks account when running within emacs)

[Jeremiah Dodds]

Roel Sergeant <rsergeant@gmail.com> writes:
>     
>     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). 
>

I certainly hope not. Allowing PAM auth and disallowing authorized_keys,
particularly reverting authorized_keys would raise "I don't want to be
dealing with this host/these people" red flags for me.

Assuming it's not a permissions issue, I'd be asking whoever would be
relevant about the behaviour to make sure it's intentional.

If it *is* intentional, it seems pretty wrong-headed.

-- 
Jeremiah Dodds

blog           : http://jdodds.github.com
github         : https://github.com/jdodds
freenode/skype : exhortatory
twitter        : kaens

Re: OT: Allowing PAM auth and reverting authorized_keys?! (Was: SSH blocks account when running within emacs)

[Roel Sergeant]

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

On Wed, Nov 21, 2012 at 1:08 PM, Jeremiah Dodds <jeremiah.dodds@gmail.com>wrote:

> Roel Sergeant <rsergeant@gmail.com> writes:
> >
> >     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).
> >
>
> I certainly hope not. Allowing PAM auth and disallowing authorized_keys,
> particularly reverting authorized_keys would raise "I don't want to be
> dealing with this host/these people" red flags for me.
>
> Assuming it's not a permissions issue, I'd be asking whoever would be
> relevant about the behaviour to make sure it's intentional.
>
> If it *is* intentional, it seems pretty wrong-headed.
>
>
Thanks! Already send out the email to them to ask why... But since it
happened 3 times
I assumed it was intentional, but that was before I knew anything about
ssh,
except how to start a session... At least I learned a few new things this
week.

Kind regards,
Roel.

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

Re: SSH blocks account when running within emacs

[Bob Proulx]

Roel Sergeant wrote:
> 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

Ouch.  That seems like the root of the problem.  No tty so can't ask
for a password.

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

It will use the tty device.  You can tell which device by using the
'tty' command.  Such as this example from my machine.

  $ tty
  /dev/pts/39

> From env I have the following related to terminals..
> 
> In emacs:
> TERM=dumb
> SSH_TTY=/dev/pts/0

TERM=dumb is normal within a '*shell*' window.  I am not familiar with
SSH_TTY but wonder if that environment variable is simply in the
environment from when emacs is started and unrelated to the current
shell running in the emacs inferior process.

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

Be sure to try this with 'emacs -Q' to test it without any startup
files.  Just in case a startup file has overridden the installation in
some way that is breaking you.

I know you said you were running emacs 24.2.1 on NetBSD.  Seems like
that should operate okay there.  I am running emacs 23.2.1 on Debian
Squeeze.  In that and previous versions of emacs 'M-x shell' starts up
a shell and in that shell a pty is associated with it.  I can very
this by running 'tty' to produce the name of it and 'test -t 0' shows
a pty as in this example below.

  $ test -t 0 && echo yes tty || echo no tty
  yes tty

I can only suggest taking it up with the NetBSD maintainer and ask
about how emacs was built for your platform.  It should work, but
doesn't, so why not?  Or of course you could grab the source and build
it yourself.  But it appears that emacs on your platform is not going
to have a tty available for some reason.

I would also try 'M-x term' too.  That should definitely spawn an
associated pty device since that is the entire point of it.  Read the
documentation on the emulator since the emacs keys are necessarily
nested.  Hint: Within emacs try "C-h r g terminal emulator" to read
the documentation.  Note that C-c is the escape character.  All other
control characters are sent to the shell.  So you need to know how to
get out of that mode before using that mode.  I routinely run M-x term
and then C-c C-j to swith to line mode so that normal emacs keys are
enabled again and then C-c C-k to switch back when I want to send
control keys to the inferior shell process.

Bob