Jak skonfigurować umas ssh dla wszystkich typów połączeń

Szukałem sposobu na instalacyjnego OpenSSH umask aby 0027w sposób spójny we wszystkich typów połączeń.

Przez typy połączeń mam na myśli:

1. sftp
2. scp
3. nazwa hosta ssh
4. program nazwa hosta ssh

Różnica między 3. a 4. polega na tym, że pierwszy uruchamia powłokę, która zwykle odczytuje /etc/profileinformacje, a druga nie.

Ponadto, czytając ten post , dowiedziałem się o opcji -u, która jest obecna w nowszych wersjach OpenSSH. Jednak to nie działa.

Muszę również dodać, że /etc/profileteraz obejmuje umask 0027.

Przechodzenie punkt po punkcie:

• sftp - Ustawienie -u 0027w sshd_configjak wspomniano tutaj , nie jest wystarczające.

Jeśli nie ustawię tego parametru, sftp używa domyślnie umask 0022. Oznacza to, że jeśli mam dwa pliki:

-rwxrwxrwx 1 user user 0 2011-01-29 02:04 execute
-rw-rw-rw- 1 user user 0 2011-01-29 02:04 read-write

Kiedy używam sftp do umieszczenia ich na maszynie docelowej, faktycznie otrzymuję:

-rwxr-xr-x 1 user user 0 2011-01-29 02:04 execute
-rw-r--r-- 1 user user 0 2011-01-29 02:04 read-write

Jednakże kiedy ustawić -u 0027na sshd_configurządzenia docelowego I rzeczywiście otrzymujemy:

-rwxr--r-- 1 user user 0 2011-01-29 02:04 execute
-rw-r--r-- 1 user user 0 2011-01-29 02:04 read-write

co nie jest spodziewane, ponieważ tak naprawdę powinno być:

-rwxr-x--- 1 user user 0 2011-01-29 02:04 execute
-rw-r----- 1 user user 0 2011-01-29 02:04 read-write

Czy ktoś rozumie, dlaczego tak się dzieje?

• scp - Niezależnie od ustawień sftp , uprawnienia są zawsze umask 0022. Obecnie nie mam pojęcia, jak to zmienić.

• nazwa hosta ssh - nie ma tutaj problemu, ponieważ powłoka /etc/profiledomyślnie czyta , co oznacza umask 0027w bieżącej instalacji.

• program nazwa hosta ssh - taka sama sytuacja jak scp .

W sumie, na ustawienie umask sftpzmienia wynik, ale nie tak jak powinno, ssh hostnamedziała zgodnie z oczekiwaniami czytania /etc/profilei oba scpi ssh hostname programwydaje się, że umask 0022ustalony gdzieś.

Wszelkie informacje na temat powyższych punktów są mile widziane.

EDYCJA: Chciałbym uniknąć poprawek wymagających ręcznej kompilacji openssh. W systemie działa Ubuntu Server 10.04.01 (lucid) LTS z opensshpakietami indywidualnymi.

Odpowiedź: Jak wskazał poige, użycie pam_umask załatwiło sprawę.

Dokładne zmiany to:

Linie dodane do /etc/pam.d/sshd:

# Setting UMASK for all ssh based connections (ssh, sftp, scp)
session    optional     pam_umask.so umask=0027

Ponadto, aby wpłynąć na wszystkie powłoki logowania, niezależnie od tego, czy pochodzą, /etc/profileczy też nie, dodano te same linie /etc/pam.d/login.

EDYCJA : Po niektórych komentarzach ponownie przetestowałem ten problem.

Przynajmniej w Ubuntu (gdzie testowałem) wydaje się, że jeśli użytkownik ma inny zestaw umask w plikach inicjujących powłoki (.bashrc, .zshrc, ...), umask PAM jest ignorowany, a zamiast niego używany jest umask zdefiniowany przez użytkownika. Zmiany w nie /etc/profilewpłynęły na wynik, chyba że użytkownik jawnie pozyska te zmiany w plikach init.

W tym momencie nie jest jasne, czy takie zachowanie występuje we wszystkich dystrybucjach.

Mogę zasugerować wypróbowanie 2 rzeczy:

1. pam_umask
2. Opakowanie LD_PRELOAD (samozapisane?)

Oto rozwiązanie, które pozwoli Ci robić to, co chcesz dla poszczególnych użytkowników. Używa tylko natywnych sshdfunkcji i nie wymaga chowania z lokalnie obsługiwanymi łatami. To rozwiązanie wykorzystuje ForceCommandzachowanie sshd do wstawienia skryptu konfiguracji środowiska do każdego połączenia ssh, a następnie uruchomienia oryginalnej komendy.

Najpierw utwórz skrypt w systemie z następującą zawartością:

#!/bin/sh

umask 0027
exec /bin/sh -c "${SSH_ORIGINAL_COMMAND:-$SHELL}"

Na potrzeby tego przykładu założę, że to nazwałeś /usr/bin/umask-wrapper.

Teraz masz kilka opcji konfiguracji. Jeśli chcesz, aby była to obowiązkowa konfiguracja dla wszystkich użytkowników (co wydaje się mało prawdopodobne), możesz zmodyfikować konfigurację sshd, aby uwzględnić:

ForceCommand /usr/bin/umask-wrapper

Jeśli chcesz, aby dotyczyło to tylko niektórych użytkowników, możesz użyć Matchbloku (na końcu Twojego sshd_config):

Match User user1,user2
ForceCommand /usr/bin/umask-wrapper

