[Comm] Перенос юзера на другую систему

[Comm] Перенос юзера на другую систему

[Dmitry E. Oboukhov]

тут возникла задачка переместить одного юзера вместе с его паролем
на другой сервер.

сервер стоит на Дебиане, исппользуется МД5.
исходный юзер находится на сервере АЛМ2

можно ли как-то это проделать?

если переместить запись из
/etc/tcb/username/shadow в /etc/shadow будет работать ?

Re: [Comm] Перенос юзера на другую систему

[Sergey Vlasov]

On Sun, Oct 13, 2002 at 22:34:23 +0400, Dmitry E. Oboukhov wrote:
> тут возникла задачка переместить одного юзера вместе с его паролем
> на другой сервер.
> 
> сервер стоит на Дебиане, исппользуется МД5.
> исходный юзер находится на сервере АЛМ2
> 
> можно ли как-то это проделать?
> 
> если переместить запись из
> /etc/tcb/username/shadow в /etc/shadow будет работать ?

Скорее всего, нет, т.к. в дистрибутивах ALT уже давно используется
алгоритм Blowfish, а не MD5 (можете проверить - hash в shadow начинается с
$2a$, а не с $1$, как для MD5). Разве что в Debian тоже внесли поддержку
Blowfish - не видел, не знаю.

Re: [Comm] Перенос юзера на другую систему

[Dmitry E. Oboukhov]

Sergey Vlasov wrote:

>On Sun, Oct 13, 2002 at 22:34:23 +0400, Dmitry E. Oboukhov wrote:
>  
>
>>тут возникла задачка переместить одного юзера вместе с его паролем
>>на другой сервер.
>>
>>сервер стоит на Дебиане, исппользуется МД5.
>>исходный юзер находится на сервере АЛМ2
>>
>>можно ли как-то это проделать?
>>
>>если переместить запись из
>>/etc/tcb/username/shadow в /etc/shadow будет работать ?
>>    
>>
>
>Скорее всего, нет, т.к. в дистрибутивах ALT уже давно используется
>алгоритм Blowfish, а не MD5 (можете проверить - hash в shadow начинается с
>$2a$, а не с $1$, как для MD5). Разве что в Debian тоже внесли поддержку
>Blowfish - не видел, не знаю.
>  
>
тут у меня проблема: надо переместить шефа, но чтобы он об этом не знал :)
ладно, у них разные системы шифрования,
тогда можно ли расшифровать ключ взятый из

/etc/tcb/username/shadow

пусть это займет хоть месяц, но по полит-соображениям юзер не должен
знать что его "перепрописали" на другой сервер.
есть ли средства (и какие) для расшифровки (пусть путем подбора)
такого ключа ?

Re: [Comm] Перенос юзера на другую систему

[Alexander Bokovoy]

On Mon, Oct 14, 2002 at 07:02:36PM +0400, Dmitry E. Oboukhov wrote:
> >>сервер стоит на Дебиане, исппользуется МД5.
> >>исходный юзер находится на сервере АЛМ2
> >>
> >>можно ли как-то это проделать?
> >>
> >>если переместить запись из
> >>/etc/tcb/username/shadow в /etc/shadow будет работать ?
> >Скорее всего, нет, т.к. в дистрибутивах ALT уже давно используется
> >алгоритм Blowfish, а не MD5 (можете проверить - hash в shadow начинается с
> >$2a$, а не с $1$, как для MD5). Разве что в Debian тоже внесли поддержку
> >Blowfish - не видел, не знаю.
> > 
> >
> тут у меня проблема: надо переместить шефа, но чтобы он об этом не знал :)
> ладно, у них разные системы шифрования,
> тогда можно ли расшифровать ключ взятый из
> 
> /etc/tcb/username/shadow
> 
> пусть это займет хоть месяц, но по полит-соображениям юзер не должен
> знать что его "перепрописали" на другой сервер.
> есть ли средства (и какие) для расшифровки (пусть путем подбора)
> такого ключа ?
Если на стороне Debian есть поддержка Blowfish, то просто запись
перенесите. Если поддержки нет, то можно собрать glibc для этой машины с
использованием патча поддержки Blowfish из нашего src.rpm.
-- 
/ Alexander Bokovoy
---
revolutionary, adj.:
	Repackaged.

Re[2]: [Comm] ðÅÒÅÎÏÓ ÀÚÅÒÁ ÎÁ ÄÒÕÇÕÀ ÓÉÓÔÅÍÕ

