4

after years of finding every question already asked it's finally time to ask one myself. I am afraid the problem is rather specific but I'll try to be as detailed as possible.

I am trying to ssh connect to remote servers via python3 scripts using paramiko. Normally this works just fine.

import paramiko as pm

pm.util.log_to_file('debug.log')
client = pm.client.SSHClient()
client.load_system_host_keys()
#works
client.connect('servername', username='username')

stdin,stdout,stderr=client.exec_command("touch testing")

However, I am stuck trying to apply the same for a server that uses Kerberos authentification. And since documentation is rather cryptic to me I am stuck not knowing where to look at.

For a normal ssh -v login I am getting:

debug1: Reading configuration data /home/***/.ssh/config
debug1: /home/***/.ssh/config line 40: Applying options for excalibur
debug1: Connecting to excalibur.arl.hpc.mil [140.31.71.19] port 22.
debug1: Connection established.
debug1: identity file /home/***/.ssh/id_rsa type 1
debug1: identity file /home/***/.ssh/id_rsa-cert type -1
debug1: identity file /home/***/.ssh/id_dsa type -1
debug1: identity file /home/***/.ssh/id_dsa-cert type -1
debug1: identity file /home/***/.ssh/id_ecdsa type -1
debug1: identity file /home/***/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.3p1a
debug1: match: OpenSSH_7.3p1a pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1a
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 63:86:77:97:9b:48:ea:99:c5:60:d8:1f:c2:f5:8e:38
debug1: Host 'SERVERNAME' is known and matches the ECDSA host key.
debug1: Found key in /home/***/.ssh/known_hosts:13
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to excalibur.arl.hpc.mil ([140.31.71.19]:22).
debug1: Final hpn_buffer_size = 131072
debug1: HPN Disabled: 0, HPN Buffer Size: 131072
debug1: channel 0: new [client-session]
debug1: Enabled Dynamic Window Scaling

For me this means that gssapi-with-mic is used for authentication. Therefore, I am changing my test script to:

import paramiko as pm
import gssapi

pm.util.log_to_file('debug.log')
client = pm.client.SSHClient()
client.load_system_host_keys()

#client.set_missing_host_key_policy(pm.AutoAddPolicy())
client.connect('server', username='username',gss_auth=True,gss_kex=True)
stdin,stdout,stderr=client.exec_command("touch testing")

However, this raises errors:

client.connect('HOSTNAME', username='USERNAME',gss_auth=True,gss_kex=True)
File "/home/USERNAME/lib/python3.5/site-packages/paramiko-2.1.1-py3.5.egg/paramiko/client.py", line 380, in connect
File "/home/USERNAME/lib/python3.5/site-packages/paramiko-2.1.1-py3.5.egg/paramiko/client.py", line 621, in _auth
File "/home/USERNAME/lib/python3.5/site-packages/paramiko-2.1.1-py3.5.egg/paramiko/client.py", line 598, in _auth
File "/home/USERNAME/lib/python3.5/site-packages/paramiko-2.1.1-py3.5.egg/paramiko/transport.py", line 1327, in auth_publickey
paramiko.ssh_exception.SSHException: No existing session

I think the last line is just telling that the touch comment is not successful, where as the rest is just indicating that something is going wrong without giving useful hints.

Looking into debug.log shows:

DEB [20170210-00:00:23.772] thr=1   paramiko.transport: starting thread (client mode): 0x73b15a58
DEB [20170210-00:00:23.772] thr=1   paramiko.transport: Local version/idstring: SSH-2.0-paramiko_2.1.1
DEB [20170210-00:00:23.772] thr=1   paramiko.transport: Remote version/idstring: SSH-2.0-OpenSSH_7.3p1a
INF [20170210-00:00:23.772] thr=1   paramiko.transport: Connected (version 2.0, client OpenSSH_7.3p1a)
DEB [20170210-00:00:23.782] thr=1   paramiko.transport: kex algos:['curve25519-sha256@libssh.org', 'ecdh-sha2-nistp256', 'ecdh-sha2-nistp384', 'ecdh-sha2-nistp521', 'diffie-hellman-group-exchange-sha256', 'diffie-hellman-group16-sha512', 'diffie-hellman-group18-sha512', 'gss-group1-sha256-', 'gss-group14-sha256-', 'gss-gex-sha256-', 'diffie-hellman-group14-sha256', 'diffie-hellman-group14-sha1'] server key:['ssh-rsa', 'rsa-sha2-512', 'rsa-sha2-256', 'ecdsa-sha2-nistp256', 'ssh-ed25519'] client encrypt:['aes256-ctr', 'aes192-ctr', 'aes128-ctr'] server encrypt:['aes256-ctr', 'aes192-ctr', 'aes128-ctr'] client mac:['umac-64-etm@openssh.com', 'umac-128-etm@openssh.com', 'hmac-sha2-256-etm@openssh.com', 'hmac-sha2-512-etm@openssh.com', 'hmac-sha1-etm@openssh.com', 'umac-64@openssh.com', 'umac-128@openssh.com', 'hmac-sha2-256', 'hmac-sha2-512', 'hmac-sha1'] server mac:['umac-64-etm@openssh.com', 'umac-128-etm@openssh.com', 'hmac-sha2-256-etm@openssh.com', 'hmac-sha2-512-etm@openssh.com', 'hmac-sha1-etm@openssh.com', 'umac-64@openssh.com', 'umac-128@openssh.com', 'hmac-sha2-256', 'hmac-sha2-512', 'hmac-sha1'] client compress:['none', 'zlib@openssh.com'] server compress:['none', 'zlib@openssh.com'] client lang:[''] server lang:[''] kex follows?False
DEB [20170210-00:00:23.782] thr=1   paramiko.transport: Kex agreed: diffie-hellman-group14-sha1
DEB [20170210-00:00:23.782] thr=1   paramiko.transport: Cipher agreed: aes128-ctr
DEB [20170210-00:00:23.782] thr=1   paramiko.transport: MAC agreed: hmac-sha2-256
DEB [20170210-00:00:23.782] thr=1   paramiko.transport: Compression agreed: none
DEB [20170210-00:00:23.836] thr=1   paramiko.transport: kex engine KexGroup14 specified hash_algo <built-in function openssl_sha1>
DEB [20170210-00:00:23.837] thr=1   paramiko.transport: Switch to new keys ...
DEB [20170210-00:00:23.893] thr=1   paramiko.transport: userauth is OK
ERR [20170210-00:00:24.007] thr=1   paramiko.transport: Unknown exception: (851968) Unspecified GSS failure.  Minor code may provide more information. Minor code: (2529639053) No Kerberos credentials available. Target: HOSTNAME
ERR [20170210-00:00:24.020] thr=1   paramiko.transport: Traceback (most recent call last):
ERR [20170210-00:00:24.020] thr=1   paramiko.transport:   File "/home/USERNAME/lib/python3.5/site-packages/paramiko-2.1.1-py3.5.egg/paramiko/ssh_gss.py", line 285, in ssh_init_sec_context
ERR [20170210-00:00:24.020] thr=1   paramiko.transport:     token = self._gss_ctxt.step(token)
ERR [20170210-00:00:24.021] thr=1   paramiko.transport:   File "/home/USERNAME/lib/python3.5/site-packages/python_gssapi-0.6.2-py3.5-linux-x86_64.egg/gssapi/ctx.py", line 757, in step
ERR [20170210-00:00:24.021] thr=1   paramiko.transport:     raise _exception_for_status(retval, minor_status[0], None, out_token)
ERR [20170210-00:00:24.021] thr=1   paramiko.transport: gssapi.error.Failure: (851968) Unspecified GSS failure.  Minor code may provide more information. Minor code: (2529639053) No Kerberos credentials available.
ERR [20170210-00:00:24.021] thr=1   paramiko.transport:
ERR [20170210-00:00:24.021] thr=1   paramiko.transport: During handling of the above exception, another exception occurred:
ERR [20170210-00:00:24.021] thr=1   paramiko.transport:
ERR [20170210-00:00:24.021] thr=1   paramiko.transport: Traceback (most recent call last):
ERR [20170210-00:00:24.021] thr=1   paramiko.transport:   File "/home/USERNAME/lib/python3.5/site-packages/paramiko-2.1.1-py3.5.egg/paramiko/transport.py", line 1795, in run
ERR [20170210-00:00:24.021] thr=1   paramiko.transport:     self.auth_handler._handler_table[ptype](self.auth_handler, m)
ERR [20170210-00:00:24.021] thr=1   paramiko.transport:   File "/home/USERNAME/lib/python3.5/site-packages/paramiko-2.1.1-py3.5.egg/paramiko/auth_handler.py", line 264, in _parse_service_accept
ERR [20170210-00:00:24.021] thr=1   paramiko.transport:     self.username,))
ERR [20170210-00:00:24.021] thr=1   paramiko.transport:   File "/home/USERNAME/lib/python3.5/site-packages/paramiko-2.1.1-py3.5.egg/paramiko/ssh_gss.py", line 290, in ssh_init_sec_context
ERR [20170210-00:00:24.021] thr=1   paramiko.transport:     self._gss_host))
ERR [20170210-00:00:24.021] thr=1   paramiko.transport: gssapi.error.GSSException: (851968) Unspecified GSS failure.  Minor code may provide more information. Minor code: (2529639053) No Kerberos credentials available. Target: HOSTNAME
ERR [20170210-00:00:24.021] thr=1   paramiko.transport:
DEB [20170210-00:00:24.023] thr=2   paramiko.transport: Trying discovered key b'1e15eb352834796798e72c7a50eb137e' in /home/USERNAME/.ssh/id_rsa

The question is now twofold:

1) The 'errors' I am getting are hard to start with for me. If anyone with more experience sees a lead, help would be much appreciated.

2) I am not really sure if I am using the gssapi part correctly. For example looking at paramiko gss-api documentation shows that there is paramiko.ssh_gss._SSH_GSSAuth(auth_method, gss_deleg_creds), where I probably have to specify auth_method=gssapi-with-mic, but there is no intuitive way (that works) for me how to use this object and I couldn't find any online examples. Furthermore setting gss_kex=False would make more sense to me but with this option the login attempt stops even earlier. Could anyone shed some light or has a minimal working example of how to use this properly?

Thanks in advance,

(I am aware of this thread Trouble connecting via paramiko + kerberos but unfortunately it remains unanswered and details are missing in the initial post.)

Community
  • 1
  • 1
jg43
  • 111
  • 8
  • Are you running on Windows? Because the Microsoft implementation of Kerberos does not use GSSAPI, but SSPI. So you would need to install "MIT Kerberos for Windows", set up the config file to point to the appropriate Kerberos server *(Microsoft AD?)*, create a Kerberos ticket manually (w/ user/password)... and finally make sure that Python uses the same default cache as MIT Kerberos, cf. http://stackoverflow.com/questions/41763936/kerberos-kinit-on-windows-8-1-leads-to-empty-ticket-cache/41771570 – Samson Scharfrichter Feb 10 '17 at 09:39
  • Hi, no, this is for linux – jg43 Dec 05 '17 at 06:52
  • @jg43 Did you find a fix for this? I am running into a similar problem – xabhi Sep 19 '18 at 16:25
  • no, nothing yet, although it has been a while since i tried, sry – jg43 Jan 26 '19 at 16:31

0 Answers0