Consenti SCP ma accesso non effettivo tramite SSH

Esiste un modo per configurare un utente su un box Linux (Centos 5.2 in questo caso) in modo che possano usare scp per recuperare i file, ma in realtà non possono accedere al server usando SSH?

rssh shell ( http://pizzashack.org/rssh/ ) è progettato proprio per questo scopo.

Poiché RHEL / CentOS 5.2 non include un pacchetto per rssh, è possibile cercare qui per ottenere un RPM: http://dag.wieers.com/rpm/packages/rssh/

Per usarlo basta impostarlo come shell per un nuovo utente come questo:

useradd -m -d /home/scpuser1 -s /usr/bin/rssh scpuser1
passwd scpuser1

..o cambia la shell per una esistente come questa:

chsh -s /usr/bin/rssh scpuser1

..e modifica /etc/rssh.confper configurare la shell rssh, in particolare la allowscpriga di commento per abilitare l'accesso SCP a tutti gli utenti rssh.

(Puoi anche usare chroot per mantenere gli utenti contenuti nelle loro case, ma questa è un'altra storia.)

Sono in ritardo, ma potresti usare le chiavi ssh e specificare il comando esatto consentito nel loro file ~ / .ssh / authorized_keys, ad es.

no-port-forwarding, no-pty, command = "destinazione sorgente scp" ssh-dss ...

Potrebbe essere necessario utilizzare ps su sul target per configurare le giuste impostazioni di comando.

PS: Se esegui un comando test scp con "-v" puoi vedere qualcosa del genere

debug1: Sending command: scp -v -t myfile.txt

Noterai che "-t" è un'opzione scp non documentata, usata dal programma dall'altra parte. Questo ti dà l'idea di ciò che devi mettere in authorized_keys.

EDIT: è possibile trovare ulteriori informazioni (con diversi collegamenti) in questa domanda StackOverflow .

Ecco un esempio funzionante di questo, per un utente chiamato backup_usersul lato server.

~backup_user/.ssh/authorized_keys contenuto sul lato server (con alcune ulteriori restrizioni di sicurezza):

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -v -r -d -t ~/CONTENT" ssh-rsa AAAAMYRSAKEY...

Crea un link in ~ backup_user / che colleghi alla directory in cui il contenuto dovrebbe essere accessibile.

$ ln -s /path/to/directory/with/accessible/content ~backup_user/CONTENT

Ora, dal lato client, dovrebbe funzionare il seguente comando:

scp -v  -r  -P 2222 -i .ssh/id_rsa_key_file path/to/data backup_user@SERVER:~/CONTENT

Cosa fa questo comando:

• Visualizza informazioni dettagliate ( opzionale : puoi rimuovere -vsia il comando sia il file authorized_keys)
• Copia in modo ricorsivo il contenuto del percorso / in / dati. ( opzionale : puoi rimuovere -rsia dal comando sia dal file authorized_keys se non vuoi fare una copia ricorsiva)
• Utilizza la porta 2222 per connettersi al server ( opzionale : è possibile rimuovere -P 2222dal comando)
• Utilizza e file di identità per automatizzare la connessione ( opzionale : è possibile rimuovere-i .ssh/id_rsa_key_file
• Il contenuto di path/to/dataverrà copiato in/path/to/directory/with/accessible/content/

Per creare una copia di un file (o più) dal server al client, è necessario creare uno script shell che gestisca questo come descritto qui

Sono un po 'in ritardo alla festa, tuttavia ti suggerirò di dare un'occhiata alla ForceCommanddirettiva di OpenSSH.

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp

Certo, questo è SFTP e non SCP, ma raggiunge lo stesso obiettivo, in modo più sicuro rispetto a una shell con restrizioni. Inoltre, puoi chroot l'utente se lo desideri.

Consiglierei di usare scponly.

È una shell limitata che consente agli utenti di fare esattamente ciò che sembra, i file SCP sul server, ma in realtà non effettuano l'accesso. I download di informazioni e codice sorgente per il software sono disponibili qui e i pacchetti RPM precompilati sono disponibili tramite Archivi EPEL YUM .

Una volta installato, sarà necessario configurare ciascun account utente, al quale si desidera limitare l'accesso, per utilizzare la shell con restrizioni appena installata. Puoi farlo manualmente tramite / etc / passwd o usare il seguente comando: usermod -s /usr/bin/scponly USERNAME

Per fare questo uso MySecureShell. Puoi configurare anche altre restrizioni.

https://github.com/mysecureshell/mysecureshell

Limita solo le connessioni a SFTP / SCP. Nessun accesso alla shell.

Molto tardi alla festa, ma basta impostare la shell dell'utente git su / usr / bin / git-shell. È una shell con restrizioni che non consente l'accesso interattivo. Puoi comunque fare richiesta all'utente con 'su -s / bin / bash git' o qualunque sia il tuo nome utente git.

Usiamo una shell psudo chiamata scponly sui nostri server ftp sicuri per gli utenti che vogliamo solo poter scpare i file ma non accedere.

Ho trovato un modo carino è usare la funzione command = "..." del file authorized_keys. (Mi è stato suggerito da questa pagina )

Il comando che avresti eseguito sarebbe quello che verifica gli argomenti che iniziano con scp (e rsync).

Ecco il file authorized_keys:

# authorized_keys
command="/usr/local/bin/remote-cmd.sh" ssh-rsa.....== user@pewpew

Ecco il contenuto di remote-cmd.sh:

#!/bin/bash
# /usr/local/bin/remote-cmd.sh
case $SSH_ORIGINAL_COMMAND in
 'scp'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 'rsync'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 *)
    echo "Access Denied"
    ;;
esac

Immagino che probabilmente avresti ancora bisogno di proteggere il file authorized_keys dell'utente, ma il mio scopo era di avere una chiave senza password che avrei potuto usare per i backup, senza dover creare un nuovo utente e avere la chiave per non fornire una shell (ok, facilmente)

Cambia la shell di login dell'utente in qualcosa di restrittivo, che consente all'utente di eseguire solo scp , sftp-server e solo rsync e verifica inoltre che non siano consentiti argomenti non sicuri (ad esempio scp -S ... e rsync -e .. . sono sicuri, vedere qui: http://exploit-db.com/exploits/24795 ). Esempio per tale shell di accesso restrittiva:

• rssh
• scponly (non solo scp, consente anche sftp, svn ecc. se configurato in questo modo)
• transfer_shell

Potresti voler eseguire uno di questi in un chroot o in un altro ambiente limitato (ad esempio nsjail su Linux), per disabilitare l'accesso alla rete e per un controllo più semplice (autorizzato) di quali directory possono essere lette e / o scritte.

Non consiglio di utilizzarlo command="..."in ~/.ssh/authorized_keys, perché senza un'attenta protezione aggiuntiva (come chmod -R u-w ~per l'utente) un utente malintenzionato può caricare una nuova versione di ~/.ssh/authorized_keys, ~/.ssh/rco ~/.bashrc, e quindi può includere ed eseguire comandi arbitrari.

Non è la soluzione più elegante, ma potresti lanciare qualcosa del genere negli utenti .bashrc

if [ "$TERM"  != "dumb" ]; then
  exit
fi

Ho scoperto che gli utenti di SCP ottengono un termine "stupido", e altri in genere ottengono vt100.

Immagino che l'utente potrebbe probabilmente scavare su un nuovo .bashrc, il che rende questa non la soluzione migliore, ma per una soluzione rapida e sporca, funzionerà