[ASA]

Hello Dmitry,

Monday, October 14, 2002, 8:02:36 PM, you wrote:

DEO> тут у меня проблема: надо переместить шефа, но чтобы он об этом не знал :)

DEO> пусть это займет хоть месяц, но по полит-соображениям юзер не должен
DEO> знать что его "перепрописали" на другой сервер.
DEO> есть ли средства (и какие) для расшифровки (пусть путем подбора)
DEO> такого ключа ?
Ты  же  _хозяин_  и того, и другого сервера? Обращаемся к теории
защиты  информации,  вычленяем  системы,  и  определяем уязвимые
компоненты,  легко  подверженные атаке. Например, идет ли пароль
по  сети  в  открытом  виде к какому-либо сервису, скажем, POP3?
Отсниффать  чем-нибудь,  tcpdump  и  тот справится. Или вставить
"бомбу"  в ту программу, в которой шеф использует свой пароль. В
общем,  варианты  в  таком  дуже  -  возможны.  Если,  например,
логинится  с  консоли  машины  (что, впрочем, к твоей ситуции не
подходит),  то  можно  и  login  подправить,  а  можно  и в ядро
вставить  вывод  в  лог  всех событий нажатий клавиш. Но эти все
способы   со   вставкой   -   требуют   хоть   какого-то  знания
программирования.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] Перенос юзера на другую систему

[Dmitry E. Oboukhov]

ASA wrote:

>Hello Dmitry,
>
>Monday, October 14, 2002, 8:02:36 PM, you wrote:
>
>DEO> тут у меня проблема: надо переместить шефа, но чтобы он об этом не знал :)
>
>DEO> пусть это займет хоть месяц, но по полит-соображениям юзер не должен
>DEO> знать что его "перепрописали" на другой сервер.
>DEO> есть ли средства (и какие) для расшифровки (пусть путем подбора)
>DEO> такого ключа ?
>Ты  же  _хозяин_  и того, и другого сервера?
>
да

> Обращаемся к теории
>защиты  информации,  вычленяем  системы,  и  определяем уязвимые
>компоненты,  легко  подверженные атаке. Например, идет ли пароль
>по  сети  в  открытом  виде к какому-либо сервису, скажем, POP3?
>Отсниффать  чем-нибудь,  tcpdump  и  тот справится. Или вставить
>"бомбу"  в ту программу, в которой шеф использует свой пароль. В
>общем,  варианты  в  таком  дуже  -  возможны.  Если,  например,
>логинится  с  консоли  машины  (что, впрочем, к твоей ситуции не
>подходит),  то  можно  и  login  подправить,  а  можно  и в ядро
>вставить  вывод  в  лог  всех событий нажатий клавиш. Но эти все
>способы   со   вставкой   -   требуют   хоть   какого-то  знания
>программирования.
>  
>
спасибо,

мне именно это и порекомендовали, я так скорее всего и сделаю (посканим
РОР3), но просто стало интересно потестить уже _свои_ пароли на предмет
взламываемости, отсюда и вопрос: чем можно это сделать?

задача:
у меня есть ключ, полученный из /etc/tcb/...
я хочу восстановить по нему пароль, сколько времени
это займет?

чем решить такую задачу в линуксе? куда смотреть, какие маны, или просто
направление ?

Re: [Comm] Перенос юзера на другую систему

[Dmitry E. Oboukhov]

я правильно понимаю, что в АЛЬТ-линуксе заменена
стандартная функция libc - crypt ?
то есть если я напишу программу, которая будет её вызывать
с разными входными значениями до тех пор, пока не получит
два совпадающих ключа я решу свою задачу?

или здесь применяется другие функции ?
все что у меня на эту тему относительно юниксов есть
- публикации 5-ти летней давности...

сегодня вечером гляну..

Re: [Comm] Перенос юзера на другую систему

[Alexander Bokovoy]

On Mon, Oct 14, 2002 at 08:52:38PM +0400, Dmitry E. Oboukhov wrote:
> я правильно понимаю, что в АЛЬТ-линуксе заменена
> стандартная функция libc - crypt ?
Она не заменена. Она расширена.

> то есть если я напишу программу, которая будет её вызывать
> с разными входными значениями до тех пор, пока не получит
> два совпадающих ключа я решу свою задачу?
Можете и так, но даже для более слабого RC5-64bit у проекта
distributed.net это заняло более 2,5 лет "всем скопом".

