Konta SFTP-only możemy chcieć użyć, gdy mamy zainstalowany na serwerze SSH (prawie zawsze) i udostępniamy dane innemu systemowi, który loguje się i pobiera je (i ewentualnie usuwa), a nie chcemy instalować dodatkowej aplikacji jak FTPd czy HTTPd.
Zakładamy, że logowanie odbywa się automatycznie z użyciem klucza i bez hasła. Nazwa użytkownika na serwerze zdalnym to: copy z UID 2000, a grupa to sftponly z GID 2000. Serwer z SFTP to 10.7.18.2, a klient, z którego będziemy się logować to 10.7.18.1
Na pierwszy ogień musimy skongfigurować demona SSH, aby posiadał następujące wpisy:
Subsystem sftp internal-sftp AuthorizedKeysFile .ssh/authorized_keys AllowUsers copy@10.7.18.1 Match user copy ChrootDirectory %h ForceCommand internal-sftp AllowTCPForwarding no X11Forwarding no
Oraz żeby nie posiadał takiego wpisu lub podobnego
#Subsystem sftp /usr/libexec/openssh/sftp-server
Następnym krokiem jest utworzenie katalogu, gdzie chcemy mieć katalogi w chroot, ja utworze katalog chroot w głównym drzewie
mkdir /chroot
Po utworzeniu katalogu a przed utworzeniem użytkownika warto utworzyć osobną grupę dla użytkownika
groupadd -g 2000 sftponly
Teraz naszym zadaniem jest utworzenie użytkownika z shellem ustawionym na /bin/false i z katalogiem domowym w wybranym miejscu.
adduser -u 2000 -g 2000 -s /bin/false -d /chroot/copy copy
Konto zostało utworzone z następującymi prawami dostępu
ls -ald /chroot/copy/ drwx------. 2 copy sftponly 4096 Mar 3 12:32 /chroot/copy/
Muszą one zostać zedytowane tak, aby właścicielem katalogu domowego konta chrootowanego był root i trzeba trochę poluzować dostępy
chown root /chroot/copy chmod 755 /chroot/copy
Jeszcze musimy stworzyć katalog na klucze, nadać mu odpowiednie uprawnienia i wkopiować klucze publiczne, które będą mogły logować się do systemu, żeby skopiować jakieś dane za pomocą sftp
mkdir /chroot/copy/.ssh chown root:root /chroot/copy/.ssh
Teraz czas na wkopiowanie klucza publicznego i ustawienie mu odpowiednich uprawnień
echo 'AAAA...== user@maszyna' > /chroot/copy/.ssh/authorized_keys chown root:root /chroot/copy/.ssh/authorized_keys chmod 644 /chroot/copy/.ssh/authorized_keys
Po tych operacjach możemy zrestartować SSHD
service sshd restart
Jeżeli wykorzystujemy selinux w trybie enforcing, to musimy jeszcze skonfigurować dla plików i katalogów odpowiednie konteksty z użyciem aplikacji semanage dostępnej w pakiecie
policycoreutils-python
Same ustawienia kontekstów
semanage fcontext -a -t home_root_t "/chroot(/.*)?" semanage fcontext -a -t user_home_t "/chroot/copy(/.*)?" semanage fcontext -a -t ssh_home_t "/chroot/copy/.ssh(/.*)?" restorecon -FFrv /chroot
Po wykonaniu powyższych operacji konto copy powinno umożliwiać łączenie się do niego ze wskazanego klienta za pomocą komendy
sftp -o "IdentityFile=/sciezka/do/klucza/prywatnego" copy@10.7.18.2
Po zalogowaniu powinniśmy zobaczyć następujące okno
Connecting to 10.7.18.2... sftp>
Jeżeli tak nie jest i system odrzuca połączenie lub prosi o hasło warto rozpocząć rozwiązywanie problemu od włączenia SSHD na serwerze w trybie debug poprzez dodanie do /etc/ssh/sshd_config wpisu
LogLevel DEBUG
i zrestartowanie usługi
service sshd restart
A po stronie klienta użyć sftp z opcją -v lub -vv
sftp -v -o "IdentityFile=/sciezka/do/klucza/prywatnego" copy@10.7.18.2 sftp -vv -o "IdentityFile=/sciezka/do/klucza/prywatnego" copy@10.7.18.2
Po stronie serwera logi czytać można wykorzystując taila
tail -fn0 /var/log/secure
Article Number: 455
Posted: Fri, Nov 30, 2018 10:50 PM
Last Updated: Fri, Nov 30, 2018 10:50 PM
Online URL: http://kb.ictbanking.net/article.php?id=455