Rename ansible_ssh_{host,port,user} in docs to ansible_*

The _ssh variants will continue to work, but the shorter, more generic
names are preferred now.

docsite/rst/faq.rst

@@ -24,8 +24,8 @@ Setting inventory variables in the inventory file is the easiest way.
 For instance, suppose these hosts have different usernames and ports::
 
     [webservers]
-    asdf.example.com  ansible_ssh_port=5000   ansible_ssh_user=alice
-    jkl.example.com   ansible_ssh_port=5001   ansible_ssh_user=bob
+    asdf.example.com  ansible_port=5000   ansible_user=alice
+    jkl.example.com   ansible_port=5001   ansible_user=bob
 
 You can also dictate the connection type to be used, if you want::
 
@@ -66,8 +66,8 @@ ssh command line when connecting to the relevant host(s), so it's a good
 way to set a `ProxyCommand`. Consider the following inventory group:
 
     [gatewayed]
-    foo ansible_ssh_host=192.0.2.1
-    bar ansible_ssh_host=192.0.2.2
+    foo ansible_host=192.0.2.1
+    bar ansible_host=192.0.2.2
 
 You can create `group_vars/gatewayed.yml` with the following contents:
 

docsite/rst/guide_rax.rst

@@ -129,7 +129,7 @@ The rax module returns data about the nodes it creates, like IP addresses, hostn
       local_action:
           module: add_host 
           hostname: "{{ item.name }}"
-          ansible_ssh_host: "{{ item.rax_accessipv4 }}"
+          ansible_host: "{{ item.rax_accessipv4 }}"
           ansible_ssh_pass: "{{ item.rax_adminpass }}"
           groups: raxhosts
       with_items: rax.success
