Come configurare umask di ssh per tutti i tipi di connessioni

Sono stato alla ricerca di un modo per impostare di OpenSSH umask a 0027in modo coerente in tutti i tipi di connessione.

Per tipi di connessione mi riferisco a:

1. sftp
2. SCP
3. nome host ssh
4. programma hostname ssh

La differenza tra 3. e 4. è che il primo avvia una shell che di solito legge le /etc/profileinformazioni mentre il secondo no.

Inoltre leggendo questo post mi sono reso conto dell'opzione -u presente nelle versioni più recenti di OpenSSH. Tuttavia questo non funziona.

Devo anche aggiungere che /etc/profileora include umask 0027.

Andando punto per punto:

• sftp - Impostazione -u 0027in sshd_configcome detto qui , non è sufficiente.

Se non imposto questo parametro, sftp usa di default umask 0022. Ciò significa che se ho i due file:

-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 sftp per inserirli nella macchina di destinazione ottengo effettivamente:

-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

Tuttavia quando accendo -u 0027il sshd_configcomputer di destinazione ottengo effettivamente:

-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

che non è previsto, dal momento che dovrebbe essere effettivamente:

-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

Qualcuno capisce perché questo accade?

• scp : indipendentemente dalle impostazioni di sftp , le autorizzazioni sono sempre umask 0022. Al momento non ho idea di come modificare questo.

• nome host ssh - nessun problema qui poiché la shell legge /etc/profileper impostazione predefinita, il che significa che umask 0027nella configurazione corrente.

• programma hostname ssh - stessa situazione di scp .

In breve, l'impostazione di umask su sftpaltera il risultato ma non come dovrebbe, ssh hostnamefunziona come la lettura prevista /etc/profileed entrambi scpe ssh hostname programsembra aver umask 0022codificato da qualche parte.

Qualsiasi approfondimento su uno dei punti di cui sopra è il benvenuto.

EDIT: Vorrei evitare le patch che richiedono la compilazione manuale di openssh. Il sistema esegue Ubuntu Server 10.04.01 (lucido) LTS con opensshpacchetti di Maverick.

Risposta: Come indicato da Poige, usare pam_umask ha fatto il trucco.

Le modifiche esatte sono state:

Linee aggiunte a /etc/pam.d/sshd:

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

Inoltre, al fine di influire su tutte le shell di login indipendentemente dal fatto che siano di origine /etc/profileo meno, sono state aggiunte anche le stesse linee /etc/pam.d/login.

EDIT : dopo alcuni dei commenti ho riprovato questo problema.

Almeno in Ubuntu (dove ho testato) sembra che se l'utente ha un set di umask diverso nei file init della sua shell (.bashrc, .zshrc, ...), l'umask PAM viene ignorato e viene usato l'utente definito dall'utente. Le modifiche apportate /etc/profilenon hanno influito sul risultato a meno che l'utente non abbia esplicitamente fornito tali modifiche nei file init.

Non è chiaro a questo punto se questo comportamento si verifica in tutte le distro.

Posso suggerire di provare 2 cose:

1. pam_umask
2. Wrapper LD_PRELOAD (scritto da solo?)

Ecco una soluzione che ti consentirà di fare ciò che desideri in base all'utente. Utilizza solo sshdfunzionalità native e non richiede confusione con le patch gestite localmente. Questa soluzione sfrutta il ForceCommandcomportamento di sshd per inserire uno script di installazione dell'ambiente in ogni connessione ssh e quindi eseguire il comando originale.

Innanzitutto, crea uno script da qualche parte sul tuo sistema con i seguenti contenuti:

#!/bin/sh

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

Ai fini di questo esempio, suppongo che tu l'abbia chiamato /usr/bin/umask-wrapper.