-- 
/ Alexander Bokovoy
---
Dear Lord:
	I just want *___\b\b\bone* one-armed manager so I never have to hear "On
the other hand", again.

[Comm] [JT] þÅÍ ËÏÎÞÁÅÔÓÑ ÐÏÄÂÏÒ ÐÁÒÏÌÅÊ

[Henri Bourbon]

On 14 Oct 2002  21:18, Alexander Bokovoy wrote:

> On Mon, Oct 14, 2002 at 08:52:38PM +0400, Dmitry E. Oboukhov wrote:

>> то есть если я напишу программу, которая будет её вызывать
>> с разными входными значениями до тех пор, пока не получит
>> два совпадающих ключа я решу свою задачу?

> Можете и так, но даже для более слабого RC5-64bit у проекта
> distributed.net это заняло более 2,5 лет "всем скопом".

Точнее, "взлом" RC5-64 занял почти 5 лет (1757 дней). Интересно, есть ли
здесь  люди  из  RC5  Hackzone  team?  Думаю, есть. Но уж точно никто не
помнит, кто такой HB :-)

Осенью  1998-го  ваш  покорный  слуга,  сидевший за Pentium MMX 250 MHz,
загрузил  distributed.net  client  и  прикинул:  на  подбор  ключа  его
компьютер потратит... 1 миллион лет.

Что  касается конкретной поставленной задачи (подобрать пароль шефа), то
она  _несравнимо_  проще перебора всех 64-битных ключей, не говоря уже о
128-битных.  Просто  потому,  что шеф -- человек. Когда Дмитрий написал,
что  нужно  пароль  шефа  подобрать,  я  сразу  вспомнил душераздирающую
историю.  "Just   Another   Perl   Hacker"   (Рэндал  Шварц), работая на
Intel,   из   альтруистских   соображений (помочь корпорации понять, что
нельзя  недооценивать  проблемы  безопасности; воровать секретные данные
или разглашать пароли в его планы не входило)  пускал  на  паре серверов
программу  перебора  паролей  (как   раз   такую,   о   к-рой  спрашивал
Дмитрий).  Он подобрал немало паролей, самым крупным "уловом" был пароль
вице-президента Intel. Он был, AFAIR, такой:
$president
Благодарность  Intel  превзошла  все мыслимые ожидания Рэндала. Потратив
почти   $200   тыс.  на адвокатов, много месяцев времени и, можно только
догадываться,  сколько  нервов, он  сумел избежать тюремного заключения,
к-рое   заменили  "общественными  работами"  (или  как  там  оно  у  них
называется).  Кроме прочих последствий, теперь при поступлении на работу
он  обязан  уведомить  работодателя  о произошедшем инциденте. Последнюю
проблему  он решил, впрочем, довольно просто, открыв собственную фирму и
работая на себя :-)
Такие вот пироги.

Резюме  1.  Подбирая пароль шефа, особенно высокопоставленного в крупной
фирме,  имейте  про  запас  мешок  с  сухарями,  чесноком, мылом, чаем и
ногтекусачкой (ножницы в тюрьме запрещены).

Резюме  2.  Сложность задачи подбора пароля, к-рый придумал себе обычный
человек,  не  помешанный  на  безопасности  (в  отличие от многих в этой
рассылке),  не  имеет  ничего общего со сложностью перебора 2^64 и более
вариантов.

-- 
HB

[Comm] Re: [Comm] [JT] Чем кончается подбор паролей

[K. Neverovsky]

Hello Henri,

Monday, October 14, 2002, 11:03:45 PM, you wrote:

HB> On 14 Oct 2002  21:18, Alexander Bokovoy wrote:

>> Можете и так, но даже для более слабого RC5-64bit у проекта
>> distributed.net это заняло более 2,5 лет "всем скопом".

HB> Точнее, "взлом" RC5-64 занял почти 5 лет (1757 дней). Интересно, есть ли
HB> здесь  люди  из  RC5  Hackzone  team?  Думаю, есть. Но уж точно никто не
HB> помнит, кто такой HB :-)

А зачем этому проекту (distributed.net) понадобилось ломать RC-5?
Загрузил я их клиент, так он какой-то OGR пересчитывать стал =:( Что
такое этот самый OGR и зачем они его взломать хотят?

Простите за вопросы чайника. Просто интересно в плане general
knoledge.

Re: [Comm] Re: [Comm] [JT] Чем кончается подбор паролей

[Andy Gorev]

Henri Bourbon <useperl@fastmail.fm> wrote:
> Интересно, есть ли здесь  люди  из  RC5  Hackzone  team?
Есть-есть ;)

