Изпечатай

[d0ni]

Не мога да го reproduce-на, но ми изглежда, че PAM бърка sshd => su. Но не мога да си обясня защо паролата в случая няма значение?

[d0ni]

root@XXX /etc/pam.d> cat su

# This allows root to su without passwords (normal operation)
auth       sufficient pam_rootok.so

Ясна е работата

[gat3way]

Доста топло

Сега остава да се разбере защо като преименуваш sshd на su, pam решава че е su, а не sshd. Защото примерно
същата работа можеш да я сътвориш линквайки login или passwd като su, но в този случай няма да мине всяка парола (алтернативно с passwd като те пита за старата парола, няма да мине всяка парола).

Тук за съжаление мисля вече са тези 10% дето са по-свързани с C.

Между другото каква е дистрибуцията и дали sshd-то не е конфигурирано да автентицира само на база ключове? В последният случай няма как да се reproduce-не, но е възможно и да са си поиграли малко при билдването на openssh

[Naka]

При мен хака не работи.: Centos 5

[gat3way]

Това е доста странно...сигурен съм че тествах на VM с centos, беше 6.нещо и работеше. Сега ще трябва да дърпам ISO-та с по-стара версия и да разбера откъде идва тая работа.

[Naka]

Ако нещо логовете ти говорят:
~/su -oPort=12345 -oLogLevel=DEBUG


Jan 18 23:46:10 localhost su[4028]: debug1: Bind to port 12345 on ::.
Jan 18 23:46:10 localhost su[4028]: Server listening on :: port 12345.
Jan 18 23:46:10 localhost su[4028]: debug1: Bind to port 12345 on 0.0.0.0.
Jan 18 23:46:10 localhost su[4028]: error: Bind to port 12345 on 0.0.0.0 failed: Address already in use.
Jan 18 23:46:10 localhost su[4028]: Generating 768 bit RSA key.
Jan 18 23:46:10 localhost su[4028]: RSA key generation complete.

Jan 18 23:47:28 localhost su[4031]: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7
Jan 18 23:47:28 localhost su[4028]: debug1: Forked child 4031.
Jan 18 23:47:28 localhost su[4031]: debug1: inetd sockets after dupping: 3, 3
Jan 18 23:47:28 localhost su[4031]: Connection from 127.0.0.1 port 44582
Jan 18 23:47:28 localhost su[4031]: debug1: Client protocol version 2.0; client software version OpenSSH_4.3
Jan 18 23:47:28 localhost su[4031]: debug1: match: OpenSSH_4.3 pat OpenSSH*
Jan 18 23:47:28 localhost su[4031]: debug1: Enabling compatibility mode for protocol 2.0
Jan 18 23:47:28 localhost su[4031]: debug1: Local version string SSH-1.99-OpenSSH_4.3
Jan 18 23:47:28 localhost su[4032]: debug1: permanently_set_uid: 74/74
Jan 18 23:47:28 localhost su[4032]: debug1: list_hostkey_types: ssh-rsa,ssh-dss
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_KEXINIT sent
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_KEXINIT received
Jan 18 23:47:28 localhost su[4032]: debug1: kex: client->server aes128-cbc hmac-md5 none
Jan 18 23:47:28 localhost su[4032]: debug1: kex: server->client aes128-cbc hmac-md5 none
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
Jan 18 23:47:28 localhost su[4032]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_NEWKEYS sent
Jan 18 23:47:28 localhost su[4032]: debug1: expecting SSH2_MSG_NEWKEYS
Jan 18 23:47:28 localhost su[4032]: debug1: SSH2_MSG_NEWKEYS received
Jan 18 23:47:28 localhost su[4032]: debug1: KEX done
Jan 18 23:47:28 localhost su[4032]: debug1: userauth-request for user root service ssh-connection method none
Jan 18 23:47:28 localhost su[4032]: debug1: attempt 0 failures 0
Jan 18 23:47:28 localhost su[4032]: debug1: userauth-request for user root service ssh-connection method keyboard-interactive
Jan 18 23:47:28 localhost su[4032]: debug1: attempt 1 failures 1
Jan 18 23:47:28 localhost su[4032]: debug1: keyboard-interactive devs
Jan 18 23:47:28 localhost su[4032]: debug1: auth2_challenge: user=root devs=
Jan 18 23:47:28 localhost su[4032]: debug1: kbdint_alloc: devices ''
Jan 18 23:47:38 localhost su[4032]: debug1: userauth-request for user root service ssh-connection method password
Jan 18 23:47:38 localhost su[4032]: debug1: attempt 2 failures 2
Jan 18 23:47:38 localhost su[4031]: Failed password for root from 127.0.0.1 port 44582 ssh2
Jan 18 23:47:42 localhost su[4032]: debug1: userauth-request for user root service ssh-connection method password
Jan 18 23:47:42 localhost su[4032]: debug1: attempt 3 failures 3
Jan 18 23:47:42 localhost su[4031]: Failed password for root from 127.0.0.1 port 44582 ssh2
Jan 18 23:47:44 localhost su[4032]: debug1: userauth-request for user root service ssh-connection method password
Jan 18 23:47:44 localhost su[4032]: debug1: attempt 4 failures 4
Jan 18 23:47:44 localhost su[4031]: Failed password for root from 127.0.0.1 port 44582 ssh2
Jan 18 23:47:44 localhost su[4032]: Connection closed by 127.0.0.1
Jan 18 23:47:44 localhost su[4032]: debug1: do_cleanup
Jan 18 23:47:44 localhost su[4031]: debug1: do_cleanup

