{"action":"created","issue":{"url":"https://api.github.com/repos/fabric/fabric/issues/1618","repository_url":"https://api.github.com/repos/fabric/fabric","labels_url":"https://api.github.com/repos/fabric/fabric/issues/1618/labels{/name}","comments_url":"https://api.github.com/repos/fabric/fabric/issues/1618/comments","events_url":"https://api.github.com/repos/fabric/fabric/issues/1618/events","html_url":"https://github.com/fabric/fabric/issues/1618","id":233313469,"number":1618,"title":"Modernize auth/key handling","user":{"login":"bitprophet","id":6088,"avatar_url":"https://avatars2.githubusercontent.com/u/6088?v=4","gravatar_id":"","url":"https://api.github.com/users/bitprophet","html_url":"https://github.com/bitprophet","followers_url":"https://api.github.com/users/bitprophet/followers","following_url":"https://api.github.com/users/bitprophet/following{/other_user}","gists_url":"https://api.github.com/users/bitprophet/gists{/gist_id}","starred_url":"https://api.github.com/users/bitprophet/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bitprophet/subscriptions","organizations_url":"https://api.github.com/users/bitprophet/orgs","repos_url":"https://api.github.com/users/bitprophet/repos","events_url":"https://api.github.com/users/bitprophet/events{/privacy}","received_events_url":"https://api.github.com/users/bitprophet/received_events","type":"User","site_admin":false},"labels":[{"id":618638815,"url":"https://api.github.com/repos/fabric/fabric/labels/Authentication/Keys","name":"Authentication/Keys","color":"d93f0b","default":false},{"id":140141,"url":"https://api.github.com/repos/fabric/fabric/labels/Feature","name":"Feature","color":"40a056","default":false},{"id":140151,"url":"https://api.github.com/repos/fabric/fabric/labels/Refactoring","name":"Refactoring","color":"ededed","default":false},{"id":140140,"url":"https://api.github.com/repos/fabric/fabric/labels/Wart","name":"Wart","color":"e10c02","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/fabric/fabric/milestones/24","html_url":"https://github.com/fabric/fabric/milestone/24","labels_url":"https://api.github.com/repos/fabric/fabric/milestones/24/labels","id":742771,"number":24,"title":"2.0","description":"Initial 2.0 release, backwards incompatible with 1.x, based heavily on use of https://github.com/pyinvoke/invoke","creator":{"login":"bitprophet","id":6088,"avatar_url":"https://avatars2.githubusercontent.com/u/6088?v=4","gravatar_id":"","url":"https://api.github.com/users/bitprophet","html_url":"https://github.com/bitprophet","followers_url":"https://api.github.com/users/bitprophet/followers","following_url":"https://api.github.com/users/bitprophet/following{/other_user}","gists_url":"https://api.github.com/users/bitprophet/gists{/gist_id}","starred_url":"https://api.github.com/users/bitprophet/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bitprophet/subscriptions","organizations_url":"https://api.github.com/users/bitprophet/orgs","repos_url":"https://api.github.com/users/bitprophet/repos","events_url":"https://api.github.com/users/bitprophet/events{/privacy}","received_events_url":"https://api.github.com/users/bitprophet/received_events","type":"User","site_admin":false},"open_issues":25,"closed_issues":19,"state":"open","created_at":"2014-08-04T21:50:58Z","updated_at":"2017-06-02T22:10:52Z","due_on":null,"closed_at":null},"comments":0,"created_at":"2017-06-02T22:01:16Z","updated_at":"2017-08-26T00:49:54Z","closed_at":null,"body":"## Immediate problem\r\n\r\nFab v2 currently stinks for real-world auth situations where you have multiple keys (say, github + server, or personal + work, or combinations thereof, or etc), and/or multiple sources for those keys (such as `~/.ssh`, an SSH agent, or in-memory keys taken out of a secrets store, etc). This is because none of the auth handling from v1 has been ported. Thus, it's quite easy to encounter Paramiko-level `AuthenticationException` or `SSHException`. (The best method to avoid that, at present, is to rely on how Paramiko tries all agent keys, as all key types, before giving up -- and thus to make sure the right key is early in your agent list.)\r\n\r\nThe deeper problem is that the auth handling from v1 is pretty gross, because Paramiko's auth handling is somewhat gross, and it'd be _nice_ not to just port it directly.\r\n\r\n## Background\r\n\r\nThere are a handful of related issues (arguably some should already be closed as dupes) in the [Auth/Keys label](https://github.com/fabric/fabric/labels/Authentication%2FKeys) that have been warts forever. High level/consolidated overview:\r\n\r\n- First, Paramiko's own auth handling is shit, and needs improvements. (See paramiko/paramiko#387.)\r\n  - Fabric 1 has to guess constantly about what a given Paramiko exception instance truly means, based on what parameters the Fabric level has handy (such as presence or lack of a password value).\r\n  - We can't usefully improve until Paramiko raises usefully distinct errors, at the very least, such as an aggregate error noting which keys were tried and how each of them failed (e.g. \"I tried <some RSA in-memory pkey> and it was rejected; and I tried <some EC from-file pkey> but it appeared to be encrypted and you didn't give a passphrase; finally I tried <some agent key> but it didn't actually seem to be ANY key type I recognize\")\r\n  - Possibly also want to clean up the params of `Client.connect` (though those are not super duper awful, on their own.)\r\n- Aside from that, Fabric v1 has its own old, naive assumptions about the world:\r\n  - That there's only ever a single explicit username, password and/or key to use globally instead of on a per-host basis.\r\n    - This ties strongly into #4, and is already mostly-solved simply by having `Connection` objects which carry their own non-shared config data;\r\n    - Though the CLI-flag use case still has issues, since there's no good way to 'tag' flags as being 'for' a given host. That said, config files (SSH and Invoke/Fabric level) are a thing, so...\r\n  - The `password` setting does double duty as both true *password* auth as well as key *passphrase*. This has always been gross. EDIT: actually, this is Paramiko's fault too! It's where that behavior is implemented.\r\n    - At the very least, these concepts need to be made into distinct CLI flags and config settings;\r\n    - Presumably including multiple \"prompt me up front\" options, as we had already in v1 for the one password setting.\r\n      - And going by my thoughts around Invoke's implementation of `sudo`, we may well want to do away with 'lazy' runtime prompting entirely.\r\n- Then there's other random stuff that probably needs to be their own tickets:\r\n  - Support for an OS-level keychain for key passphrases (i.e. OpenSSH `UseKeychain`, at least on OS X Sierra) - this likely wants to be in Paramiko like agent support.\r\n\r\n## Solution brainstorm\r\n\r\n- Ideal: get out a Paramiko 3.0 with an overhauled auth handler logic core, and wrap it with a nice, gentle, compact bit of logic at the Fabric level. Sadly this will take time.\r\n- Fast but crappy: just port v1's `connect` logic which loops-until-success and does chicken-entrail level divination about any resulting Paramiko errors.\r\n- Meet halfway: implement enough functionality (which is, typically, required either way) to let users specify very exact auth parameters (including up-front passphrase entry and/or keychain integration) so they can ensure Paramiko gets the right key or password for a given host."},"comment":{"url":"https://api.github.com/repos/fabric/fabric/issues/comments/325065947","html_url":"https://github.com/fabric/fabric/issues/1618#issuecomment-325065947","issue_url":"https://api.github.com/repos/fabric/fabric/issues/1618","id":325065947,"user":{"login":"radssh","id":8227350,"avatar_url":"https://avatars2.githubusercontent.com/u/8227350?v=4","gravatar_id":"","url":"https://api.github.com/users/radssh","html_url":"https://github.com/radssh","followers_url":"https://api.github.com/users/radssh/followers","following_url":"https://api.github.com/users/radssh/following{/other_user}","gists_url":"https://api.github.com/users/radssh/gists{/gist_id}","starred_url":"https://api.github.com/users/radssh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/radssh/subscriptions","organizations_url":"https://api.github.com/users/radssh/orgs","repos_url":"https://api.github.com/users/radssh/repos","events_url":"https://api.github.com/users/radssh/events{/privacy}","received_events_url":"https://api.github.com/users/radssh/received_events","type":"User","site_admin":false},"created_at":"2017-08-26T00:49:54Z","updated_at":"2017-08-26T00:49:54Z","body":"Hi @bitprophet - hopping in from the Paramiko side 😃\r\n\r\nNot sure where you want to officially track the underlying overhaul of the \"terribad\" (love that term, btw) key/auth handling that's been lingering, and want to volunteer to assist in addressing a potential cleanup/reorg/rearchitect to stop the accumulation of tacking on the \"good enough for now\" cumulative bits and pieces. Probably would take a Paramiko 3.0 goal to break loose from the chains of maintaining backward compatibility - I've tinkered with some ideas, but that compatibility thing, yuck...\r\n\r\nThis topic seems better suited to the Paramiko issue, so I chose to drop this here, but can continue the dialog wherever you deem most appropriate."}}
{"actor":{"display_login":"radssh"}}