Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Witam,
Muszę przygotować serwer pod sftp, więc postanowiłem go zabezpieczyć chrootem. Niestety borykam się z problemem który wynika albo z mojego błędu albo niewiedzy i niezrozumienia tematu.
W konfiguracji ssh mam wpisy:
Subsystem sftp internal-sftp Match User test ChrootDirectory /var/chrooted/test ForceCommand internal-sftp AllowTcpForwarding no X11Forwarding no
Użytkownik wygląda tak:
test:x:505:505::/home/test:/sbin/nologin
Uprawnienia na chrootowanym folderze wyglądają tak:
ls-l /var/chrooted/ drwxr-x---. 3 root root 4096 Feb 11 12:58 test
Cała, prowadząca do niego ścieżka, jest własnością roota.
Zgodnie z poradnikiem: https://wiki.archlinux.org/index.php/SFTP-chroot, aby nie pozwolić na eskalację uprawnień, robię montowanie katalogu w którym użytkownik ma prawa zapisu (/home/test) do katalogu chrootowanego (/var/chrooted/test)
mount --bind /var/chrooted/test/ /home/test/
I do tej pory wszystko zgadza się z wszelkimi poradnikami jakie znalazłem na sieci.
Mój problem pojawia się w momencie w którym próbuje cokolwiek zrobić na zasobie do którego się podłączam.
ls -ld /var/chrooted/test/ drwxr-x---. 3 root root 4096 Feb 11 12:58 /var/chrooted/test/ ls -l /var/chrooted/test/total 4 drwxrwxrwx. 2 test test 4096 Feb 11 12:58 folder1
sftp test@ip test@ip's password: sftp> ls Couldn't get handle: Permission denied sftp> cd folder1 Couldn't canonicalise: Permission denied
Problemem są uprawnienia na folderze, ale właśnie tego nie potrafię rozgryźć.
Być może ktoś z kolegów/koleżanek musiał się zetknąć z SFTP i Chrootem i potrafi pomóc?
Offline
Dawno się nie bawiłem chrootowaniem sftp, ale zobacz, czy coś takiego ruszy:
Subsystem sftp internal-sftp #........ Match group sftpgroup ChrootDirectory /home/%u GatewayPorts no X11Forwarding no ForceCommand internal-sftp AllowTcpForwarding no PermitTunnel no AuthorizedKeysFile /var/keys/%u/authorized_keys
Kiedyś to nawet działało u mnie w mniej-więcej takiej formie, i dotyczyło pacjentów dodanych do grupy systemowej sftpgroup.
Poza tym zobacz, czy przypadkiem w Proftpd nie pójdzie łatwiej, serwery ftp nie są tak bezpieczne, ale łatwiej pakują pacjenta w chroocie, natomiast Proftpd na 100% obsługuje protokół sftp.
SSH w domyślnej wersji [b]zamknie pacjenta w chroocie tylko wtedy, jak chrootowany folder jest własnością roota[/b] i ma odpowiednie uprawnienia.
To jest spore ograniczenie, w powyższym przykładzie konfigu folder domowy pacjenci mieli w scieżce /home/pacjent/pacjent,
i uprawnienia wygladały tak:
/home/pacjent - root:root - chmod 700
/home/pacjet/pacjent - pacjent:users chmod 700.
Żeby mu takie ograniczenie wybić ze łba, trzeba zajrzeć do kodu, zmienić jedna funkcję i skompilować Openssh we własnym zakresie.
A tu przykład chroota z powłoką shell:
Foldery:
ls -ld /home/bydle drwxr-xr-x 11 root root 4096 2012-07-27 /home/bydle ls -l /home/bydle razem 36 drwxr-xr-x 2 root root 4096 2012-07-27 bin drwx------ 3 bydle bydle 4096 2012-07-27 bydle drwxr-xr-x 3 root root 4096 2012-07-27 dev drwxr-xr-x 7 root root 4096 2012-07-27 etc drwxr-xr-x 2 root root 4096 2012-07-27 home lrwxrwxrwx 1 root root 5 2012-07-26 lib -> lib64 drwxr-xr-x 3 root root 4096 2012-07-27 lib64 drwxr-x--- 2 root root 4096 2012-07-27 sbin drwxrwxrwt 3 root root 4096 2012-07-27 tmp drwxr-xr-x 5 root root 4096 2012-07-27 usr
Konfig ssh:
Match group chrootssh ChrootDirectory /home/%u GatewayPorts no X11Forwarding no AllowTcpForwarding no
EDIT:
Te moje kombinacje są z przed kilku lat (ale działa):
~> ssh bydle@localhost bydle@localhost's password: Last login: Wed Feb 12 10:33:34 2014 from localhost -bash: /dev/null: Permission denied (Chroot) 10:34:27 localhost : /home/bydle/bydle bydle $
Tylko musiałem dorobić takie dowiązanie, bo nie umiał trafić do folderu domowego:
ls -l /home/bydle/home/bydle/bydle lrwxrwxrwx 1 root root 11 02-12 10:30 /home/bydle/home/bydle/bydle -> ../../bydle
Jeszcze coś miauczy o /dev/null - partycja /home zamontowana z opcją nodev. ;)
To wygląda trochę lepiej:
http://allanfeid.com/content/creating-chroot-jail-ssh-access
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2014-02-12 10:44:09)
Offline
Witam i dziękuje za odpowiedź :-)
Moim problemem jest to, że jedyne z czego mogę skorzystać do czyste ssh (SFTP).
Są trzy rzeczy których nie rozumiem w tej konfiguracji.
Pierwszą jest montowanie z bind'em folderów. Skoro wystarczy zagnieździć folder z uprawnieniami dla użytkownika
/home/pacjent - root:root - chmod 700
/home/pacjent/pacjent - pacjent:users chmod 700[/quote]
to w jaki sposób ma to ograniczyć go przed eskalacją uprawnień?
Druga rzecz, jest taka: po co montować folder w folderze skoro właśnie taką sztuczką jak powyżej załatwiamy kwestię uprawnień?
Natomiast trzecia to tak naprawdę zrozumienie:
- w konfiguracji masz ustawiony [b]ChrootDirectory /home/%u[/b]
- użytkownik pacjent wpada zatem do tego folderu [b]ChrootDirectory /home/pacjent[/b], do którego nie ma uprawnień
- skoro nie ma uprawnień, podobnie jak w moim przypadku nie będzie mógł zrobić ani ls, ani cd do folderu [b]/home/pacjent/pacjent[/b] gdyż dostanie [b]Couldn't canonicalise: Permission denied[/b] - czy jednak u ciebie nie było z tym problemu?
- jak powinien wyglądać kierunek montowania?
- czy jest jakiś związek z katalogiem domowym użytkownika a montowanym folderem?Ostatnio edytowany przez lun (2014-02-12 14:56:40)
Pozdrawiam,
LuN
Offline
SSH nie otworzy chroota do folderu, jeśli folder ma innego właściciela, niż root, tak to jest zrobione w kodzie programu.
Do tego sprawdza dokładnie uprawnienia, przeważnie nie zaloguje się w przypadku nieszczelnych uprawnień folderu domowego, czyli słabszych niż 750.
U mnie jest /home/pacjent na chroota dlatego, ze najpierw miałem zrobione to na ftp przez pure-ftpd, który bez problemu chrootował w $HOME.
Potem chciałem przeprowadzić to na SSH, i zaczęły się schody, z których wykluła się taka konfiguracja, ale działa.
W międzyczasie nawet, ponieważ serwer stał na Gentoo, zajrzałem do źródeł serwera SSH i zmieniłem jedna funkcję, żeby działało tak, jak w pure-ftpd, ale w końcu dałem sobie spokój z majstrowaniem w kodzie.
Taka konfiguracja, jak przykład u mnie, działa i na ssh/sftp,
i równocześnie przez ftp (Proftpd, Pure-ftpd), a każdy pacjent ma swoją prywatną klatkę z osobnymi prywatnymi binarkami i skryptami.
Dostęp po SSH/SFTP/FTPS/FTP.
SSH/SFTP dają dostąp do /home/pacjent, serwer ftp chrootuje do /home/pacjent/pacjent, który to folder jest domowym pacjenta.
To wszystko, dlaczego u Ciebie nie idzie, nie wiem, nie mam bladego pojęcia, gdzie masz błąd.
Z montowaniem musisz sobie sam poradzić, poza tym logi, logi i jeszcze raz logi.
Możesz spróbować logowania z opcją [b]-v[/b], to prędzej napisze, co go boli.
Przykładowo:
sftp -v bydle@localhost OpenSSH_6.4, OpenSSL 1.0.1e 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 20: Applying options for * debug1: /etc/ssh/ssh_config line 72: Applying options for localhost debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /home/użyszkodnik/.ssh/id_rsa type 1 debug1: identity file /home/użyszkodnik/.ssh/id_rsa-cert type -1 debug1: identity file /home/użyszkodnik/.ssh/id_dsa type -1 debug1: identity file /home/użyszkodnik/.ssh/id_dsa-cert type -1 debug1: identity file /home/użyszkodnik/.ssh/id_ecdsa type 3 debug1: identity file /home/użyszkodnik/.ssh/id_ecdsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.4p1-hpn14v2 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.4p1-hpn14v2 debug1: match: OpenSSH_6.4p1-hpn14v2 pat OpenSSH* debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: AUTH STATE IS 0 debug1: REQUESTED ENC.NAME is 'aes128-ctr' debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com debug1: REQUESTED ENC.NAME is 'aes128-ctr' debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA a0:21:bb:65:41:b3:71:ee:50:2e:c3:17:7d:98:34:1f debug1: Host '[localhost]:22' is known and matches the ECDSA host key. debug1: Found key in /home/użyszkodnik/.ssh/known_hosts:4 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/użyszkodnik/.ssh/id_rsa debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Trying private key: /home/użyszkodnik/.ssh/id_dsa debug1: Offering ECDSA public key: /home/użyszkodnik/.ssh/id_ecdsa debug1: Server accepts key: pkalg ecdsa-sha2-nistp521 blen 172 debug1: read PEM private key done: type ECDSA debug1: Enabling compression at level 6. debug1: Single to Multithread CTR cipher swap - client request debug1: Authentication succeeded (publickey). Authenticated to localhost ([127.0.0.1]:22). debug1: Final hpn_buffer_size = 2097152 debug1: HPN Disabled: 0, HPN Buffer Size: 2097152 debug1: channel 0: new [client-session] debug1: Enabled Dynamic Window Scaling debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: need rekeying debug1: SSH2_MSG_KEXINIT sent debug1: rekeying in progress debug1: SSH2_MSG_KEXINIT received debug1: AUTH STATE IS 1 debug1: REQUESTED ENC.NAME is 'aes128-ctr' debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com debug1: REQUESTED ENC.NAME is 'aes128-ctr' debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA a0:21:bb:65:41:b3:71:ee:50:2e:c3:17:7d:98:34:1f debug1: Host '[localhost]:22' is known and matches the ECDSA host key. debug1: Found key in /home/użyszkodnik/.ssh/known_hosts:4 debug1: ssh_ecdsa_verify: signature correct debug1: set_newkeys: rekeying debug1: spawned a thread debug1: spawned a thread debug1: Enabling compression at level 6. debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: set_newkeys: rekeying debug1: spawned a thread debug1: spawned a thread debug1: SSH2_MSG_NEWKEYS received debug1: Sending subsystem: sftp Connected to localhost. sftp> debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1 sftp> exit debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK Transferred: sent 3344, received 2968 bytes, in 60.6 seconds Bytes per second: sent 55.2, received 49.0 debug1: Exit status 0 debug1: compress outgoing: raw data 116, compressed 94, factor 0.81 debug1: compress incoming: raw data 280, compressed 162, factor 0.58
Ostatnio edytowany przez Jacekalex (2014-02-12 15:01:38)
Offline
Cześć,
Tak wiem że logi, logi i jeszcze raz logi ale problem jest taki, że nawet z sftp -v nie pokazuje dodatkowych informacji przy wykonywaniu komend.
Dlatego czy to cd, czy ls nie wypluwa nic, poza to co wkleiłem na górze.
Z mojego punktu widzenia, oraz sprawdzając z poradnikami, nie widzę błędu konfiguracyjnego. Wydaje mi się że błąd jest gdzieś w mojej logice i wyobrażeniu jak to powinno działać.
Offline
Jeżeli nie widzisz błędu, ale nie działa, to kto i jak Twoim zdaniem ma dostrzec ten błąd?
Była tu kiedyś wróżka, ale zwiała na Afganistanu, i zabrała ostatnią szklaną kulę.
Także zamiast pisać, ze nie wiesz, gdzie masz błąd, to weź się w garść,
i bierz się do roboty.
A tu masz [url=http://rtfm.killfile.pl/]lekturę na dobranoc[/url].
To by było na tyle
Ostatnio edytowany przez Jacekalex (2014-02-12 22:58:21)
Offline
Jacekalex wybacz, ale twoje pytanie wydaje się trochę infantylne. Gdybym wychodził z założenia że wiem i umiem wszystko najlepiej na świecie, nie pytał bym na forum gdzie popełniłem błąd.
Mój punkt widzenia i moje przeświadczenie nie jest prawdą ostateczną, stąd prośba o pomoc.
Wygląda mi na to, że wyszedłeś z prostego założenia że przyszedł człowiek i chce gotowca bo nie chce mu się szukać rozwiązania. Gdyby tak było, przekalkowałbym twoją działającą konfigurację i zamknął temat. To że go kontynuuję świadczy że jest inaczej.
Idąc dalej, znalazłem błąd i rzeczywiście był on w sumie do zobaczenia we fragmentach uprawnień, które podawałem w pierwszym poście. Zmieniając katalog / dla użytkownika na /var/chrooted/ nie dałem uprawnienia +x dla other. Stąd nie mogłem wylistować katalogu, oraz wskoczyć do /home/test/. Więc jak widzisz do "roboty" byłem "zabrany" cały czas.
Pewnie dla bardziej wprawnego oka było to pewnie do "wyłapania" w parę minut.
Offline
Uprawnienia?
Folder chroota dla pacjenta bydle:
ls -ld /home/bydle drwxr-xr-x 11 root root 4096 2012-07-27 /home/bydle
I uprawienia w w chroocie pacjenta bydle:
ls -ld /home/bydle/* drwxr-xr-x 2 root root 4096 2012-07-27 /home/bydle/bin drwx------ 3 bydle bydle 4096 2012-07-27 /home/bydle/bydle drwxr-xr-x 3 root root 4096 2012-07-27 /home/bydle/dev drwxr-xr-x 7 root root 4096 2012-07-27 /home/bydle/etc drwxr-xr-x 3 root root 4096 02-12 10:29 /home/bydle/home lrwxrwxrwx 1 root root 5 2012-07-26 /home/bydle/lib -> lib64 drwxr-xr-x 3 root root 4096 2012-07-27 /home/bydle/lib64 drwxr-x--- 2 root root 4096 2012-07-27 /home/bydle/sbin drwxrwxrwt 3 root root 4096 2012-07-27 /home/bydle/tmp drwxr-xr-x 5 root root 4096 2012-07-27 /home/bydle/usr
Było już wcześniej.
I nie chcę Cię obsobaczać, ale uprawnienia chmod i ACL, to jest przedszkole Linuxa.
Tak samo, jak tajna informacja, ze żeby pacjent mógł wejść do folderu,
to folder musi mieć atrybut uruchomienia, to też przedszkole.
A zanim zaczniesz stawiać chrooty na ssh, to przedszkole jest obowiązkowe, niczym pacież....
I naucz się wklejać logi i wyniki, zamiast pisać, że Twoim zdaniem nic w nich nie ma.
~> ssh bydle@localhost Last login: Thu Feb 13 22:48:25 2014 from localhost -bash: /dev/null: Permission denied (Chroot) 22:48:39 localhost : /home/bydle/bydle bydle $
SOA#1
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2014-02-13 22:52:24)
Offline
Time (s) | Query |
---|---|
0.00015 | SET CHARSET latin2 |
0.00006 | SET NAMES latin2 |
0.00111 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.225.195.4' WHERE u.id=1 |
0.00060 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.225.195.4', 1732852770) |
0.00069 | SELECT * FROM punbb_online WHERE logged<1732852470 |
0.00090 | DELETE FROM punbb_online WHERE ident='3.133.146.94' |
0.00090 | SELECT topic_id FROM punbb_posts WHERE id=256166 |
0.00008 | SELECT id FROM punbb_posts WHERE topic_id=25219 ORDER BY posted |
0.00081 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=25219 AND t.moved_to IS NULL |
0.00008 | SELECT search_for, replace_with FROM punbb_censoring |
0.00264 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=25219 ORDER BY p.id LIMIT 0,25 |
0.00179 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=25219 |
Total query time: 0.00981 s |