[Naka]

Сега като се замисля тази мойта система Centos 5 е ъпгрейт на много стар линукс. Бях затъркал всичко /usr /bin /sbin ... и т.н. но си запазих /etc и хоме

Та мисълта ми е да не би все още да ми използва някоя стара конфигурация от /etc/..... 

[gat3way]

Мне става много ясно за жалост. Вероятно са билднали openssh както трябва (ltrace може да даде повече информация, ама това всичкото да се изсипе тук няма да е много добра идея).

Сега съм в малко странно положение - интересно ми е защо не се получава, но ако помоля за това, което би ми помогнало да разбера причината, ще издам защо се получава

Може да направим така, след няколко (примерно 3 или пък 5) поста или пък просто докато решим, ако не е разгадано всичко, обяснявам как и защо работи това в детайли. Аз като гледам вече сме много близо така или иначе

А изследването защо не сработва ще е поне толкова интересно и на мен специално

[d0ni]

Доколкото виждам openssh вика pam_start по следния начин:

pam_start(SSHD_PAM_SERVICE, user, &store_conv, &sshpam_handle);

SSHD_PAM_SERVICE е:

# define SSHD_PAM_SERVICE      __progname

__progname = ssh_get_progname(argv[0]);

което пък връща или argv[0], така че явно pam е невинен странно решение на авторите на openssh

Иначе на Debian го тествах и проработи, просто първия път не го бях пуснал с root заради параноя

[d0ni]

Под OSX пак тръгва да ползва pam/su, но гърми с:

Jan 19 01:57:55 XXX su: root [pam][27913]: in pam_sm_acct_mgmt(): Unable to obtain the remote username.

[Naka]

Ако си бил root юзер:
----------------------------

и напишеш:

Код:

su obiknoven_user

или даже да се пробваш отново като root

Код:

su root

Няма да ти иска никаква парола - и така е правилно. Нали и без това като root юзер вече си имал всички права върху обикновенните юзери.

[gat3way]

Доколкото виждам openssh вика pam_start по следния начин:

pam_start(SSHD_PAM_SERVICE, user, &store_conv, &sshpam_handle);

SSHD_PAM_SERVICE е:

# define SSHD_PAM_SERVICE      __progname

__progname = ssh_get_progname(argv[0]);

което пък връща или argv[0], така че явно pam е невинен странно решение на авторите на openssh

Иначе на Debian го тествах и проработи, просто първия път не го бях пуснал с root заради параноя

Загадката е разгадана

Ако билднеш sshd с -DSSHD_PAM_SERVICE=sshd, нещата ще се оправят.

Защо sshd избира argv[0] като servicename за pam е не много смисленото. Не е осъдително де, но не виждам огромен смисъл. Предполагам са искали да оставят възможност да преименуваш sshd демона, въпреки че на кой му трябва това не знам. За друга причина не мога да се сетя. Забавното става като го преименуваш на su и sshd отвори pam сесия със servicename "su". Това задейства su конфигурацията на pam откъдето вече минава всяка парола. За да се "задейства" pam_rootok.so обаче, трябва uid на процеса да е 0. Обаче sshd се стартира като root и "сдава" правата (със setuid()) по-късно, поради което първия ред в /etc/pam.d/su сработва и автентицира само защото преименувания sshd работи като root.

[gat3way]

или даже да се пробваш отново като root
Код:

su root

Няма да ти иска никаква парола

Не мисля че това е много правилно поведение и не би трябвало да се случва. Дали няма някакъв механизъм за кеширане на пароли, както в sudo и оттам да идва...макар че ме съмнява. Изглежда странно.

[appmaster]

Това е доказателство, че не може да имаш доверие на стрингове (в настоящата им имплементация) при организация на правата.
За съжаление при подобно положение, добавянето на нов layer от абстракция ще причини повече проблеми отколкото положителен ефект.
Според мен трябва да се промени самия код на sshd демона (дали чрез rebuild или patch), защото ако трябва да се пипа логиката в линукс, ще стане доста грозно. sshd е entry point-a на проблема, и трябва да се обърне внимание на него.

От гледна точка на сигурност няма проблем наистина. Защо - защото ние вече сме root и това предполага, че защитата вече е преодоляна без значение правомерно или не. Така че проблема е комплексен и се решава с допълнителна сложност, която не оправдава целта

[d0ni]

Това е доказателство, че не може да имаш доверие на стрингове (в настоящата им имплементация) при организация на правата.
За съжаление при подобно положение, добавянето на нов layer от абстракция ще причини повече проблеми отколкото положителен ефект.
Според мен трябва да се промени самия код на sshd демона (дали чрез rebuild или patch), защото ако трябва да се пипа логиката в линукс, ще стане доста грозно. sshd е entry point-a на проблема, и трябва да се обърне внимание на него.

От гледна точка на сигурност няма проблем наистина. Защо - защото ние вече сме root и това предполага, че защитата вече е преодоляна без значение правомерно или не. Така че проблема е комплексен и се решава с допълнителна сложност, която не оправдава целта

Това мнение силно ми напомня на http://weknowmemes.com/generator/uploads/generated/g1390401315884110280.jpg :-)