Jeśli chcesz, aby było to zachowanie kontrolowane przez użytkownika, możesz użyć command=opcji w authorized_keypliku, aby wybrać to zachowanie dla określonych kluczy. Na przykład podczas testowania tego dodałem wpis do mojego authorized_keyspliku, który wygląda mniej więcej tak:

command="/home/lars/bin/umask-wrapper" ssh-rsa AAAAB3NzaC1 ... umask-test

A oto niektóre wyniki mojego testu:

Używanie sshbez polecenia:

localhost$ ssh remotehost
remotehost$ touch umask-test/file1
remotehost$ ls -l umask-test/file1
-rw-r-----. 1 lars lars 0 Feb  2 06:02 file1

Używanie sshz poleceniem:

localhost$ ssh remotehost touch umask-test/file2
localhost$ ssh remotehost ls -l umask-test/file2
-rw-r-----. 1 lars lars 0 Feb  2 06:03 file2

Używanie scp:

localhost$ touch file3
localhost$ ls -l file3
-rw-r--r--  1 lars  staff  0 Feb  2 06:03 file3
localhost$ scp file3 remotehost:umask-test/file3
localhost$ ssh remotehost ls -l umask-test/file3
-rw-r-----. 1 lars lars 0 Feb  2 06:03 file3

Używanie sftp:

localhost$ sftp remotehost
sftp> put file3 umask-test/file4
sftp> ls -l umask-test/file4
-rw-r-----    0 500      500             0 Feb  2 06:05 umask-test/file4

I masz to. Wierzę, że takiego zachowania się szukałeś. Jeśli masz pytania dotyczące tego rozwiązania, chętnie udzielę dodatkowych informacji.

Przyjęłam nieco inne podejście do scentralizowania tego ustawienia.

Zostało to dodane do /etc/pam.d/common-session:

session    optional     pam_umask.so

Zostało to zmodyfikowane w /etc/login.defs:

UMASK           0027

Mam pam_umask do pracy z ssh, ale nie z scp lub sftp.

Metoda otoki również nie robi nic dla sftp ani scp. Nie jestem pewien, czy 027 jest dobrym przykładem, ponieważ większość dystrybucji ma już ustawione na to umask. Spróbuj z 002 i sprawdź, czy to działa.

Programy, które nie ustawiają własnego umask, dziedziczą umask aplikacji, która go uruchomiła. Zatrzymaj sshd całkowicie, ustaw swój umask na 0027, a następnie uruchom go ponownie. (Możesz dodać komendę umask w skrypcie init do przyszłych restartów.)

Testowany do pracy z scp.

Jeśli pam_umaskwydaje się, że nie wpływa to na sesje SFTP, sprawdź, czy w pliku UsePamjest ustawiona opcja Yesna /etc/ssh/sshd_config.

Jeśli wyłączyłeś uwierzytelnianie hasłem i UsePamzostało ustawione lub ustawione domyślnie na No. Możesz ustawić ChallengeResponseAuthentication Now sshd_configpliku, ponieważ w przeciwnym razie może przypadkowo włączyć uwierzytelnianie haseł za pomocą tego systemu.

Dodano uwagę do powyższej odpowiedzi user188737:

To może być oczywiste, ale jeśli nie używasz pakietu openssh-server i ręcznie skompilowałeś OpenSSH, upewnij się, że „Włącz obsługę PAM”, przekazując --with-pamflagę konfiguracji.

W przeciwnym razie UsePAM=yesw sshd_config plus wszelkie zmiany /etc/pam.d/*zostaną skutecznie zignorowane przez sshd.

W końcu dotarło do mnie, dlaczego żadne z zalecanych rozwiązań PAM nie miało żadnego wpływu na testowanie za pośrednictwem nieinteraktywnych połączeń SFTP ...

Ponieważ umask jest dziedziczony z procesu nadrzędnego, w systemie Slackware, który używa /etc/rc.d/rc.sshddo uruchamiania / zatrzymywania / restartowania sshd, możesz po prostu umieścić umask 0027sam wiersz bezpośrednio nad „sshd_start” lub „sshd_restart” lub alternatywnie w dowolnym momencie przed rozpoczyna się główna sekcja wykonawcza w /etc/rc.d/rc.sshd:

case "$1" in
'start')
  umask 0027
  sshd_start
  ;;
'stop')
  sshd_stop
  ;;
'restart')
  umask 0027
  sshd_restart
  ;;
*)

Lub alternatywnie na górze pliku:

#!/bin/sh
# Start/stop/restart the secure shell server:
umask 0027

Właśnie przetestowałem możliwe ulepszenie opcji sshd_config larsks na solaris 11

Skonfiguruj grupę z użytkownikami do zarządzania i przenieś skrypt do samego pliku konfiguracyjnego, w moim przypadku chciałem ustawić umask na 0002.

wynikowa konfiguracja staje się ....

Match Group managedgroup
ForceCommand /bin/sh -c 'umask 0002; ${SSH_ORIGINAL_COMMAND:-$SHELL}'

Walczyłem z tym problemem, w szczególności z uprawnieniami do pliku po skopiowaniu pliku za pomocą scp , i w końcu przyszło mi do głowy, aby po prostu użyć ssh do zmiany uprawnień po skopiowaniu.

Oto rozwiązanie:

1. Skopiuj plik: localhost$ scp filename remotehost:umask-test/filename
2. Napraw uprawnienie: localhost$ ssh remotehost "chmod go+r umask-test/filename"

Najlepsze jest to, że nie jest wymagany dostęp do konta root, aby zastosować to rozwiązanie.