Jak sprawić, by klucze wspólne .ssh / Author_keys i sudo działały razem?

Skonfigurowałem .ssh / autoryzowane_klucze i jestem w stanie zalogować się przy użyciu nowego „użytkownika” przy użyciu klucza pub / private ... Dodałem również „użytkownika” do listy sudoers ... Problem, który mam teraz, to kiedy Próbuję wykonać polecenie sudo, coś takiego jak:

$ sudo cd /root

wyświetli monit o podanie hasła, które wpisuję, ale nie działa (używam ustawionego hasła klucza prywatnego)

Ponadto wyłączyłem hasło użytkownika za pomocą

$ passwd -l user

czego mi brakuje?

Gdzieś moje początkowe uwagi są źle rozumiane ...

Próbuję zahartować mój system ... ostatecznym celem jest użycie kluczy pub / private do logowania, a nie proste uwierzytelnianie hasłem. Nauczyłem się, jak to wszystko skonfigurować za pomocą pliku autoryzowanych_kluczy.

Ponadto ostatecznie zapobiegnę logowaniu się do serwera za pośrednictwem konta root. Ale zanim to zrobię, potrzebuję sudo do pracy dla drugiego użytkownika (użytkownika, z którym będę cały czas logował się do systemu).

W przypadku tego drugiego użytkownika chcę zapobiec regularnemu logowaniu się za pomocą hasła i wymuszać tylko logowanie do klucza publicznego / publicznego, jeśli nie zablokuję użytkownika za pomocą „passwd -l user ... to jeśli nie użyję klucza, nadal mogę dostać się na serwer za pomocą zwykłego hasła.

Ale co ważniejsze , muszę sprawić, aby sudo współpracowało z konfiguracją klucza publicznego / publicznego z użytkownikiem, którego hasło zostało wyłączone.

Edycja: OK, myślę, że mam (rozwiązanie):

1) Dostosowałem / etc / ssh / sshd_config i ustawiłem. PasswordAuthentication no Zapobiegnie to logowaniu się za pomocą hasła ssh (pamiętaj, aby mieć działającą konfigurację klucza publicznego / prywatnego przed zrobieniem tego)

2) Poprawiłem listę sudoers visudoi dodałem

root      ALL=(ALL) ALL
dimas     ALL=(ALL) NOPASSWD: ALL

3) root to jedyne konto użytkownika, które będzie miało hasło, testuję z dwoma kontami użytkownika „dimas” i „sherry”, które nie mają ustawionego hasła (hasła są puste, passwd -d user)

Powyższe zasadniczo uniemożliwia wszystkim logowanie się do systemu za pomocą haseł (klucz publiczny / prywatny musi zostać skonfigurowany).

Dodatkowo użytkownicy na liście sudoers mają uprawnienia administratora. Mogą również korzystać suz różnych kont. Więc w zasadzie „Dimas” może sudo su sherryjednak „Dimas może NIE su sherry. Podobnie żadnego użytkownika nie ma na liście sudoers nie można zrobić su userlub sudo su user.

UWAGA Powyższe działa, ale jest uważane za słabe bezpieczeństwo. Każdy skrypt, który może uzyskać dostęp do kodu jako użytkownik „dimas” lub „sherry”, będzie mógł wykonać sudo, aby uzyskać dostęp do roota. Błąd w ssh, który pozwala zdalnym użytkownikom zalogować się pomimo ustawień, zdalne wykonanie kodu w coś takiego jak Firefox lub inna wada, która pozwala na uruchomienie niechcianego kodu, ponieważ użytkownik będzie mógł teraz działać jako root. Sudo powinno zawsze wymagać hasła, możesz równie dobrze zalogować się jako root zamiast jakiegoś innego użytkownika.

sshi sudonie mają ze sobą nic wspólnego. Ustawienie sshmetody uwierzytelniania nic nie da sudo. sudonie zrozumie sshhasła.

passwd -lma na celu zablokowanie konta użytkownika, aby nie mógł już uwierzytelniać się za pomocą hasła. To prawie przeciwieństwo tego, co chcesz, a mianowicie zezwalanie użytkownikowi na uwierzytelnianie bez hasła.

Myślę, że to, czego chcesz, to NOPASSWDopcja w twoim sudoerspliku .

(PS, nie ma powodu, aby uruchamiać cdpolecenie z sudo. cdNie propaguje się do procesów nadrzędnych, więc jak tylko sudowyjdzie, wrócisz tam, gdzie zacząłeś.)

