Python Fabric gives: Fatal error: No existing session

Question

I have the following simple fabfile.py from the docs:

from fabric.api import run

def host_type():
    run('uname -s')

I try to run it using:

fab -H 192.168.0.201 host_type

But get the error:

me@ubuntu:~/me$ fab -H 192.168.0.201 host_type
[192.168.0.201] run: uname -s
Password for [email protected]: 

Fatal error: No existing session

Aborting.

I can ssh okay into 192.168.0.201.

Any ideas?

Harrell

There's something odd happening with your ssh session. What OS is the server running? Try ssh -o"PreferredAuthentications=password" and see if it denies you access. – Schulz

This has just started working. I didn't change anything that I can remember other than stop the VMs and restart them, but I thought I'd done that before...Anyway thanks to all for the ideas. – Harrell

Answer 1

Short answer: try the '-k' and '-a' command-line flags if you have more than one SSH public key and want to use password authentication.

When I encountered this error, it was the result of a very unique situation. I have many different public keys in ~/.ssh. I also have many of those public keys added to my SSH agent. I was attempting to use Fabric with only a password.

Here's what I saw in the server authentication logs:

Nov  7 07:56:02 ubuntu sshd[1862]: Disconnecting: Too many authentication failures for user [preauth]
Nov  7 07:56:08 ubuntu sshd[1864]: Disconnecting: Too many authentication failures for user [preauth]

I had instructed Fabric to use not public keys for authentication with the '-k' command-line flag. I had missed that Fabric (via Paramiko) defaults to using whatever is available via the SSH agent. In my case, all these public keys were registered with the SSH agent, so telling Fabric not to use public keys was an incomplete solution. I added the '-a' command-line flag which tells Fabric not to query the SSH agent. Finally, I could use password authentication to connect to the server with Fabric.

Labroid

did you file a bug report? – Davey

This is not working in Fabric2, adding -a returns No idea what '-a' is! – Elamite

Answer 2

More generally, if you get this error, you should try SSHing with the exact parameters that paramiko is trying to use:

• hostname
• user
• authentication method

I found that having too many SSH keys caused some (but not all) of my fabric SSH connections to fail, because all the keys were being offered to the remote host. In the past, malformed keys have also raised this error message for me (you can detect them by removing the keys from ~/.ssh/ , one at a time.)

Unfortunately, Fabric doesn't respect your .ssh/config settings. If you want to debug this, you can run the following:

#!/usr/bin/env python
import paramiko

paramiko.util.log_to_file("/tmp/paramiko.log")
ssh = paramiko.SSHClient()
# Run this if you get host key errors: see later
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect("example.com", username="myuser", password="mypassword")

and check the output in /tmp/paramiko.log - you might see something like:

INF [20120904-16:58:52.155] thr=1   paramiko.transport: Disconnect (code 2): Too many authentication failures for myuser

You can set no_keys on the Fabric env environment:

env.no_keys = True

But then you will need to tell Fabric to use specific keys for specific hosts. As suggested above, you can do that in your fabfile with:

from fabric.api import env

env.key_filename = "/path/to/.ssh/ssk_non_public_key"

More generally here's a function to parse your .ssh config and pull out selective keys - in this keys, the SSH key to use. For this to work automatically, you'll need to add IdentityFile to ~/.ssh/config:

Host example.com
    IdentityFile /home/jp/.ssh/id_rsa_example

Another cause of failure might be that paramiko does not recognize all host key types. This is somewhat more problematic: paramiko is quietly ignoring the host key in ~/.ssh/known_hosts, because it's not a format of host key that it understands. Try ssh-ing with -v and see what line SSH says it finds a host key match for:

debug1: Host '1.2.3.4' is known and matches the RSA host key.
debug1: Found key in /home/jp/.ssh/known_hosts:105

You can try deleting this line, then doing ssh again and accepting the (new?) host key, and see if paramiko is happy then. If that's the problem, though, and that doesn't solve it, then there's no clear solution that I can see.

Invoke

did you file a bug report? – Davey

Answer 3

To fix it

1. add this lines to your fabric recept:

   from fabric.api import env
   
   env.key_filename = "/path/to/.ssh/ssk_non_public_key"
   

   If you placed public ssh key on the server that needs to be accesses by the fab script.

2. If no -- delete you .ssh directory this can also help

Or you can create ssh key by ssh-keygen and than use the combination of the 1) and 2)

Happiness

Answer 4

I had private key in ~/.ssh/config and turns out I need to add it again with ssh-add ~/.ssh/PRIVATE_KEY_NAME then everything starts working again. I've use command with forward agent optioni -A

Taryn

Answer 5

Not enough reputation to comment on Troy J. Farrell's post, in response to jberryman's questions. This is NOT a bug, but an artifact in the way that SSH public keys are handled.

My problem was one of the keys I have loaded into ssh-agent (ed25519) was incompatible with one of the systems I had loaded into env.hosts in fabric. Since I did want to use my other keys, I just added the -a option, and not the -k option to fabric. This worked. The only caveat is if one of your private keys is password protected, you'd have to enter this passphrase every time fabric used the key.

Bantamweight

Answer 6

One of the simplest solution in fab --help use parameter -a

file name : fabfile.py To run from command line : fab -a check_service

from fabric.api import run, env

env.hosts = ['127.0.0.1']
env.user = 'viraj'

def check_service():
    """
    Function will show status of nginx service. 
    """
    run ("systemctl status nginx.service")

Brushwood

Answer 7

Hmmm, just guessing... have you tried this ?

def host_type():
    run('uname -s', pty=True)

I remember I applied this faq entry for a similar problem: http://docs.fabfile.org/en/1.0.0/faq.html#why-do-i-sometimes-see-err-stdin-is-not-a-tty

Token

Answer 8

It was ssh agent failure for me, caused by smartcard removal. Problem could be easily seen in "ssh user@host" output (in my case it was "Agent admitted failure to sign using the key." message).

My guess is that OP had some transient problem with ssh as well, hence the same (not particulary clear) paramiko error.

Seaton