Титла: GUI scp
Публикувано от: Agent_SMITH в Apr 09, 2006, 01:02
Привет на всички:
Търси се обичаен заподозрян със следните характеристики:
SCP client
+ по възможност с GUI (gtk based)
+ по възможност подобен на mc (два панела local/remote)
Едно от предложенията на бат' Google - secpanel не мяза на нищо. За това ще съм благодарен на отзиви базирани на личен опит, не на резултати в google.
Търси се обичаен заподозрян със следните характеристики:
SCP client
+ по възможност с GUI (gtk based)
+ по възможност подобен на mc (два панела local/remote)
Едно от предложенията на бат' Google - secpanel не мяза на нищо. За това ще съм благодарен на отзиви базирани на личен опит, не на резултати в google.
Титла: GUI scp
Публикувано от: vesselinkolev в Apr 09, 2006, 02:27
Неправилно питаш. Ти не търсиш SCP клиент, а SFTP клиент.
В GNOME:
-- Nautilus поддържа SFTP протокола. Работи с OpenSSH ключове и приема кеширания ключ от ssh агента. Задаването на потребител и адрес става в Location полето на Nautilus във формата:
sftp://user@host
Може да се указва и директно вътрешна директория или файл.
В KDE:
-- Konqueror поддържа протокола fish. Работи с OpenSSH ключове и приема кеширания от ssh агента ключ. Задаването на потребител и адрес става в Location полето на Konqueror във формата:
fish://user@host
Може да се указва и директно вътрешна директория или файл.
Мисля, че това решава поставената от теб задачка.
В GNOME:
-- Nautilus поддържа SFTP протокола. Работи с OpenSSH ключове и приема кеширания ключ от ssh агента. Задаването на потребител и адрес става в Location полето на Nautilus във формата:
sftp://user@host
Може да се указва и директно вътрешна директория или файл.
В KDE:
-- Konqueror поддържа протокола fish. Работи с OpenSSH ключове и приема кеширания от ssh агента ключ. Задаването на потребител и адрес става в Location полето на Konqueror във формата:
fish://user@host
Може да се указва и директно вътрешна директория или файл.
Мисля, че това решава поставената от теб задачка.
Титла: GUI scp
Публикувано от: vesselinkolev в Apr 09, 2006, 08:45
Само да допълня себе си. Midnight Commander също може да се използва за SFTP клиент. Той поддържа fish като протокол.
За да може да се работи с fish под Midnight Commander, в командния ред на програмата се пише инструкция от вида:
cd /#sh:user@host
и се натиска Enter. Следва диалог за уточняване на паролата на потребителя user. Работи с използването на OpenSSH ключове и ssh-agent.
Може да се използва и някой от панелите с менюта "Left" и "Right". От там се избира подменю "Shell link". В тесктовия прозорец, който ще се появи, се описва целта като име на потребител и хост така:
user@host
и след натискане на "Enter" се влиза в отдалечената машина през протокол sftp.
Нужно е да напомня, че дизайна на протокола SSH, а оттам това се населдява в протокола SFTP, не включва възможността за динамична договорка на криптиращия сесиен ключ по време на сесията. Това води до принципен проблем, който се състои в това, че ако се трансферира доста голям файл в рамките на поредица от файлове през SFTP и този, който подслушва сесията знае кой именно голям файл се тегли, може да отгатне сесийния ключ и да прочете останалите файлове от серията, които ще се трансферират. Имайте предвид това. До момента този вид атака срещу сесиен ключ е теоретична, но това е само защото никой не е публикувал практическа реализация.
Освен това SFTP протокола изисква върху отдалечената машина да има системен потребителски профил, което прави този протокол вреден при използването му в многопотребителски режим и особено при голямо число протребители. Причината е, че създава опасност от експлоатиране на локални "дупки" върху отдалечената система (примерно проблеми с ядрото или glibc). Един от вариантите е да се използва потребителски команден интерпретатор scponly за потребителите върху отдалечената система. Това обаче също не спасява на 100% отдалечената система от пробив. Sshd винаги се стартира като потребител root и оттам би могла да бъде експлоатирана евентуална "дупка" в самия демон (сепарацията на привилегии следва след установяване на сесията). Да, някой по-напреднал администратор може да си направи труда да пуска чрез xinetd по един sshd за всеки потребител на непривилигерован порт (>1024) и процеса на демона да е с правата на потребителя. Това обаче е доста спорно откъм ефективност решение.
Доколкото се търси графичен интерфейс за SFTP предполагам, че в случая става въпрос именно за многопотребителска система, където ще има потребители, които не са на "ти" с работа в текстова конзола. За такива системи е много по-удачно с цел управление на файлови хранилища да се използва някакъв DAV клиент през web приложение, обвито със SSL и удостоверяване на клиент със X.509 сертификат преди достъпването на DAV клиента.
За да може да се работи с fish под Midnight Commander, в командния ред на програмата се пише инструкция от вида:
cd /#sh:user@host
и се натиска Enter. Следва диалог за уточняване на паролата на потребителя user. Работи с използването на OpenSSH ключове и ssh-agent.
Може да се използва и някой от панелите с менюта "Left" и "Right". От там се избира подменю "Shell link". В тесктовия прозорец, който ще се появи, се описва целта като име на потребител и хост така:
user@host
и след натискане на "Enter" се влиза в отдалечената машина през протокол sftp.
Нужно е да напомня, че дизайна на протокола SSH, а оттам това се населдява в протокола SFTP, не включва възможността за динамична договорка на криптиращия сесиен ключ по време на сесията. Това води до принципен проблем, който се състои в това, че ако се трансферира доста голям файл в рамките на поредица от файлове през SFTP и този, който подслушва сесията знае кой именно голям файл се тегли, може да отгатне сесийния ключ и да прочете останалите файлове от серията, които ще се трансферират. Имайте предвид това. До момента този вид атака срещу сесиен ключ е теоретична, но това е само защото никой не е публикувал практическа реализация.
Освен това SFTP протокола изисква върху отдалечената машина да има системен потребителски профил, което прави този протокол вреден при използването му в многопотребителски режим и особено при голямо число протребители. Причината е, че създава опасност от експлоатиране на локални "дупки" върху отдалечената система (примерно проблеми с ядрото или glibc). Един от вариантите е да се използва потребителски команден интерпретатор scponly за потребителите върху отдалечената система. Това обаче също не спасява на 100% отдалечената система от пробив. Sshd винаги се стартира като потребител root и оттам би могла да бъде експлоатирана евентуална "дупка" в самия демон (сепарацията на привилегии следва след установяване на сесията). Да, някой по-напреднал администратор може да си направи труда да пуска чрез xinetd по един sshd за всеки потребител на непривилигерован порт (>1024) и процеса на демона да е с правата на потребителя. Това обаче е доста спорно откъм ефективност решение.
Доколкото се търси графичен интерфейс за SFTP предполагам, че в случая става въпрос именно за многопотребителска система, където ще има потребители, които не са на "ти" с работа в текстова конзола. За такива системи е много по-удачно с цел управление на файлови хранилища да се използва някакъв DAV клиент през web приложение, обвито със SSL и удостоверяване на клиент със X.509 сертификат преди достъпването на DAV клиента.
Титла: GUI scp
Публикувано от: Agent_SMITH в Apr 09, 2006, 18:17
Благодаря ти, едва ли бих могъл да искам повече информация по темата 
Титла: GUI scp
Публикувано от: v_badev в Apr 10, 2006, 10:36
Аз май малко късно се обаждам, но може да пробваш малко по-различен подход. С sshfs да си монтираш отдалечената файлова система и да използваш произволен файлов мениджър с нея.