Add latest changes from gitlab-org/gitlab@master

3 files changed, 9 insertions, 3 deletions

diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md
index e763a6919f7..c05d8b4b0da 100644
--- a/doc/install/aws/index.md
+++ b/doc/install/aws/index.md
@@ -353,7 +353,7 @@ TIP: **Tip:** If you do not want to maintain bastion hosts, you can set up [AWS
 1. Review all your settings and, if you're happy, click **Launch**.
 1. Acknowledge that you have access to an existing key pair or create a new one. Click **Launch Instance**.
 
-Confirm that you can SHH into the instance:
+Confirm that you can SSH into the instance:
 
 1. On the EC2 Dashboard, click on **Instances** in the left menu.
 1. Select **Bastion Host A** from your list of instances.
@@ -367,6 +367,12 @@ Confirm that you can SHH into the instance:
    1. Under the **Add Tags** section, we’ll set `Key: Name` and `Value: Bastion Host B` so that we can easily identify our two instances.
    1. For the security group, select the existing `bastion-sec-group` we created above.
 
+### Use SSH Agent Forwarding
+
+EC2 instances running Linux use private key files for SSH authentication. You'll connect to your bastion host using an SSH client and the private key file stored on your client. Since the private key file is not present on the bastion host, you will not be able to connect to your instances in private subnets.
+
+Storing private key files on your bastion host is a bad idea. To get around this, use SSH agent forwarding on your client. See [Securely Connect to Linux Instances Running in a Private Amazon VPC](https://aws.amazon.com/blogs/security/securely-connect-to-linux-instances-running-in-a-private-amazon-vpc/) for a step-by-step guide on how to use SSH agent forwarding.
+
 ## Deploying GitLab inside an auto scaling group
 
 We'll use AWS's wizard to deploy GitLab and then SSH into the instance to
diff --git a/doc/install/installation.md b/doc/install/installation.md
index 61d04258e31..c742d9ca464 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -563,7 +563,7 @@ NOTE: **Note:**
 If you want to use HTTPS, see [Using HTTPS](#using-https) for the additional steps.
 
 NOTE: **Note:**
-Make sure your hostname can be resolved on the machine itself by either a proper DNS record or an additional line in `/etc/hosts` ("127.0.0.1  hostname"). This might be necessary, for example, if you set up GitLab behind a reverse proxy. If the hostname cannot be resolved, the final installation check will fail with `Check GitLab API access: FAILED. code: 401` and pushing commits will be rejected with `[remote rejected] master -> master (hook declined)`.
+Make sure your hostname can be resolved on the machine itself by either a proper DNS record or an additional line in `/etc/hosts` ("127.0.0.1 hostname"). This might be necessary, for example, if you set up GitLab behind a reverse proxy. If the hostname cannot be resolved, the final installation check will fail with `Check GitLab API access: FAILED. code: 401` and pushing commits will be rejected with `[remote rejected] master -> master (hook declined)`.
 
 NOTE: **Note:**
 GitLab Shell application startup time can be greatly reduced by disabling RubyGems. This can be done in several ways:
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index cfab6352e46..a6bea3938b3 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -42,7 +42,7 @@ Please consider using a virtual machine to run GitLab.
 
 ### Ruby versions
 
-GitLab requires Ruby (MRI) 2.6. Beginning in GitLab 12.2, we  no longer support Ruby 2.5 and lower.
+GitLab requires Ruby (MRI) 2.6. Beginning in GitLab 12.2, we no longer support Ruby 2.5 and lower.
 
 You must use the standard MRI implementation of Ruby.
 We love [JRuby](https://www.jruby.org/) and [Rubinius](https://rubinius.com), but GitLab