Consenti SCP ma non effettivo login utilizzando SSH

C'è un modo per configurare un utente in una casella Linux (Centos 5.2 in questo caso) in modo che possano utilizzare scp per recuperare i file, ma non possono effettivamente accedere al server utilizzando SSH?

  • Tunnel di inversione SSH affidabile
  • Come posso trovare la versione corrente del protocollo ssh della connessione corrente?
  • come impostare ENABLE_CLEAR_REFERENCES in GlassFish 3.1.1?
  • Eliminare le directory ricorsive con il command FTP su Bash
  • SSH Connection ha rifiutato
  • Come posso elencare tutti gli utenti con root?
  • Utilizzare il riepilogo di return o return in Subversion commit dalla row di command
  • Bash: eseguire un eseguibile che fornisce un buon stato di output
  • Come faccio a installare Wireshark in Red Hat Linux?
  • Memoria misteriosa in Linux
  • "Host virtuali" per SSH
  • Utilizzare casi per avere priorità di process diverse per CPU e IO?
  • 9 Solutions collect form web for “Consenti SCP ma non effettivo login utilizzando SSH”

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

    Poiché RHEL / CentOS 5.2 non include un pacchetto per rssh, si può guardare qui per get un RPM: http://dag.wieers.com/rpm/packages/rssh/

    Per usarla è sufficiente impostarla come shell per un nuovo utente come questo:

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

    .. o cambiare la shell per un esistente come questo:

     chsh -s /usr/bin/rssh scpuser1 

    .. e modificare /etc/rssh.conf per configurare la shell rssh – in particolare la linea allowscp per abilitare l'accesso SCP per tutti gli utenti rssh.

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

    Sono molto tardi a questo ma potresti usare le chiavi ssh e specificare il command esatto consentito nel loro file ~ / .ssh / authorized_keys

    no-port-forwarding, no-pty, command = "scap source target" ssh-dss …

    Potrebbe essere necessario utilizzare ps per l'objective per impostare le impostazioni di command corrette.

    PS: Se si esegue un command scp test con "-v" puoi vedere qualcosa di simile

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

    Notenetworking che "-t" è un'opzione scp non documentata, utilizzata dal programma all'estremità opposta. Questo ti dà l'idea di ciò che ti serve per mettere in keys_authenticated.

    EDIT: Potete trovare ulteriori informazioni (con diversi collegamenti) in questa domanda di StackOverflow .

    Ecco un esempio di lavoro per questo, per un utente denominato backup_user sul lato server.

    ~backup_user/.ssh/authorized_keys sul lato server (con alcune 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 collegamento in ~ backup_user / che collega alla directory in cui il contenuto deve essere accessibile.

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

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

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

    Che cosa fa questo command:

    • Visualizza informazioni dettagliate ( optionnal : è ansible rimuovere il -v da entrambi i file di command e authorized_keys)
    • Copia ricorsivamente il contenuto del path / dati. ( opzionale : è ansible rimuovere -r da entrambi i comandi e il file autorizzato_keys se non si desidera eseguire una copia ricorsiva)
    • Utilizza la port 2222 per connettersi al server ( optionnal : è ansible rimuovere -P 2222 dal command)
    • Utilizza e file di identity framework; per automatizzare la connessione ( optionnal : è ansible rimuovere -i .ssh/id_rsa_key_file
    • Il contenuto del path/to/data verrà 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 di shell che gestisce questo come descritto qui

    Sono un po 'tardi per la festa, tuttavia vi suggerisco di dare un'occhiata alla direttiva ForceCommand di OpenSSH.

     Subsystem sftp internal-sftp Match group sftponly ForceCommand internal-sftp 

    Certo, questo è SFTP e non SCP, ma raggiunge lo stesso objective, più sicuro che con una shell limitata. Inoltre, è ansible chroot l'utente se si desidera.

    Consiglierei di usare sconnesso.

    È una shell limitata che consente agli utenti di fare proprio ciò che suona come file SCP al server, ma non effettivamente accedere. I download di informazioni e di codice di origine per il software sono disponibili qui e i pacchetti RPM precompilati sono disponibili tramite Reparti di EPEL YUM .

    Una volta installata, è necessario configurare each account utente che desideri limitare l'accesso a, per utilizzare la shell limitata appena installata. Puoi farlo manualmente tramite / etc / passwd o utilizzare il seguente command: usermod -s /usr/bin/scponly USERNAME

    Io uso MySecureShell per farlo. È ansible configurare anche altre restrizioni.

    https://github.com/mysecureshell/mysecureshell

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

    Molto tardi per la festa, ma solo impostare il guscio dell'utilizzatore git per essere / usr / bin / git-shell. È una shell limitata che non consente l'accesso interattivo. È ancora ansible accedere all'utente con 'su -s / bin / bash git' o qualunque sia il tuo username del git.

    Utilizziamo una shell psudo chiamata scponly nei nostri server ftp protetti per gli utenti che vogliamo solo essere in grado di scp ma non accedere.

    Ho trovato un modo piacevole è usare la funzionalità command = "…" del file authorized_keys. (Suggerito da questa pagina )

    Il command da eseguire sarebbe quello che esegue test per 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 

    Suppongo che probabilmente avresti ancora bisogno di proteggere il file autorizzato_key di utente, ma il mio scopo era quello di disporre di una chiave senza password che potrei utilizzare per i backup, senza wherer creare un utente completamente nuovo e non avere la chiave a dare un shell (ok, facilmente)

    La sua non è la soluzione più graziosa, ma potreste gettare qualcosa di simile negli utenti .bashrc

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

    Ho scoperto che gli utenti di SCP ricevono un TERM di "muto" e altri in genere ricevono vt100.

    Immagino che l'utente potrebbe probabilmente scp su un nuovo .bashrc, che rende questa non la soluzione migliore, ma per una soluzione veloce e sporca, questo functionrà

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.