Una serie di programmi storici consente di eseguire delle operazioni su elaboratori remoti. I nomi di questi iniziano convenzionalmente con una lettera «r» in modo da distinguerli da programmi equivalenti che svolgono la loro funzione in ambito locale. Oltre ai programmi che richiedono l'elaborazione, nel server ci devono essere dei demoni in grado di attuare quanto richiesto.
L'esecuzione di un'elaborazione remota richiede il riconoscimento dell'utente, in modo da potere stabilire l'ambito e i privilegi in cui si deve trovarsi presso l'elaboratore remoto. Il riconoscimento può avvenire attraverso una sorta di procedura di accesso, durante il funzionamento del programma dal lato client, oppure può essere basato sulla semplice fiducia, concedendo l'accesso attraverso la preparazione di alcuni file di configurazione. Indubbiamente, la fiducia è un metodo molto poco sicuro di amministrare il proprio sistema, ma quando una rete locale è ristretta a un ambito in cui tutto è comunque sotto controllo, la richiesta di una password può essere effettivamente un fastidio inutile.
Il riconoscimento può avvenire nel modo tradizionale, attraverso i file /etc/hosts.equiv e ~/.rhosts, oppure attraverso un'autenticazione Kerberos. Quest'ultima non viene descritta.
Se si vuole concedere un accesso senza controlli particolari, si può predisporre il file /etc/hosts.equiv con un semplice elenco di nomi di nodi (o di indirizzi IP) a cui si concede l'accesso, in modo generalizzato, senza la richiesta di password. Parallelamente, o alternativamente, ogni utente può predisporre il proprio elenco di nodi e di utenti da considerare equivalenti alla propria «identità» locale, preparando il file ~/.rhosts.
Il file /etc/hosts.equiv permette di definire un elenco di nodi che deve essere trattato come equivalente a quello locale, in modo tale che gli utenti di questi nodi possano accedere attraverso l'uso di comandi remoti, e senza la richiesta di password.
L'esempio seguente mostra il contenuto del file /etc/hosts.equiv di un nodo per il quale si vuole consentire l'accesso da parte di dinkel.brot.dg e di roggen.brot.dg.
dinkel.brot.dg roggen.brot.dg |
In questo modo, gli utenti dei nodi dinkel.brot.dg e roggen.brot.dg possono accedere al sistema locale senza la richiesta formale di alcuna identificazione, purché esista per loro un'utenza con lo stesso nome.
L'elenco di nodi equivalenti può contenere anche l'indicazione di utenti particolari, per la precisione, ogni riga può contenere il nome di un nodo seguito eventualmente da uno spazio e dal nome di un utente. Si osservi l'esempio seguente:
dinkel.brot.dg roggen.brot.dg dinkel.brot.dg tizio dinkel.brot.dg caio |
Come nell'esempio precedente, viene concesso agli utenti dei nodi dinkel.brot.dg e roggen.brot.dg di accedere localmente se esistono utenze con lo stesso nome. In aggiunta a questo, però, viene concesso agli utenti tizio e caio del nodo dinkel.brot.dg, di accedere con qualunque nominativo-utente (locale), senza la richiesta di alcuna password.
|
Si può intuire che fare una cosa del genere significa concedere a tali utenti privilegi simili a quelli di |
Indipendentemente dal fatto che il file /etc/hosts.equiv sia presente o meno, ogni utente può predisporre il proprio file ~/.rhosts. La sintassi di questo file è la stessa di /etc/hosts.equiv, ma si riferisce esclusivamente all'utente che predispone tale file nella propria directory personale.
In questo file, l'indicazione di utenti precisi è utile e opportuna, perché quell'utente fisico, potrebbe essere riconosciuto con nomi differenti sui nodi da cui vuole accedere.
dinkel.brot.dg tizi roggen.brot.dg tizio |
L'esempio, mostra l'indicazione precisa di ogni nominativo-utente dei nodi che possono accedere senza richiesta di identificazione. *1*
Per motivi di sicurezza, dovrebbe essere impedito all'utente root, così come agli utenti speciali (cioè quelli corrispondenti a numeri UID particolarmente bassi), di accedere senza identificazione. Quindi, di solito, la sola configurazione del file /etc/hosts.equiv non basta a permettere l'accesso all'utente root senza che questo fornisca la password. Normalmente, è sufficiente predisporre anche il file ~root/.rhosts.
*2*
L'accesso remoto tradizionale è qualcosa di molto simile all'utilizzo di una connessione Telnet e comunque rimane la base dei programmi di utilizzo remoto. Dal lato del server occorre un demone rlogind e dal lato del client il programma rlogin.
in.rlogind [<opzioni>] |
È il demone del servizio necessario per ricevere connessioni attraverso rlogin. È gestito dal supervisore inetd e filtrato da tcpd. Nell'esempio seguente, viene mostrata la riga di /etc/inetd.conf in cui si dichiara il suo possibile utilizzo.
login stream tcp nowait root /usr/sbin/tcpd in.rlogind |
|
Permette anche all'utente root di utilizzare il file ~/.rhosts.
rlogin [<opzioni>] <host-remoto> |
Si tratta di un modo per effettuare l'accesso all'interno di un elaboratore remoto, come se ci si trovasse sulla console di questo.
|
Con questa opzione è possibile specificare già nella riga di comando il nome dell'utente da utilizzare per l'accesso nel sistema remoto. Quando ci si identifica in questo modo, viene richiesta la password in ogni caso.
|
Abilita la connessione utilizzando una comunicazione a 8 bit in modo da poter utilizzare caratteri speciali come le lettere accentate.
Una shell remota è uno strumento per eseguire un comando in un elaboratore remoto dirigendo il flusso normale di dati attraverso il programma utilizzato localmente. In pratica, per fare questo, si utilizza il demone rshd dal lato server e rsh dal lato client.
Quando si utilizza una shell remota come rsh, è importante fare mente locale alla sequenza delle operazioni che avvengono. Infatti, il comando viene interpretato inizialmente dalla shell locale che poi passa gli argomenti a rsh, il quale poi eseguirà un comando presso l'elaboratore remoto. Il problema sta quindi nel comprendere quale sia effettivamente il comando che verrà eseguito nell'elaboratore remoto, tenendo conto anche della shell che verrà utilizzata lì, per determinare il flusso di output che si ottiene (standard output e standard error), flusso che poi può essere visualizzato, ridiretto o rielaborato localmente.
in.rshd [<opzioni>] |
È il demone del servizio necessario per ricevere connessioni attraverso rsh. È gestito dal supervisore inetd e filtrato da tcpd. Nell'esempio seguente, viene mostrata la riga di /etc/inetd.conf in cui si dichiara il suo possibile utilizzo.
shell stream tcp nowait root /usr/sbin/tcpd in.rshd |
|
Permette anche all'utente root di utilizzare il file ~/.rhosts.
rsh [<opzioni>] <host-remoto> [<comando>] |
Permette di eseguire il comando richiesto nell'elaboratore remoto specificato se su quell'elaboratore è abilitata questa possibilità. Lo standard input ricevuto da rsh viene inviato allo standard input del comando remoto; lo standard output e lo standard error emessi dal comando remoto vengono ridiretti in modo che diventino rispettivamente lo standard output e lo standard error di rsh.
Questo meccanismo di ridirezione è l'elemento che rende utile questo programma e d'altra parte è anche il suo limite: non possono essere utilizzati programmi che richiedono l'interazione con l'utente, attraverso rsh.
Se rsh viene utilizzata senza l'indicazione del comando remoto, si ottiene in pratica un accesso puro e semplice, attraverso rlogin.
|
Con questa opzione è possibile specificare già nella riga di comando il nome dell'utente da utilizzare per l'accesso al sistema remoto. Quando ci si identifica in questo modo, viene richiesta la password in ogni caso.
$ rsh roggen.brot.dg cat /etc/fstab > copia-locale
Esegue il cat del file /etc/fstab dell'elaboratore roggen.brot.dg e ne dirige l'output verso il file locale copia-locale.
$ rsh roggen.brot.dg cat /etc/fstab ">" copia-remota
Questo esempio sembra molto simile al precedente, ma utilizzando il simbolo di ridirezione tra virgolette, la shell locale non lo interpreta in questo modo, ma lo lascia tra gli argomenti di rsh. Così facendo, il simbolo di ridirezione viene gestito dal comando remoto generando così il file copia-remota proprio nell'elaboratore remoto.
$ rsh roggen.brot.dg tar czf - /home/pluto > ~/pluto.tgz
Esegue l'archiviazione della directory /home/pluto/ dell'elaboratore roggen.brot.dg generando l'archivio compresso ~/pluto.tgz nell'elaboratore locale.
Un modo per copiare dati tra un elaboratore e un altro può essere quello di sfruttare un filesystem di rete. Un altro modo potrebbe essere quello di utilizzare rsh per copiare dati da un elaboratore remoto verso quello locale (viceversa è un po' difficile).
Il modo più pratico è l'utilizzo di rcp attraverso il quale si possono copiare file tra due elaboratori remoti o tra un elaboratore remoto e quello locale.
rcp si avvale di rsh, di conseguenza, dal lato server occorre il demone rshd.
rcp [<opzioni>] <origine> <destinazione> |
rcp [<opzioni>] <origine>... <directory> |
rcp copia file tra elaboratori differenti. I file o le directory indicati tra gli argomenti possono essere espressi nella forma seguente:
[[<utente>@]<host>:]<file> |
Se non viene indicato esplicitamente un utente, si intende fare riferimento a un utente remoto con lo stesso nome di quello usato localmente; se non viene indicato il nome o l'indirizzo dell'elaboratore remoto, si intende quello locale.
Quando si fa riferimento a file remoti senza l'indicazione di un percorso assoluto, occorre tenere presente che la directory corrente di un elaboratore remoto corrisponde alla directory personale dell'utente a cui si fa riferimento. Nello stesso modo, occorre tenere presente che, dal momento che rcp si avvale di rsh, le cose possono cambiare un po' a seconda del tipo di shell abbinato all'utente remoto.
|
Se all'interno dei file indicati come origine della copia, si trovano anche directory, queste vengono copiate assieme al loro contenuto, in modo ricorsivo. In tal caso, necessariamente, la destinazione deve essere una directory.
|
Preserve. Con questa opzione si intende fare in modo che rcp tenti di riprodurre le stesse proprietà e gli stessi permessi nei file di destinazione, senza tenere conto del valore della maschera dei permessi (umask). Quando questa opzione non viene indicata, nel caso in cui il file di destinazione esista già, vengono mantenuti i permessi e le proprietà di quello esistente, mentre se i file di destinazione vengono creati, si utilizzano i permessi del file originale, filtrati attraverso la maschera dei permessi.
$ rcp roggen.brot.dg:/home/tizio/letterina ./letterina
Copia il file /home/tizio/letterina contenuto nell'elaboratore roggen.brot.dg, nella directory corrente dell'elaboratore locale.
$ rcp roggen.brot.dg:\~/letterina ./letterina
Esegue un'operazione simile a quella dell'esempio precedente, ma in questo caso si utilizza un codice macro che deve essere interpretato dalla shell remota. Per evitare che venga invece interpretato dalla shell locale, viene utilizzata la barra obliqua inversa per proteggere la tilde.
---------------------------
Appunti Linux 1999.09.21 --- Copyright © 1997-1999 Daniele Giacomini -- daniele @ pluto.linux.it
1.) Si deve fare attenzione al fatto che tra il nome del nodo e il nome dell'utente, ci deve essere uno spazio.
2.) Oltre a questo problema, potrebbe essere stato impedito l'accesso da un elaboratore remoto a causa della configurazione del file /etc/securetty.