Я хочу разрешить некоторым доверенным пользователям отправлять файлы scp на мой сервер (определенному пользователю), но я не хочу предоставлять этим пользователям ни домашний адрес, ни вход по ssh.
У меня возникли проблемы с пониманием правильных настроек пользователей/групп, которые мне нужно создать, чтобы это произошло.
Приведу пример;
Имея:
MyUser@MyServer
MyUser
принадлежит к группеMyGroup
- Допустим, домом MyUser будет:
/home/MyUser
SFTPGuy1@OtherBox1
SFTPGuy2@OtherBox2
Они дают мне свои id_dsa.pub
'ы, и я добавляю их к своимauthorized_keys
Я думаю, тогда я бы сделал на своем сервере что-то вроде
useradd -d /home/MyUser -s /bin/false SFTPGuy1
(и то же самое для других..)
И последнее useradd -G MyGroup SFTPGuy1
(опять же, для другого парня)
Я бы ожидал, что тогда SFTPGuys смогут sftp -o IdentityFile=id_dsa MyServer
попасть в дом MyUser...
Ну, это не так... SFTP просто продолжает спрашивать у меня пароль.
Может ли кто-нибудь подсказать, что я упускаю?
Спасибо большое,
ф.
[РЕДАКТИРОВАТЬ:Мессав StackOverflow меня спросили, доступен ли файл authorized_keys для чтения другим пользователям (членам MyGroup). Это интересный момент, вот мой ответ:
Ну, это не так (было 700), но затем я изменил права доступа к каталогу .ssh и файлу auth на 750, хотя эффекта все равно не было. Думаю, стоит упомянуть, что мой домашний каталог ( /home/MyUser
) также доступен для чтения для группы; большинство каталогов имеют права 750, а конкретная папка, куда они сбрасывают файлы, — 770.
Тем не менее, что касается файла аутентификации, я полагаю, что аутентификация будет выполняться локальным пользователем MyServer
, не так ли? Если так, то я не понимаю, зачем другим пользователям его читать... ну... просто интересно. ]
решение1
Прежде чем попробовать это, пожалуйста, дочитайте до конца.
Вы можете сделать то, что хотите, создав 2 пользователей, поместив их в одну группу и дав им один и тот же домашний каталог. Затем создайте файл ~/.ssh/authorized_keys в общем домашнем каталоге с ключами в нем.
Учетные записи должны иметь оболочку, поэтому заблокируйте их, usermod -L LOGIN
чтобы предотвратить интерактивный вход.
Права доступа к каталогу ~/.ssh должны быть g:rx, а к ~/.ssh/authorized_keys — g:r--
chmod g+rx ~/.ssh
chmod g+r ~/.ssh/authorized_keys
Это затем вызывает проблемы с sshd, так как он ожидает, что каталог будет не больше g:r--, а файл будет g:---, вы получаете сообщение об ошибке
Authentication refused: bad ownership or modes for file /home/test/.ssh/authorized_keys
Чтобы эта схема заработала, вам теперь придетсясломать встроенные проверки sshdпутем редактирования
/etc/sshd_config
и установки StrictModes no
из значения по умолчанию StrictModes yes
. Перезапустите sshd, чтобы изменения вступили в силу.
Это должно работать так, как вы хотите. К сожалению, вы отключили безопасность sshd и можете внести изменения позже, которые оставят вашу систему полностью открытой.
Чтобы сделать это более безопасно, не вносите никаких изменений, указанных выше.
Создайте 2 учетные записи пользователей в одной группе и настройте их ~/.ssh/authorised_keys. Создайте ссылку из каждого домашнего каталога на место, куда вы хотите, чтобы они помещали свои файлы.
ln -s -n /path/to/stuff content
Заблокируйте права доступа к домашнему каталогу, чтобы пользователи не могли в него писать.
Остановить интерактивный вход в учетные записи
usermod -L LOGIN
Измените разрешения на /path/to/stuff, чтобы разрешить групповой доступ.
решение2
Похоже, вы хотите предоставить доступ к идентификатору пользователя, который действует как Dropbox для файлов. Вы можете ограничить то, что пользователи могут делать в файле авторизованных ключей.
Поскольку вы хотите, чтобы они подключались только к этому идентификатору пользователя на сервере, вы можете предоставить им файл .ssh/config, который напрямую сопоставляет их с правильным идентификатором пользователя.
решение3
Ответ на этот вопрос -Как создать учетную запись пользователя, которая разрешает загрузку только через sftp?- рекомендует пакет под названиемscponly- Я никогда им не пользовался, но, похоже, он может сделать то, что вам нужно.
решение4
Проверка файлов журнала может помочь. Пожалуйста, введите следующее после "неудачного" входа
tail -n 50 /var/log/secure
и опубликуйте вывод