Posso sugerir tentar duas coisas:
- pam_umask
- Wrapper LD_PRELOAD (autogravado?)
Estou procurando uma maneira de configurar o umask do OpenSSH para 0027 de maneira consistente em todos os tipos de conexão.
Por tipos de conexão, estou me referindo a:
A diferença entre 3. e 4. é que o primeiro inicia um shell que normalmente lê as informações de /etc/profile enquanto o último não.
Além disso, leia este post I Tomei conhecimento da opção -u que está presente em versões mais recentes do OpenSSH. No entanto, isso não funciona.
Também devo adicionar que /etc/profile agora inclui umask 0027 .
Indo ponto por ponto:
-u 0027 em sshd_config como mencionado aqui , não é suficiente. Se eu não definir esse parâmetro, o sftp usará por padrão umask 0022 . Isso significa que, se eu tiver os dois arquivos:
-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
Quando eu uso o sftp para colocá-los na máquina de destino, eu realmente obtenho:
-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
No entanto, quando eu defino -u 0027 em sshd_config da máquina de destino, na verdade, obtenho:
-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
que não é esperado, já que deve ser:
-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
Alguém entende por que isso acontece?
scp - Independentemente do que é configurado para sftp , as permissões são sempre umask 0022 . Atualmente, não tenho ideia de como alterar isso.
ssh hostname - não há problema aqui, pois o shell lê /etc/profile por padrão, o que significa umask 0027 na configuração atual.
ssh nome do host programa - mesma situação que o scp .
Resumindo, definir umask em sftp altera o resultado, mas não como deveria, ssh hostname funciona como esperado lendo /etc/profile e ambos scp e ssh hostname program parecem ter umask 0022 codificado em algum lugar.
Qualquer informação sobre qualquer um dos pontos acima é bem-vinda.
EDIT: Eu gostaria de evitar os patches que requerem a compilação manual do openssh. O sistema está executando o Ubuntu Server 10.04.01 (lucid) LTS com openssh packages do maverick.
Resposta: Como indicado por poige, usar pam_umask resolveu o problema.
As mudanças exatas foram:
Linhas adicionadas a /etc/pam.d/sshd :
# Setting UMASK for all ssh based connections (ssh, sftp, scp)
session optional pam_umask.so umask=0027
Além disso, para afetar todos os shells de login, independentemente de eles terem ou não /etc/profile , as mesmas linhas também foram adicionadas a /etc/pam.d/login .
EDIT : Depois de alguns comentários, retestei esta questão.
Pelo menos no Ubuntu (onde eu testei) parece que se o usuário tem um conjunto de umask diferente em seus arquivos init do shell (.bashrc, .zshrc, ...), o umask do PAM é ignorado e o umask definido pelo usuário usado em vez disso. As alterações em /etc/profile não afetaram o resultado, a menos que o usuário forneça explicitamente essas alterações nos arquivos init.
Não está claro se esse comportamento acontece em todas as distros.
Posso sugerir tentar duas coisas:
Aqui está uma solução que permitirá que você faça o que quiser por usuário. Ele usa apenas recursos nativos do sshd e não exige que os patches sejam mantidos localmente. Essa solução aproveita o comportamento ForceCommand do sshd para inserir um script de configuração do ambiente em cada conexão ssh e, em seguida, executa o comando original.
Primeiro, crie um script em algum lugar do seu sistema com o seguinte conteúdo:
#!/bin/sh
umask 0027
exec /bin/sh -c "${SSH_ORIGINAL_COMMAND:-$SHELL}"
Para os fins deste exemplo, suponho que você tenha chamado isso /usr/bin/umask-wrapper .
Agora, você tem algumas opções para configurar isso. Se você quer que esta seja uma configuração obrigatória para todos os usuários (o que parece um pouco improvável), você pode modificar sua configuração do sshd para incluir o seguinte:
ForceCommand /usr/bin/umask-wrapper
Se você quiser que isso se aplique apenas a alguns usuários, use um bloco Match (isso será no final do seu sshd_config ):
Match User user1,user2
ForceCommand /usr/bin/umask-wrapper
Se você quiser que isso seja um comportamento controlável pelo usuário, use a opção command= em um arquivo authorized_key para selecionar esse comportamento para chaves específicas. Por exemplo, ao testar isso, adicionei uma entrada ao meu arquivo authorized_keys que se parece com isso:
command="/home/lars/bin/umask-wrapper" ssh-rsa AAAAB3NzaC1 ... umask-test
E aqui estão alguns resultados do meu teste:
Usando ssh sem comando:
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
Usando ssh com um comando:
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
Usando 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
Usando 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
E você tem isso. Eu acredito que este é o comportamento que você estava procurando. Se você tiver alguma dúvida sobre essa solução, terei prazer em fornecer detalhes adicionais.
Adotei uma abordagem ligeiramente diferente para centralizar a configuração.
Isso foi adicionado a /etc/pam.d/common-session :
session optional pam_umask.so
Isso foi modificado em /etc/login.defs :
UMASK 0027
Eu consegui pam_umask para trabalhar com ssh, mas não com scp ou sftp.
O método wrapper também não faz nada para sftp ou scp. Eu não tenho certeza se 027 é um bom exemplo, já que a maioria das distros tem umask configurada para isso já. Tente com 002 e veja se isso funciona.
Programas que não definem sua própria umask herdam o umask do aplicativo que o iniciou. Pare o sshd completamente, defina sua umask para 0027 e, em seguida, inicie-o novamente. (Você pode adicionar o comando umask no script init para reinicializações futuras.)
Testado para trabalhar com scp.
Se pam_umask não parece afetar suas sessões de SFTP, verifique se UsePam está definido como Yes no arquivo /etc/ssh/sshd_config .
Se você desativou a autenticação de senha e UsePam foi definido ou padronizado como No . Você pode querer definir ChallengeResponseAuthentication No no arquivo sshd_config , porque senão você pode habilitar inadvertidamente uma autenticação por senha através desse sistema.
Uma nota adicionada à resposta de user188737 acima:
Isso pode ser desnecessário, mas se você não estiver usando o pacote openssh-server , e tiver manualmente compilado o OpenSSH, certifique-se você "Ativar suporte do PAM" passando o sinalizador de configuração --with-pam .
Caso contrário, UsePAM=yes em sshd_config, além de quaisquer alterações em /etc/pam.d/* , serão efetivamente ignoradas por sshd .
Por fim, ficou claro para mim por que nenhuma das soluções PAM recomendadas estava tendo nenhum teste de efeito via conexões SFTP não interativas ...
Como umask é herdada do processo pai, em um sistema Slackware que usa /etc/rc.d/rc.sshd para iniciar / parar / reiniciar o sshd, você pode simplesmente colocar umask 0027 em uma linha sozinha acima de "sshd_start" ou "sshd_restart" ou, alternativamente, em qualquer ponto antes da seção de execução principal começar, em /etc/rc.d/rc.sshd :
case "$1" in
'start')
umask 0027
sshd_start
;;
'stop')
sshd_stop
;;
'restart')
umask 0027
sshd_restart
;;
*)
Ou, alternativamente, na parte superior do arquivo:
#!/bin/sh
# Start/stop/restart the secure shell server:
umask 0027
Acabei de testar uma possível melhoria para as opções do larsks sshd_config no solaris 11
Configure um grupo com os usuários a serem gerenciados e mova o script para o arquivo de configuração em si, no meu caso eu queria definir o umask para 0002.
a configuração resultante se torna ....
Match Group managedgroup
ForceCommand /bin/sh -c 'umask 0002; ${SSH_ORIGINAL_COMMAND:-$SHELL}'
Eu tenho lutado com esse problema, especificamente com permissões de arquivo depois de copiar um arquivo usando scp , e finalmente me ocorreu simplesmente usar o ssh para alterar as permissões após a cópia.
Aqui está a solução:
localhost$ scp filename remotehost:umask-test/filename
localhost$ ssh remotehost "chmod go+r umask-test/filename"
Melhor de tudo, não é necessário acesso root para efetuar esta solução.