☰

Amazon Web Service (AWS) VPC-Privatsubnetzinstanz „Zugriff verweigert (öffentlicher Schlüssel)“ – SSH von OSX

tag-icon • tag-icon ssh amazon-ec2 amazon-web-services
Amazon Web Service (AWS) VPC-Privatsubnetzinstanz „Zugriff verweigert (öffentlicher Schlüssel)“ – SSH von OSX

Ich verbinde mich über eine NAT-Instanz mit einer Amazon Web Service (AWS) EC2-Instanz im privaten Subnetz eines virtuellen privaten Servers und erhalte die folgende Fehlermeldung:

Berechtigung verweigert (öffentlicher Schlüssel)

Dies geschieht, nachdem ich eine Verbindung zum NAT hergestellt habe und versuche, per SSH auf die EC2-Instanz des privaten Subnetzes zuzugreifen.

Verfahren:

  1. Definieren Sie den Host ~/.ssh/configwie folgt:

    Host my_aws_nat
Hostname xx.xx.xx.xx
User ec2-user
IdentityFile /location/of/my/aws/key_pair.pem
ForwardAgent yes

  2. SSH zur NAT-Instanz über ssh my_aws_nat(was erfolgreich ist)

  3. SSH zur Instanz im privaten Subnetz – dann erhalte ich den Fehlerssh [email protected]

Ich kann meine private Instanz von meinem NAT aus mit anpingen ping 10.0.X.X. Ich bin mir also ziemlich sicher, dass es kein Problem mit Sicherheitsgruppen ist. Es sieht so aus, als wäre es ein Problem mit der Agentenweiterleitung.

Derzeit verwendet die Instanz, mit der ich mich verbinde, dasselbe Schlüsselpaar wie die NAT-Instanz (im Lernmodus).

Die andere Möglichkeit, die ich versucht habe, besteht darin, mit folgendem Verfahren eine Verbindung zum NAT herzustellen:

ssh -A [email protected] -i key_pair.pem

Dadurch wird wiederum eine korrekte Verbindung zum NAT hergestellt, aber bei der Verbindung mit der privaten Instanz tritt derselbe Fehler auf.

Muss ich es ssh-agentunter Mac OS X verwenden?

Oder sollte die Angabe ForwardAgent yesvon in nicht /.ssh/configdasselbe bewirken?

Antwort1

GemäßDasAntwort unddiese Leitlinie

Ich musste es key_pair.pemdem OSX-SSH-Agenten wie folgt hinzufügen:

ssh-add -K /path/to/key_pair.pem

(in meinem Fall wurde nicht nach einer Passphrase gefragt)

Danach funktionierte mit beiden oben beschriebenen Methoden alles einwandfrei.

Um die Frage zu beantworten:

Q: Muss ich unter Mac OS X einen SSH-Agenten verwenden, um mich über einen NAT-/Bastion-Host bei einer privaten Subnetzinstanz anzumelden?
A: JA

Antwort2

Bei mir hat es geholfen, den öffentlichen Schlüssel der Bastion (NAT-Instanz) aus zu entfernen ~/.ssh/known_hosts. Wenn sich der Schlüssel des Remote-Bastion-Hosts geändert hat (was recht häufig vorkommen kann, wenn Sie EIPs neuen Instanzen zuweisen) und Sie zusätzlich StrictHostKeyChecking noin Ihrer ssh_config festgelegt haben, wird AgentForwarding auf dem Bastion-Host deaktiviert. Sie werden auch eine entsprechende Warnung erhalten, wenn Sie sich beim Bastion-Host anmelden. Ich für meinen Teil habe sie einfach nicht gelesen -.-

Löschen Sie also den Schlüssel und stellen Sie die Verbindung erneut her. Der aktuelle Schlüssel wird zur Datei „known_hosts“ hinzugefügt und Sie können eine Verbindung mit der Instanz im privaten Subnetz herstellen.

verwandte Informationen