Chcę wiedzieć, kiedy należy go używać? Podążałem za tutorialem this i mówi, że nie wolno używać opcji Brak.Co to jest opcja "Brak" dla, dla kluczy podczas uruchamiania instancji w EC2?
Ponieważ mam tę opcję, musi być jakiś użytek, prawda? Chcę wiedzieć, w jakim scenariuszu go użyję?
Po określeniu nazwy pary podczas uruchamiania instancji AMI, Amazon EC2 udostępnia publiczny klucz ssh dla instancji, dzięki czemu może np. Dodać klucz do $ HOME/.ssh/authorized_keys dla domyślnego użytkownika . Domyślny użytkownik zależy od AMI i może być "ec2-user" lub "ubuntu" lub nawet "root".
Jednak nie jest wymagane, aby AMI używały klucza ssh, jest to jedynie wygodna konwencja i jeden z nielicznych sposobów zapewnienia osobie obsługującej AMI bezpiecznego dostępu do instancji.
Jeśli nie podasz nazwy keypair ssh (tj. Określisz "Brak"), musisz znaleźć inny sposób na udostępnienie tej instancji. W przypadku Amazon Linux i Ubuntu AMI można użyć systemu CloudInit i przekazać skrypt danych użytkownika, który ustawia dostęp przez ssh lub instaluje oprogramowanie, które ma być uruchomione na instancji, nawet jeśli użytkownik nie chce dostępu do ssh.
Nawet jeśli użytkownik nie oczekuje dostępu ssh do instancji, często jest przydatny do śledzenia problemów, gdy system lub uruchomione na nim oprogramowanie powoduje problemy.
"Brak" jest prawidłową opcją, która może być nieco praktyczna w użyciu w kilku sytuacjach, ale generalnie zaleca się podanie wartości, jeśli tylko w nagłych wypadkach.
Używamy opcji none w przypadkach, gdy nasz AMI jest na tyle solidny, że nie chcemy udostępniać maszyny w inny sposób niż poprzez oprogramowanie, które jest na niej zainstalowane. Jako przykład używamy oprogramowania Service Bus, które działa z kolejkami, ten konkretny AMI uruchomi się i zacznie nasłuchiwać kolejek do przetwarzania komunikatów, nie robi absolutnie nic więcej. W tej sytuacji, ponieważ nie ma danych hostowanych na samym komputerze (nawet danych kolejek), nie mamy potrzeby dostępu do niego.
Ale jeśli kiedykolwiek zejdziesz z tej trasy, przygotuj się na eksperta w regularnej wymianie maszyn "wyrzucaj" tylko po to, by wzmocnić AMI. Powiedziałbym, że w przypadku sytuacji typu czarna skrzynka żadna nie może być pomocna.
Mam nadzieję, że to pomoże,
To jest straszna rada. Nigdy nie powinieneś mieć maszyny, do której nie możesz się zalogować. – bwight
Nigdy nie jest mocnym słowem, z którym się nie zgadzam. Są chwile (zachowaj otwarty umysł), gdy byłoby to całkowicie uzasadnione. –
W środowisku EC2 dobrze jest mieć serwer bez logowania, o ile wiesz, co robisz. Serwery wyszukujące, które same konfigurują się i uruchamiają, jest bardzo możliwe na EC2 i nie jest to coś, co prawdopodobnie zrozumieją sysadmini w starym stylu. Nie zezwalając ssh na zamknięcie potencjalnego ryzyka bezpieczeństwa w przypadku, gdy prywatny klucz ssh nie jest tak prywatny (np. Pracownicy opuszczają firmę). W szczyptę zawsze możesz uzyskać wolumeny EBS, przenosząc je na serwer, na którym możesz się zalogować. Nie używanie klucza ssh ogranicza ekspozycję tylko do osób, które mają poświadczenia AWS. –
Po prostu, aby dodać do tego, jeśli AMI jest zbudowany samodzielnie, możesz dodać własne klucze i hasło. Ponieważ są one wbudowane w maszynę, nie potrzebujesz już kluczy amazonek. – bwight