{ "info": { "author": "Ken Kundert", "author_email": "sshdeploy@nurdletech.com", "bugtrack_url": null, "classifiers": [ "Development Status :: 3 - Alpha", "Environment :: Console", "Intended Audience :: End Users/Desktop", "License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+)", "Natural Language :: English", "Operating System :: POSIX :: Linux", "Programming Language :: Python :: 3.5", "Topic :: Utilities" ], "description": "---------------------------------------------\nSSH Deploy - Generate and Distribute SSH Keys\n---------------------------------------------\n\n\nSYNOPSIS\n========\n\nsshdeploy [options] generate\nsshdeploy [options] test\nsshdeploy [options] hosts\nsshdeploy [options] distribute\nsshdeploy [options] clean\nsshdeploy manual\n\n\nOPTIONS\n=======\n-c , --config-file file that contains list of keys to generate \n and the hosts that should receive the keys \n (sshdeploy.conf is default).\n-d , --keydir name of directory for holding new keys\n ('keys-YYYY-MM-DD' is default).\n-u , --update hosts to update\n-s , --skip hosts to skip\n-k , --keys keys to update (only use with --trial-run)\n-t, --trial-run try run (do not overwrite working ssh files)\n-n, --narrate narrate the process\n-v, --verbose narrate the process more verbosely\n-h, --help print usage summary\n\nYou specify multiple hosts or keys using a comma-separated list.\n\nWith the --trial-run (or -t) option sshdeploy still generates the keys and \ncopies them to the remote hosts, but when doing so it will add '.provisional' \nas a suffix to the files to that they do not overwrite existing working files. \n\nThe -g, -d, -u, -s, -k, and -t options are used largely for debugging and \ngaining confidence that the distribution process will run correctly. It is best \nnot to use any of these options when doing an actual push of your keys.\n\n\nDESCRIPTION\n===========\n\nSSH Deploy reads a configuration file that contains information about the SSH \nkeys you use. Using this information it will regenerate and distribute your \nkeys. When generating your keys a passcode is needed. SSH Deploy uses the \nAbraxas collaborative password generator to securely generate the passcodes. \nThis avoids the need for you to interactively enter the passcodes.\n\nsshdeploy generate\n******************\n\nThe generate command regenerates the SSH key pairs.\n\nsshdeploy distribute\n********************\n\nThe distribute command copies the SSH key pair to to the clients and the \nauthorized_keys files to the servers. It can only be run after the generate key \nhas been run. Before it runs it will clean out any .provisional files from \nprevious trial runs.\n\nsshdeploy test\n**************\n\nThe test command checks the connection with each of the hosts (the clients and \nservers). It should be run before distribute to assure that each of the hosts \nis accessible.\n\nsshdeploy hosts\n***************\n\nThe hosts command simply lists out the hosts. Hosts include the servers that \nwill receive the authorized_keys file and the clients that will receive the SSH \nkey pairs.\n\nsshdeploy clean\n***************\n\nThe clean command removes the .provisional files from each of the hosts. The \n.provisional files are created during a trial run of the distribute command.\n\nsshdeploy manual\n****************\n\nThe manual command displays a detailed description of the program and how to use \nit.\n\n\nCONFIGURATION\n=============\n\nThe configuration file is a python file. The name of the file is arbitrary (the \ndefault is sshdeploy.conf). Here is a typical configuration file::\n\n Keys = {\n 'earth': {\n 'purpose': 'This key allows access from earth (primary laptop)',\n 'keygen-options': \"-t ed25519\",\n 'servers': {\n 'earth': {},\n 'mercury': {\n 'description': 'Access is funneled through Jupiter',\n 'restrictions': ['from=jupiter']\n },\n 'jupiter': {},\n },\n 'clients': {\n 'earth': {},\n },\n },\n 'phone': {\n 'purpose': \"This key allows access from the phone\",\n 'servers': {\n 'jupiter': {\n 'description': 'Only allows access to mail ports',\n 'restrictions': [\n 'no-agent-forwarding',\n 'no-pty',\n 'no-X11-forwarding',\n 'permitopen=\"pubmail:587\"',\n 'permitopen=\"pubmail:993\"',\n ],\n },\n },\n },\n 'backups': {\n 'purpose': \"This key allows sftp access to jupiter for backups.\",\n 'servers': {\n 'jupiter': {\n 'description': 'This key is not protected with a passphrase!',\n 'restrictions': [\n 'from=\"192.168.1.0/24\"',\n 'no-agent-forwarding',\n 'no-port-forwarding',\n 'no-pty',\n 'no-X11-forwarding',\n 'command=\".ssh/only-sftp.sh\"',\n ],\n },\n },\n 'servers': {\n 'earth': {},\n 'mercury': {},\n },\n },\n }\n\nWhen sshdeploy reads this file, it uses the value of several local variables \n('keygen_options', 'abraxas_account', 'remote_include_filename', and 'keys') to \ndetermine its behavior.\n\nKeygen Options\n**************\nA string that is passed to ssh-keygen to influence the generation of key. If \nnot specified, the following will be used: '-t rsa -b 4096'. This value is used \nas the default for all keys and its value may be overridden in individual keys.\n\nAbraxas Account\n***************\nWhen the private keys are generated a passcode is needed to secure the private \nkey. SSH Deploy uses the Abraxas password manager to provide the needed \npasscodes. The value of this variable is a string that is used as the default \nAbraxas account name for for all keys and its value may be overridden in \nindividual keys.\n\nRemote Include Filename\n***********************\nBefore SSH Deploy generates an authorized_keys file for a server, it will look \nfor a file in the server's ~/.ssh directory that contains public keys for keys \nnot managed by SSH Deploy that should be included in the authorized_keys file. \nThe value of this variable is the name of that file.\n\nKeys\n****\nKeys is a dictionary where there is one entry per SSH key to be generated. The \ntag for the entry is the name of the SSH key and the value is a dictionary that \ncontains information that controls how the key is generated and distributed. \nThese dictionaries may contain the keys 'purpose', 'keygen-options', \n'abraxas-account', 'servers', and 'clients'.\n\nPurpose\n-------\nThe purpose if given is simply a textual description of the purpose of\nthe key. It will be added as a comment above the public key when it is\nadded to the authorized key file.\n\nKeygen Options\n--------------\nA string that is passed to ssh-keygen to influence the generation of\nkey. If not specified, the following will be used: '-t rsa -b 4096'.\n\nAbraxas Account\n---------------\nWhen the private keys are generated a passcode is needed to secure the private \nkey. SSH Deploy uses the Abraxas password manager to provide the needed \npasscodes. This value overrides the default value for this particular key. If \nthe value is specified as None, then the private key will not be protected by \na passcode.\n\nServers\n-------\nThe servers key contains a dictionary where its keys would be the SSH\nnames of servers whose authorized_keys file that should receive the\npublic key. The value of the servers key is also a dictionary that may\nbe empty or may contain the following keys: 'description', 'restrictions', \n'remote-include-filename', and 'bypass'.\n\nDescription\n'''''''''''\nThe description is simply a second level of textual description for the\npublic key (generally explains the restrictions).\n\nRestrictions\n''''''''''''\nThe value of restrictions is a list of SSH key restrictions. These\nrestrictions are comma joined and placed before the public key in the\nauthorized key file.\n\nRemote Include Filename\n'''''''''''''''''''''''\nBefore SSH Deploy generates an authorized_keys file for a server, it will look \nfor a file in the server's ~/.ssh directory that contains public keys for keys \nnot managed by SSH Deploy that should be included in the authorized_keys file. \nThe value of this variable is the name of that file.\n\nIn an configuration file the same server may be referenced many times, once per \nkey. The remote include file is only read the first time a server is \nencountered (they are processed in alphabetic order). It is recommended that if \nthis value is given, it be given consistently in each instance of a server, \notherwise warnings will be issued and each value except the first will be \nignored.\n\nIf the value is None, an include is not performed.\n\nBypass\n''''''\nSome servers, particularly commercial cloud servers, do not allow you to upload \nan authorized_keys file using sftp. Instead they generally provide a way \nthrough their web portal. In these cases you should specify bypass to be true. \nDoing so will prevent sshdeploy from attempting to upload the file and will \ncause it to emit a warning that acts as a reminder that you must upload your \nfile manually.\n\nClients\n-------\nThe clients key contains a dictionary where its keys would be the SSH\nnames of client hosts that should receive the private and public key.\nThe value of the servers key is also a dictionary that should be empty\n(at this point any contents will be ignored).\n\n\nKEY STRATEGIES\n==============\n\nSeveral key strategies can be implemented efficiently with SSH Deploy.\n\nOne Key Per Server\n******************\nWith this strategy SSH keys are never shared between servers, meaning that one \nserver could not use its key to access another. Normally this cross access \nwould not be possible anyway, but if there were a bug in SSH it could \nconceivably leak the private key to an untrusted server. Since in this strategy \nthe key for each server is unique, a leak would not compromise the other \nservers.\n\nOne Key Per Client\n******************\nWith this strategy the server can distinguish the client that is requesting \na connection. Thus a particular client can be blocked or restrictions placed on \nits access.\n\nOther Strategies\n****************\nUsing single key for each server/client pair can give the best security and \nflexibility, but may be tedious to configure and maintain. Alternatively, you \nmight adapt your strategy to provide the security and flexibility appropriate to \nyou various servers and clients.\n\n\nDISTRIBUTING YOUR KEYS\n======================\n\nDistributing your keys is inherently a dangerous endeavor because if you make \na mistake you will likely lose the ability to log into one of your hosts, which \nwould prevent you from fixing the mistake. To reduce the risk of being locked \nout of a remote host, sshdeploy several features that reduce the risk. One is \nthe test command, which allows you to verify that all of your hosts are \navailable before you update your keys, and that they are still available after \nyou update them. Another feature is the --trial-run option. When specified, \nsshdeploy will add the .provisional suffix to any file it copies to a remote \nhost. Thus, the basic strategy is to run distribute command with the \n--trial-run option while carefully examining the provisional files to make sure \neverything working as expected. Running sshdeploy with many keys and hosts can \nbe time consuming, so several command line options are provide that allow you to \nlimit your activities to particular keys (--keys), particular servers (--update, \n--skip), and particular phases (--generate-only, --distribute-only). In \naddition, sshdeploy also provides the --narrate and --verbose options to make \nsshdeploy's activities more obvious to you.\n\nOnce you are confident that things are configured properly, it is recommended \nthat you follow the following process to generate and distribute your ssh keys.\n\n1. Generate your new keys with::\n\n sshdeploy generate\n\n2. Make sure all of your hosts (servers and clients) are up and accessible. You \n can do that with::\n \n sshdeploy test\n \n However, it is even better for you to simply open and keep active a ssh or \n sftp process to each of the remote hosts. Leave them open until all of your \n hosts are known to work. That way if there is a problem that corrupts the \n authorized_keys file, you still have access and can correct any problems.\n\n3. Do a full trial run of distribute::\n\n sshdeploy -t distribute\n \n Confirm that provisional versions of all of your ssh keys and authorized_keys \n files are being properly created and distributed to all of your hosts. You \n can first look in the keys directory to make sure the right authorized_keys \n files are generate. Then you should check the .provisional files on the \n remote hosts.\n\n4. Run distribute for real::\n\n sshdeploy distribute\n\n Do not add --trial-run, --update, --skip, or --keys to the list of command \n line options. It is also recommended that you do not split the process into \n two commands by using --generate-only or --distribute-only.\n\n5. Immediately after the update, start a new ssh-agent in a new shell and add \n your new keys. If you have ControlMaster in your SSH config file, you should \n remove it for the duration of the testing. If you do not do this, your \n testing may use your existing connections, which would conceal problems.\n\n6. Thoroughly test your access to your hosts. If you lose access, you can use \n use either existing connections or your original ssh-agent to regain access.\n\nSEE ALSO\n========\nabraxas\nsshconfig\n\n\nInstallation\n============\n\nIf you plan to use SSH Deploy without modifying it, the preferred way to \ninstall it for multiple users is::\n\n pip install --update sshdeploy\n\nDoing so generally requires root permissions. Alternately, you can install it \njust for yourself using::\n\n pip install --user --update sshdeploy\n\nThis installs sshdeploy into ~/.local and so does not require root permissions.\n\nIf you would like to change the program, you should first clone it's source \nrepository and then install it::\n\n git clone https://github.com/KenKundert/sshdeploy.git\n cd sshdeploy\n python setup.py install --user", "description_content_type": null, "docs_url": null, "download_url": "https://github.com/kenkundert/sshdeploy/tarball/master", "downloads": { "last_day": -1, "last_month": -1, "last_week": -1 }, "home_page": "http://nurdletech.com/linux-utilities/sshdeploy", "keywords": "ssh,keys", "license": "GPLv3+", "maintainer": null, "maintainer_email": null, "name": "sshdeploy", "package_url": "https://pypi.org/project/sshdeploy/", "platform": "UNKNOWN", "project_url": "https://pypi.org/project/sshdeploy/", "project_urls": { "Download": "https://github.com/kenkundert/sshdeploy/tarball/master", "Homepage": "http://nurdletech.com/linux-utilities/sshdeploy" }, "release_url": "https://pypi.org/project/sshdeploy/1.1.4/", "requires_dist": null, "requires_python": null, "summary": "Generates and distributes SSH keys.", "version": "1.1.4" }, "last_serial": 1938633, "releases": { "1.0.0": [], "1.1.0": [ { "comment_text": "", "digests": { "md5": "c09bf167838bfd31ff29558a78e5049f", "sha256": "00c4447c1ec857aea21402005e5b2674fc93ba0c41e43c9acee9c7c4353e59f0" }, "downloads": -1, "filename": "sshdeploy-1.1.0.tar.gz", "has_sig": false, "md5_digest": "c09bf167838bfd31ff29558a78e5049f", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 10715, "upload_time": "2016-01-31T08:33:28", "url": "https://files.pythonhosted.org/packages/8d/d5/50c29a71c3b77bc6c05aab58567c69e5075e66ecc348bf6d2773c436156d/sshdeploy-1.1.0.tar.gz" } ], "1.1.1": [ { "comment_text": "", "digests": { "md5": "7caf1721f147d5801ff861907f12ea8a", "sha256": "5b615c5cca80ef30e3e3e030619e81954595951b6b9973c33db593f40df5a521" }, "downloads": -1, "filename": "sshdeploy-1.1.1.tar.gz", "has_sig": false, "md5_digest": "7caf1721f147d5801ff861907f12ea8a", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 11015, "upload_time": "2016-01-31T17:55:04", "url": "https://files.pythonhosted.org/packages/6e/fe/1144e3663a68adf8885a519ffcffad2700bb61fa4f769c32460918dc2b32/sshdeploy-1.1.1.tar.gz" } ], "1.1.2": [ { "comment_text": "", "digests": { "md5": "8d278be078135d86845f271b792b7c37", "sha256": "1a45e02145a41ca0efa578dea9b33c9e775632f1885f38d5e693af23dd34de0a" }, "downloads": -1, "filename": "sshdeploy-1.1.2.tar.gz", "has_sig": false, "md5_digest": "8d278be078135d86845f271b792b7c37", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 11065, "upload_time": "2016-02-01T01:24:49", "url": "https://files.pythonhosted.org/packages/d5/2f/467d60ea07dce43906cb4f39297956b2e69634474e363ba08c1e8062627c/sshdeploy-1.1.2.tar.gz" } ], "1.1.3": [ { "comment_text": "", "digests": { "md5": "be745b2d6f96d2dfd29d8278ba9370f5", "sha256": "7323bea7e35544911512584dc505f2764e7ad3f6384d6e7416db402c0eb101f6" }, "downloads": -1, "filename": "sshdeploy-1.1.3.tar.gz", "has_sig": false, "md5_digest": "be745b2d6f96d2dfd29d8278ba9370f5", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 15518, "upload_time": "2016-02-01T06:41:05", "url": "https://files.pythonhosted.org/packages/30/52/d8bedeb960117d245d4a320c261d22d6d201bc6167bb041b4235130a9cdd/sshdeploy-1.1.3.tar.gz" } ], "1.1.4": [ { "comment_text": "", "digests": { "md5": "b3ce171d2907b81b301d7dbb3b4f5cc1", "sha256": "2fd9934aed4a6c37dadc609f64b6e28ea45cf9073e7ee62f304cb9cfa3b47140" }, "downloads": -1, "filename": "sshdeploy-1.1.4.tar.gz", "has_sig": false, "md5_digest": "b3ce171d2907b81b301d7dbb3b4f5cc1", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 15502, "upload_time": "2016-02-04T01:27:50", "url": "https://files.pythonhosted.org/packages/39/a2/603a63c494a9f45eecdccf043e71f5e0b3581df225ba995d0dc7ee5abce3/sshdeploy-1.1.4.tar.gz" } ] }, "urls": [ { "comment_text": "", "digests": { "md5": "b3ce171d2907b81b301d7dbb3b4f5cc1", "sha256": "2fd9934aed4a6c37dadc609f64b6e28ea45cf9073e7ee62f304cb9cfa3b47140" }, "downloads": -1, "filename": "sshdeploy-1.1.4.tar.gz", "has_sig": false, "md5_digest": "b3ce171d2907b81b301d7dbb3b4f5cc1", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 15502, "upload_time": "2016-02-04T01:27:50", "url": "https://files.pythonhosted.org/packages/39/a2/603a63c494a9f45eecdccf043e71f5e0b3581df225ba995d0dc7ee5abce3/sshdeploy-1.1.4.tar.gz" } ] }