"K. Neverovsky" <kn@tut.by> wrote:
> А зачем этому проекту (distributed.net) понадобилось ломать RC-5?
Посмотрите на сайте http://rc5.bugtraq.ru/ или
http://www.atmsk.ru/viewtopic.php?t=341

> Загрузил я их клиент, так он какой-то OGR пересчитывать стал =:( Что
> такое этот самый OGR и зачем они его взломать хотят?
Проект rc5-64 закрыт, и поэтому клиент закачал блоки по другому проекту.

> Простите за вопросы чайника. Просто интересно в плане general
> knoledge.
Посмотрите по ссылкам.

-- 
С Уважением,
Андрей Горев

Re: [Comm] [JT] � �������� ���

[А.Л. Клютченя]

15 Октябрь 2002 00:03, Henri Bourbon написал:
> Резюме  1.  Подбирая пароль шефа, особенно высокопоставленного
> в крупной фирме,  имейте  про  запас  мешок  с  сухарями, 
> чесноком, мылом, чаем и ногтекусачкой (ножницы в тюрьме
> запрещены).
>
> Резюме  2.  Сложность задачи подбора пароля, к-рый придумал
> себе обычный человек,  не  помешанный  на  безопасности  (в 
> отличие от многих в этой рассылке),  не  имеет  ничего общего
> со сложностью перебора 2^64 и более вариантов.

	У нас шеф умнее :-) Он не работает в сети, как и всё руководство 
:-)

-- 
ВсехБлаг!       А. Л. Клютченя
 mail:	asoneofus@kde.ru
 www:	http://www.asoneofus.nm.ru
 icq:	113679387

Re: [Comm] [JT]

[Andrey Golovin]

On Tue, 15 Oct 2002 01:07:40 +0400
"А.Л. Клютченя" <asoneofus@nm.ru> wrote:

> 15 Октябрь 2002 00:03, Henri Bourbon написал:
> > Резюме  1.  Подбирая пароль шефа, особенно высокопоставленного
> > в крупной фирме,  имейте  про  запас  мешок  с  сухарями, 
> > чесноком, мылом, чаем и ногтекусачкой (ножницы в тюрьме
> > запрещены).
> >
> > Резюме  2.  Сложность задачи подбора пароля, к-рый придумал
> > себе обычный человек,  не  помешанный  на  безопасности  (в 
> > отличие от многих в этой рассылке),  не  имеет  ничего общего
> > со сложностью перебора 2^64 и более вариантов.
> 
> 	У нас шеф умнее :-) Он не работает в сети, как и всё руководство 
> :-)
У Вас шеф РАБОТАЕТ ???
Во даёт!

Re: [Comm] [JT]

[А.Л. Клютченя]

16 Октябрь 2002 00:27, Andrey Golovin написал:
> У Вас шеф РАБОТАЕТ ???
> Во даёт!

	Да, он работает, хотя как руководитель и вперёдсмотрящий: он 
никакой :-) (хотя, они оба у нас такие, но один подаёт надежды 
:-))

-- 
ВсехБлаг!       А. Л. Клютченя
 mail:	asoneofus@kde.ru
 www:	http://www.asoneofus.nm.ru
 icq:	113679387

[Comm] Re: [Comm] [JT] Чем кончается подбор паролей

[grimnir]

Hello Henri,

Tuesday, October 15, 2002, 12:03:45 AM, you wrote:

HB> On 14 Oct 2002  21:18, Alexander Bokovoy wrote:

>> On Mon, Oct 14, 2002 at 08:52:38PM +0400, Dmitry E. Oboukhov wrote:

>>> то есть если я напишу программу, которая будет её вызывать
>>> с разными входными значениями до тех пор, пока не получит
>>> два совпадающих ключа я решу свою задачу?

>> Можете и так, но даже для более слабого RC5-64bit у проекта
>> distributed.net это заняло более 2,5 лет "всем скопом".

HB> Точнее, "взлом" RC5-64 занял почти 5 лет (1757 дней). Интересно, есть ли
HB> здесь  люди  из  RC5  Hackzone  team?  Думаю, есть. Но уж точно никто не
HB> помнит, кто такой HB :-)