Edycja: Ciągle mówisz, że chcesz zablokować hasło do konta i chcesz, aby sudo rozumiało klucze publiczne / prywatne. Przepraszamy, sudo nie będzie używać kluczy ssh. To nie jest ssh. Jeśli nie chcesz, aby użytkownicy mogli logować się przy użyciu haseł, myślę, że odpowiedzią jest wyłączenie uwierzytelniania hasła ssh , a nie blokowanie konta. Następnie możesz zachować hasło dla użytkowników, których mogą używać do sudo po zalogowaniu za pomocą ssh uprawnione_klucze.

To, co chcesz zrobić, jest możliwe, ale będzie wymagało trochę doświadczenia, ponieważ będziesz musiał skompilować moduł PAM o nazwie pam-ssh-agent-auth .

Proces jest dość prosty:

$ sudo aptitude install libssl-dev libpam0g-dev build-essential checkinstall
$ wget "http://downloads.sourceforge.net/project/pamsshagentauth/pam_ssh_agent_auth/v0.9.3/pam_ssh_agent_auth-0.9.3.tar.bz2"
$ tar -xjvf pam_ssh_agent_auth-0.9.3.tar.bz2
$ cd pam_ssh_agent_auth-0.9.3

$ ./configure --libexecdir=/lib/security --with-mantype=man

$ make
$ sudo checkinstall

Edytuj konfigurację sudo:

$ sudo visudo

Dodaj następujące:

Defaults env_keep += SSH_AUTH_SOCK

Kontynuuj, zmieniając ustawienia sudo PAM:

$ sudo vi /etc/pam.d/sudo

Dodaj (tuż powyżej linii @include):

**auth [success=2 default=ignore] pam_ssh_agent_auth.so file=~/.ssh/authorized_keys**
@include common-auth
@include common-account

Odpowiedź Andre de Mirandy zapewnia dobre rozwiązanie przy użyciu pam_ssh_agent_auth , ale części są nieaktualne. W szczególności /etc/pam.d/sudoinstrukcje dotyczące korzystania z wielu aktualnych wersji systemu Linux.

Jeśli używasz systemu Ubuntu 12.04 precyzyjnie, w rzeczywistości uprościłem ten proces, udostępniając kompilację pam_ssh_agent_auth z ppa: ppa: cpick / pam-ssh-agent-auth .

Możesz zainstalować pakiet, uruchamiając:

sudo add-apt-repository ppa:cpick/pam-ssh-agent-auth
sudo apt-get install pam-ssh-agent-auth

Po instalacji, jeśli chcesz używać tego modułu PAM z sudo, musisz skonfigurować ustawienia sudo i konfigurację PAM, w Ubuntu 12.04 precyzyjnie możesz to zrobić, tworząc następujące dwa pliki:

/etc/sudoers.d/pam-ssh-agent-auth:

Defaults    env_keep+="SSH_AUTH_SOCK"

/etc/pam.d/sudo:

ent#%PAM-1.0

auth       required   pam_env.so readenv=1 user_readenv=0
auth       required   pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
auth       sufficient pam_ssh_agent_auth.so file=/etc/security/authorized_keys
@include common-auth
@include common-account
@include common-session-noninteractive

Jeśli używasz szefa kuchni, powyższy proces można zautomatyzować za pomocą mojej książki kucharskiej, którą można znaleźć w jednej z dwóch następujących lokalizacji:
https://github.com/cpick/pam-ssh-agent-auth
http: //community.opscode .com / książki kucharskie / pam-ssh-agent-auth .

Katalog książki kucharskiej fileszawiera opisane powyżej pliki /etc/pam.d/sudoi /etc/sudoers.d/pam-ssh-agent-auth, które działają dokładnie z Ubuntu 12.04 i powinny być pomocnym punktem wyjścia przy korzystaniu z innych wersji / dystrybucji.

Jedynym sposobem, w jaki wiem, jak ominąć wprowadzanie hasła, jest wyłączenie go w twoim sudoers pliku.

Coś takiego da rootwszystkim członkom wheel pełny dostęp bez hasła:

root    ALL=(ALL)   NOPASSWD: ALL
%wheel  ALL=(ALL)   NOPASSWD: ALL

Nie jest to jednak absolutnie zalecane . Jeśli masz określone polecenie do wykonania dla tego serwera, daj im dostęp tylko do tego polecenia. Lub jeszcze lepiej, znajdź inny sposób na osiągnięcie tego, co chcesz zrobić, co nie wymaga wybicia dziury w zabezpieczeniach.