@@ -198,7 +198,7 @@ following information, which will be utilized for inventory and variables.
         "_meta": {
             "hostvars": {
                 "test": {
-                    "ansible_ssh_host": "1.1.1.1",
+                    "ansible_host": "1.1.1.1",
                     "rax_accessipv4": "1.1.1.1",
                     "rax_accessipv6": "2607:f0d0:1002:51::4",
                     "rax_addresses": {
@@ -310,7 +310,7 @@ This can be achieved with the ``rax_facts`` module and an inventory file similar
             region: "{{ rax_region }}"
         - name: Map some facts
           set_fact:
-            ansible_ssh_host: "{{ rax_accessipv4 }}"
+            ansible_host: "{{ rax_accessipv4 }}"
 
 While you don't need to know how it works, it may be interesting to know what kind of variables are returned.
 
@@ -516,9 +516,9 @@ Build a complete webserver environment with servers, custom networks and load ba
           local_action:
             module: add_host
             hostname: "{{ item.name }}"
-            ansible_ssh_host: "{{ item.rax_accessipv4 }}"
+            ansible_host: "{{ item.rax_accessipv4 }}"
             ansible_ssh_pass: "{{ item.rax_adminpass }}"
-            ansible_ssh_user: root
+            ansible_user: root
             groups: web
           with_items: rax.success
           when: rax.action == 'create'
@@ -601,9 +601,9 @@ Using a Control Machine
           local_action:
             module: add_host
             hostname: "{{ item.name }}"
-            ansible_ssh_host: "{{ item.rax_accessipv4 }}"
+            ansible_host: "{{ item.rax_accessipv4 }}"
             ansible_ssh_pass: "{{ item.rax_adminpass }}"
-            ansible_ssh_user: root
+            ansible_user: root
             rax_id: "{{ item.rax_id }}"
             groups: web,new_web
           with_items: rax.success

docsite/rst/guide_vagrant.rst

@@ -103,7 +103,7 @@ inventory file may look something like this:
 
     # Generated by Vagrant
 
-    machine ansible_ssh_host=127.0.0.1 ansible_ssh_port=2222
+    machine ansible_host=127.0.0.1 ansible_port=2222
 
 If you want to run Ansible manually, you will want to make sure to pass
 ``ansible`` or ``ansible-playbook`` commands the correct arguments for the

docsite/rst/intro_inventory.rst

@@ -48,7 +48,7 @@ To make things explicit, it is suggested that you set them if things are not run
 
 Suppose you have just static IPs and want to set up some aliases that live in your host file, or you are connecting through tunnels.  You can also describe hosts like this::
 
-    jumper ansible_ssh_port=5555 ansible_ssh_host=192.168.1.50
+    jumper ansible_port=5555 ansible_host=192.168.1.50
 
 In the above example, trying to ansible against the host alias "jumper" (which may not even be a real hostname) will contact 192.168.1.50 on port 5555.  Note that this is using a feature of the inventory file to define some special variables.  Generally speaking this is not the best
 way to define variables that describe your system policy, but we'll share suggestions on doing this later.  We're just getting started.
@@ -69,8 +69,8 @@ You can also select the connection type and user on a per host basis::
    [targets]
 
    localhost              ansible_connection=local
-   other1.example.com     ansible_connection=ssh        ansible_ssh_user=mpdehaan
-   other2.example.com     ansible_connection=ssh        ansible_ssh_user=mdehaan
+   other1.example.com     ansible_connection=ssh        ansible_user=mpdehaan
+   other2.example.com     ansible_connection=ssh        ansible_user=mdehaan
 
 As mentioned above, setting these in the inventory file is only a shorthand, and we'll discuss how to store them in individual files
 in the 'host_vars' directory a bit later on.
@@ -201,11 +201,11 @@ Host connection::
 
 SSH connection::
 
-    ansible_ssh_host
+    ansible_host
       The name of the host to connect to, if different from the alias you wish to give to it.
-    ansible_ssh_port
+    ansible_port
       The ssh port number, if not 22
-    ansible_ssh_user
+    ansible_user
       The default ssh user name to use.
     ansible_ssh_pass
       The ssh password to use (this is insecure, we strongly recommend using --ask-pass or SSH keys)
@@ -244,7 +244,7 @@ Remote host environment parameters::
 
 Examples from a host file::
 
-  some_host         ansible_ssh_port=2222     ansible_ssh_user=manager
+  some_host         ansible_port=2222     ansible_user=manager
   aws_host          ansible_ssh_private_key_file=/home/example/.ssh/aws.pem
   freebsd_host      ansible_python_interpreter=/usr/local/bin/python
   ruby_module_host  ansible_ruby_interpreter=/usr/bin/ruby.1.9.3

docsite/rst/intro_windows.rst

@@ -86,14 +86,14 @@ In group_vars/windows.yml, define the following inventory variables::
     # it is suggested that these be encrypted with ansible-vault:
     # ansible-vault edit group_vars/windows.yml
 
-    ansible_ssh_user: Administrator
+    ansible_user: Administrator
     ansible_ssh_pass: SecretPasswordGoesHere
-    ansible_ssh_port: 5986
+    ansible_port: 5986
     ansible_connection: winrm
 
 Notice that the ssh_port is not actually for SSH, but this is a holdover variable name from how Ansible is mostly an SSH-oriented system.  Again, Windows management will not happen over SSH.
 
-If you have installed the ``kerberos`` module and ``ansible_ssh_user`` contains ``@`` (e.g. ``username@realm``), Ansible will first attempt Kerberos authentication. *This method uses the principal you are authenticated to Kerberos with on the control machine and not ``ansible_ssh_user``*. If that fails, either because you are not signed into Kerberos on the control machine or because the corresponding domain account on the remote host is not available, then Ansible will fall back to "plain" username/password authentication.
+If you have installed the ``kerberos`` module and ``ansible_user`` contains ``@`` (e.g. ``username@realm``), Ansible will first attempt Kerberos authentication. *This method uses the principal you are authenticated to Kerberos with on the control machine and not ``ansible_user``*. If that fails, either because you are not signed into Kerberos on the control machine or because the corresponding domain account on the remote host is not available, then Ansible will fall back to "plain" username/password authentication.
 
 When using your playbook, don't forget to specify --ask-vault-pass to provide the password to unlock the file.
 

docsite/rst/playbooks_variables.rst

@@ -732,7 +732,7 @@ a use for it.
 If multiple variables of the same name are defined in different places, they win in a certain order, which is::
 
     * extra vars (-e in the command line) always win
-    * then comes connection variables defined in inventory (ansible_ssh_user, etc)
+    * then comes connection variables defined in inventory (ansible_user, etc)
     * then comes "most everything else" (command line switches, vars in play, included vars, role vars, etc)
     * then comes the rest of the variables defined in inventory
     * then comes facts discovered about a system