HB> Резюме  2.  Сложность задачи подбора пароля, к-рый придумал себе обычный
HB> человек,  не  помешанный  на  безопасности  (в  отличие от многих в этой
HB> рассылке),  не  имеет  ничего общего со сложностью перебора 2^64 и более
HB> вариантов.
ага у меня например пароль 20 символов, вообще очень приятно
применять ключевые фразы, легко запоминается и долго подбирается
например: "тридцатьтрибогатыря" в латинской раскладке:)
хотя тоже не 2^64:) а пароль обычных пользователей (не
помешанных  на секурити) неплохо подбираются  по словарю,
словарей в инете немеряно самый большой который я видел был 80
мегов в архиве, также их можно составлять самому, выдирая слова
из текстовых из файлов складывая в один файл после чего проверять
на повторяемость слов, но в нем не будет многих устоявшихся
жаргонных слов и кривых написаний типа @l7L1nux, MacTep и
подобных.



-- 
Best regards,
 grimnir                            mailto:grimnir@park-net.ru

Re[2]: [Comm] ðÅÒÅÎÏÓ ÀÚÅÒÁ ÎÁ ÄÒÕÇÕÀ ÓÉÓÔÅÍÕ

[ASA]

Hello Dmitry,

Monday, October 14, 2002, 9:48:19 PM, you wrote:

DEO> мне именно это и порекомендовали, я так скорее всего и сделаю (посканим
DEO> РОР3), но просто стало интересно потестить уже _свои_ пароли на предмет
DEO> взламываемости, отсюда и вопрос: чем можно это сделать?
Чем,  теорией защиты информации. Смотрим каждую подситему, через
которую  проходит  пароль,  и  анализируем,  возможно ли на этом
этапе  перехватить  пароль или прочесть следы после этого этапа.
Для  сети ответ простой: легко прочесть, если нет шифрования или
шифрование  слабое,  и практически невозможно, если используется
шифрование,   основанное  на  обмене  открытыми  ключами  (и  их
_сверке_,   что  должно  исключить  возможность  атаки  "man-in-
middle",  которой  подвержен ssh1). Для самих программ, если они
корректно написаны, проблем не возникнет.

Помню,  как в 93 году я читал дизассемблер программы LOGON из ОС
TSX-Plus  6 (работала на отечественном чуде СМ-1420) и обнаружил
потрясающий  факт  -  при  вводе имени пользователя LOGON тут же
кидалась  со  всех  ног к файлу, которому я бы в UNIX сопоставил
/etc/passwd/shadow,  брало  оттуда  пароль,  РАСШИФРОВЫВАЛО  ЕГО
(алгоритм  был  какой-то  левый,  и  главное, обратимый, f(f(x))
давало  x)  держало  результат  в  памяти, ждала ввода пароля об
юзера  и  сравнивала  его.  Нечего  говорить  о  том, что юзера,
имевшие доступ к файлу с паролями (т.е. все юзера) или доступ ко
всей  памяти  ОС  (зачем-то авторы сочли нужным иметь в арсенале
power-user'а  такую  привилегию),  т.е.  с  аналогом  доступа  к
/dev/kcore  могли  все  сделать.  На  следующий день была готова
программа,  выдававшая  пароли  любого  или всех юзеров. Мораль:
некоторым людям противопоказано писать операционные системы.

DEO> задача:
DEO> у меня есть ключ, полученный из /etc/tcb/...
DEO> я хочу восстановить по нему пароль, сколько времени
DEO> это займет?
Возводим  2  в  степень  разрядности  ключа и делим на время, за
которое  комп  расшифровывает (или зашифровывает) один ключ. Для
систем с открытыми ключами, базирующихся на возведении в степень
по  модулю,  не  все комбинации битов в ключе допустимы, поэтому
число  битов в разрядности ключа следует приблизительно поделить
на  три  (т.е.  768-битный  ssh-ключ  по  трудоемкости  примерно
соответствует  256-битному  ключу,  основанному  на перестановке
битов а-ля DES).

Далее,  не  только  длина  ключа  гарантирует  его  стойкость ко
взлому,  но  и  ненужность  зашифрованных  данных.  Если  данные
жизненно  важны  для государства, то, скорее всего, в результате
некоторых   неджентльменских  методов,  далеких  от  математики,
хозяин  данных  сам  преподнесет  ключ  на  блюдечке  с  голубой
каемочкой и будет искренне этому рад.

Следует  еще  упомянуть,  что  по следствию из известной теоремы
Геделя,  задача  атаки  на шифр не имеет универсального решения,
т.е.  нет  гарантии,  что  завтра  не  найдется новое остроумное
решение,    котрое    позволит    неожиданно   просто   прочесть
нераскрываемые  до этого шифры. Так, в самом деле, я слышал, что
летом этого (2002) года индийские матемактики нашли новый способ
определения  простоты  чисел.  Судя  по  тому,  что о нем еще не
говорили  в  коммунити,  к  краху  систем  шифрования с открытым
ключами  он  не  приводит,  но зарекаться от такой возможности в
будущем нельзя.

DEO> чем решить такую задачу в линуксе? куда смотреть, какие маны, или просто
DEO> направление ?
На  практике  в  _линухе_  (про  другие  ОС - см выше) я этим не
занимался. мне tcpdump'а хватило.

А направление... добро пожаловать в теорию защиты информации.
Публикаций - много.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

[Comm] [jt] Re: Перенос юзера на другую систему

[Maksim Otstavnov]

Monday, October 14, 2002, 8:06:04 PM, ASA wrote:

A> Hello Dmitry,

A> Monday, October 14, 2002, 8:02:36 PM, you wrote:

DEO>> тут у меня проблема: надо переместить шефа, но чтобы он об этом не знал :)

DEO>> пусть это займет хоть месяц, но по полит-соображениям юзер не должен
DEO>> знать что его "перепрописали" на другой сервер.
DEO>> есть ли средства (и какие) для расшифровки (пусть путем подбора)
DEO>> такого ключа ?
A> Ты  же  _хозяин_  и того, и другого сервера? Обращаемся к теории
A> защиты  информации,  вычленяем  системы,  и  определяем уязвимые
A> компоненты,

Добрый ASA :/

-- 
-- Maksim

Re: [Comm] Перенос юзера на другую систему

[Sergey A. Sholokhov]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

On Sun, Oct 13, 2002 at 10:34:23PM +0400, Dmitry E. Oboukhov wrote:
>тут возникла задачка переместить одного юзера вместе с его паролем
>на другой сервер.
>
>сервер стоит на Дебиане, исппользуется МД5.
>исходный юзер находится на сервере АЛМ2
>
>можно ли как-то это проделать?
>
>если переместить запись из
>/etc/tcb/username/shadow в /etc/shadow будет работать ?
>
в sid чтото есть особо не копал:
hun7er@oks:~$ apt-cache search blowfish
steghide - A steganography tool
tunnelv - Encrypted network connection within a TCP/IP connection
vpnd - Virtual Private Network Daemon
beecrypt2 - An open source C library of cryptographic algorithms.
beecrypt2-dev - Header files for beecrypt, a library of cryptographic algorithms.
libcrypt-cbc-perl - Implementation of cipher block chaining (CBC) mode
libmcrypt-dev - De-/Encryption Library development files
libmcrypt4 - De-/Encryption Library
libcrypt-blowfish-perl - Blowfish cryptography for Perl
libgcrypt-dev - LGPL Crypto library - development files
libgcrypt-doc - LGPL Crypto library - documentation
libgcrypt1 - LGPL Crypto library - runtime library
python-crypto - Cryptpgraphic algorithms and protocols for Python
python2.1-crypto - Cryptpgraphic algorithms and protocols for Python
python2.2-crypto - Cryptpgraphic algorithms and protocols for Python
python2.3-crypto - Cryptpgraphic algorithms and protocols for Python

-- 
<BR>  [ X A H 7 E P ]
      mail  : hun7er@sutd.ru
      icq   : 72994428

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] Перенос юзера на другую систему

[Anton V. Boyarshinov]

Добрый днеь

On Sun, 13 Oct 2002 22:34:23 +0400
"Dmitry E. Oboukhov" <node@avanto.mpei.ac.ru> wrote:

> тут возникла задачка переместить одного юзера вместе с его
> паролем на другой сервер.
> 
> сервер стоит на Дебиане, исппользуется МД5.
> исходный юзер находится на сервере АЛМ2
> 
> можно ли как-то это проделать?
> 
> если переместить запись из
> /etc/tcb/username/shadow в /etc/shadow будет работать ?
Да будет. Я переносил пользователей с RH6.2 на АЛМ2
Хэши разные, но АЛМ2 прекрасно понимает MD5, отличая его по
началу кроптованной строки.

Антон

PS а не проще ли было самому проверить? Дело пяти минут.
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
  9:28am  up 53 days,  1:41,  7 users,  load average: 0.12, 0.06,
0.09