Ora, hai alcune opzioni per configurarlo. Se vuoi che questa sia una configurazione obbligatoria per tutti gli utenti (che sembra un po 'improbabile), puoi modificare la tua configurazione sshd per includere quanto segue:

ForceCommand /usr/bin/umask-wrapper

Se vuoi che questo si applichi solo ad alcuni utenti, puoi usare un Matchblocco (questo va alla fine del tuo sshd_config):

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

Se si desidera che si tratti di un comportamento controllabile dall'utente, è possibile utilizzare l' command=opzione in un authorized_keyfile per selezionare questo comportamento per chiavi specifiche. Ad esempio, durante il test ho aggiunto una voce al mio authorized_keysfile che assomiglia a questo:

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

E qui ci sono alcuni risultati del mio test:

Usando sshsenza 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 sshcon un 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

Utilizzando 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

Utilizzando 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 il gioco è fatto. Credo che questo sia il comportamento che stavi cercando. In caso di domande su questa soluzione, saremo lieti di fornire ulteriori dettagli.

Ho adottato un approccio leggermente diverso per centralizzare l'impostazione.

Questo è stato aggiunto a /etc/pam.d/common-session:

session    optional     pam_umask.so

Questo è stato modificato in /etc/login.defs:

UMASK           0027

Sono riuscito a far funzionare pam_umask con ssh, ma non con scp o sftp.

Anche il metodo wrapper non fa nulla per sftp o scp. Non sono sicuro che 027 sia un buon esempio poiché la maggior parte delle distribuzioni ha già impostato umask. Prova con 002 e vedi se funziona.

I programmi che non impostano la propria umask ereditano l'umask dell'applicazione che l'ha avviata. Interrompere completamente sshd, impostare umask su 0027, quindi avviarlo nuovamente. (È possibile aggiungere il comando umask nello script init per i riavvii futuri.)

Testato per funzionare con scp.

Se pam_umasknon sembra influire sulle sessioni SFTP, controlla se UsePamè impostato su Yesnel /etc/ssh/sshd_configfile.

Se hai disabilitato l'autenticazione con password ed è UsePamstato impostato o impostato come predefinito No. È possibile che si desideri impostare ChallengeResponseAuthentication Noil sshd_configfile perché in caso contrario è possibile abilitare inavvertitamente un'autenticazione tramite password tramite quel sistema.

Una nota aggiunta alla risposta di user188737 sopra:

Ciò può essere ovvio, ma se non si utilizza il pacchetto openssh-server e si è compilato manualmente OpenSSH, assicurarsi di "Abilitare il supporto PAM" passando il --with-pamflag di configurazione.

Altrimenti, UsePAM=yesin sshd_config, oltre a qualsiasi modifica a /etc/pam.d/*verrà effettivamente ignorato sshd.

Alla fine ho capito perché nessuna delle soluzioni PAM consigliate stava avendo alcun effetto sui test tramite connessioni SFTP non interattive ...

Poiché umask è ereditato dal processo genitore, su un sistema Slackware che utilizza /etc/rc.d/rc.sshdper avviare / arrestare / riavviare sshd, è possibile semplicemente posizionarlo umask 0027su una riga da solo direttamente sopra "sshd_start" o "sshd_restart" o, in alternativa, in qualsiasi momento prima del inizia la sezione principale di esecuzione, in /etc/rc.d/rc.sshd:

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

Oppure, in alternativa, nella parte superiore del file:

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

Ho appena testato un possibile miglioramento delle opzioni di larsks sshd_config su Solaris 11

Imposta un gruppo con gli utenti da gestire e sposta lo script nel file di configurazione stesso, nel mio caso volevo impostare umask su 0002.

la configurazione risultante diventa ....

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

Ho avuto problemi con questo problema, in particolare con i permessi dei file dopo aver copiato un file usando scp , e finalmente mi è venuto in mente di usare semplicemente ssh per cambiare i permessi dopo la copia.

Ecco la soluzione:

1. Copia il tuo file: localhost$ scp filename remotehost:umask-test/filename
2. Autorizzazione correzione: localhost$ ssh remotehost "chmod go+r umask-test/filename"

Soprattutto, non è necessario l'accesso root per effettuare questa soluzione.