☰

EC2 Automatische Instanz Sudo funktioniert nicht

tag-icon • tag-icon linux centos amazon-ec2 amazon-web-services sudo
EC2 Automatische Instanz Sudo funktioniert nicht

Ich verwende Atlassian Bamboo, um einen Build-Server einzurichten. Es ermöglicht die Verwendung von „elastischen Images“, bei denen ich angeben kann, welche ihrer AMIs verwendet werden sollen (ich verwende das Amazon Linux/CentOS-Image). Außerdem können Sie Skripte hinzufügen, um den Server im Wesentlichen „bereitzustellen“. Wenn ich den Build mithilfe sudomeiner Skripte ausführe, erhalte ich Fehler wie diese:

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

sudo: no tty present and no askpass program specified
sudo: no tty present and no askpass program specified
sudo: no tty present and no askpass program specified
sudo: no tty present and no askpass program specified

Wenn ich es nicht verwende sudo, erhalte ich die Fehlermeldung „Zugriff verweigert“.

DerSkriptIch versuche, es so einfach auszuführen wie:

sudo yum install -y php-mysql
sudo yum install -y php-pdo
sudo yum install -y php-pecl-xdebug
sudo yum update

Bamboo wird mit einem Schlüssel eingerichtet und sollte daher kein tatsächliches Passwort erfordern (es gibt keines, soweit ich weiß), was bedeutet, dass das Fehlen einer TTY-Eingabe keine Rolle spielen sollte, oder?

Wenn der Server ständig hochgefahren wäre, könnte ich mich per SSH darauf anmelden und herausfinden, wie ich die Sudo-Berechtigungen aktiviere, aber das ist nicht der Fall... Er wird erstellt, der Build wird ausgeführt und dann wird er beendet.

Kurz zusammengefasst:Was kann dazu führen, dass ein dynamisch hochgefahrenes, EBS-gestütztes AMI dies nicht zulässt sudo?

Antwort1

Bamboo wird mit einem Schlüssel eingerichtet und sollte daher kein echtes Passwort erfordern (soweit ich weiß, gibt es keins). Das Fehlen einer TTY-Eingabe sollte also keine Rolle spielen, oder?

Nein. Hier sind Sie verwirrt. Wie Sie sich bei SSH authentifiziert haben, hat nichts mit Sudo zu tun. Wenn Sudo so konfiguriert ist, dass ein Passwort erforderlich ist, müssen Sie das Passwort des Benutzers eingeben. Wenn Sie das nicht tun, funktioniert es nicht. Wenn der Benutzer kein Passwort hat, kann es unmöglich funktionieren.

Es scheint, dass Sie sudo so neu konfigurieren sollten, dass

  • es erfordert kein TTY
  • Es ist kein Passwort erforderlich

Wenn ich zum Beispiel einen Benutzer namensBambusum als beliebiger Benutzer ohne Passwort jeden Befehl ausführen zu können, in meinem/etc/sudoersDatei, die ich hätte haben können

bamboo  ALL=(ALL)   NOPASSWD: ALL

Antwort2

Wie in der Dokumentation beschrieben, wenn die von Atlassian bereitgestellten Bilder nicht das tun, was Sie wollen, dann sollten SieErstellen Sie ein benutzerdefiniertes Bild.

Antwort3

Überprüfen Sie, ob die Datei /etc/sudoers richtig konfiguriert ist. Ich hatte gestern diese Fehlermeldung, als eines unserer Build-Skripte die Änderungen überschrieb, die ich in der Datei /etc/sudoers vorgenommen hatte, was zu dem Berechtigungsproblem führte.

verwandte Informationen