Como configurar umask do ssh para todos os tipos de conexões

Eu estive procurando uma maneira de configurar o OpenSSH umask para 0027de uma forma consistente em todos os tipos de conexão.

Por tipos de conexão que estou me referindo:

1. sftp
2. scp
3. ssh hostname
4. programa ssh hostname

A diferença entre 3. e 4. é que o primeiro inicia um shell que geralmente lê as /etc/profileinformações enquanto o segundo não.

Além disso, lendo este post , tomei conhecimento da opção -u que está presente nas versões mais recentes do OpenSSH. No entanto, isso não funciona.

Devo também acrescentar que /etc/profileagora inclui umask 0027.

Indo ponto a ponto:

• sftp - Definir -u 0027em sshd_configcomo 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 uso o sftp para colocá-los na máquina de destino, recebo:

-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 definir -u 0027sobre sshd_configda máquina de destino eu realmente começar:

-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

o que não é esperado, já que deveria 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 está configurado para sftp , as permissões são sempre umask 0022. Atualmente, não tenho idéia de como alterar isso.

• ssh hostname - não há problema aqui, pois o shell lê /etc/profilepor padrão, o que significa umask 0027na configuração atual.

• programa ssh hostname - mesma situação que scp .

Em suma, definir umask sftpaltera o resultado, mas não como deveria, ssh hostnamefunciona como a leitura esperada /etc/profilee ambos scpe ssh hostname programparece ter umask 0022codificado em algum lugar.

Qualquer visão sobre qualquer um dos pontos acima é bem-vinda.

EDIT: Eu gostaria de evitar patches que exigem compilação manual do openssh. O sistema está executando o Ubuntu Server 10.04.01 (lucid) LTS com opensshpacotes da maverick.

Resposta: Conforme indicado por poige, usar pam_umask fez o truque.

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 serem de origem /etc/profileou não, as mesmas linhas também foram adicionadas /etc/pam.d/login.

Edição : Depois de alguns dos comentários retestei este problema.

Pelo menos no Ubuntu (onde eu testei), parece que se o usuário tiver um umask diferente definido nos arquivos init do shell (.bashrc, .zshrc, ...), o umask do PAM será ignorado e o usuário definido como umask. Alterações no não /etc/profileafetaram o resultado, a menos que o usuário explique explicitamente essas alterações nos arquivos init.

Não está claro neste momento se esse comportamento ocorre em todas as distros.

Eu posso sugerir tentar duas coisas:

1. pam_umask
2. Wrapper LD_PRELOAD (auto-gravado?)

Aqui está uma solução que permitirá que você faça o que deseja, por usuário. Ele usa apenas sshdrecursos nativos e não requer mexer com patches mantidos localmente. Esta solução tira proveito do ForceCommandcomportamento do sshd para inserir um script de configuração do ambiente em todas as conexões ssh e, em seguida, execute 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, assumirei que você chamou isso /usr/bin/umask-wrapper.

Agora, você tem algumas opções para configurar isso. Se você deseja que essa seja uma configuração obrigatória para todos os usuários (o que parece um pouco improvável), você pode modificar sua configuração sshd para incluir o seguinte:

ForceCommand /usr/bin/umask-wrapper

Se você deseja que isso se aplique apenas a alguns usuários, você pode usar um Matchbloco (isso ocorre no final do seu sshd_config):

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

Se você deseja que esse seja um comportamento controlável pelo usuário, você pode usar a command=opção em um authorized_keyarquivo para selecionar esse comportamento para chaves específicas. Por exemplo, ao testar isso, adicionei uma entrada ao meu authorized_keysarquivo 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 sshsem 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 sshcom 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 aí está. Acredito que esse é o comportamento que você estava procurando. Se você tiver alguma dúvida sobre esta solução, ficarei feliz em fornecer detalhes adicionais.

Adotei uma abordagem um pouco 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

Consegui que o pam_umask trabalhasse com ssh, mas não com scp ou sftp.

O método wrapper também não faz nada para sftp ou scp. Não sei se 027 é um bom exemplo, já que a maioria das distros já possui umask configurada para isso. Tente com 002 e veja se isso funciona.

Os programas que não definem suas próprias umask herdam a umask do aplicativo que o iniciou. Pare o sshd completamente, defina seu umask como 0027 e inicie-o novamente. (Você pode adicionar o comando umask no script init para futuras reinicializações.)

Testado para trabalhar com scp.

Se pam_umaskisso não parece afetar suas sessões de SFTP, verifique se UsePamestá definido Yesno /etc/ssh/sshd_configarquivo.

Se você desativou a autenticação por senha e UsePamfoi definido ou o padrão No. Você pode definir ChallengeResponseAuthentication Noo sshd_configarquivo porque, caso contrário, poderá ativar inadvertidamente uma autenticação de senha através desse sistema.

Uma observação adicionada à resposta do usuário188737 acima:

Isso pode ser desnecessário, mas se você não estiver usando o pacote openssh-server e tiver compilado manualmente o OpenSSH, certifique-se de "Ativar suporte ao PAM" passando o --with-pamsinalizador de configuração.

Caso contrário, UsePAM=yesem sshd_config, mais as alterações /etc/pam.d/*serão efetivamente ignoradas sshd.

Finalmente me ocorreu por que nenhuma das soluções PAM recomendadas estava tendo algum teste de afetação por meio de conexões SFTP não interativas ...

Como umask é herdada do processo pai, em um sistema Slackware usado /etc/rc.d/rc.sshdpara iniciar / parar / reiniciar o sshd, você pode simplesmente colocar umask 0027uma linha sozinha diretamente acima de "sshd_start" ou "sshd_restart" ou, alternativamente, a qualquer momento antes do A seção principal de execução começa, em /etc/rc.d/rc.sshd:

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

Ou, como alternativa, na parte superior do arquivo:

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

Acabei de testar uma possível melhoria nas opções de larsks sshd_config no solaris 11

Configure um grupo com os usuários a serem gerenciados e mova o script para o próprio arquivo de configuração. No meu caso, eu queria definir o umask como 0002.

a configuração resultante se torna ....

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

Estou enfrentando problemas com esse problema, especificamente com permissões de arquivo após copiar um arquivo usando o scp , e finalmente me ocorreu simplesmente usar o ssh para alterar as permissões após a cópia.

Aqui está a solução:

1. Copie seu arquivo: localhost$ scp filename remotehost:umask-test/filename
2. Corrigir permissão: localhost$ ssh remotehost "chmod go+r umask-test/filename"

O melhor de tudo é que nenhum acesso root é necessário para efetivar esta solução.