[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
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 servente ci devono essere dei demoni in grado di attuare quanto richiesto. (1)
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 trovare presso l'elaboratore remoto. Il riconoscimento può avvenire attraverso una sorta di procedura di accesso, durante il funzionamento del programma dal lato cliente, 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 parola d'ordine 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. Questo ultimo metodo non viene descritto.
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 una parola d'ordine. 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.
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 parola d'ordine.
|
Si può intuire che fare una cosa del genere significa concedere a tali utenti privilegi simili a quelli di root. In generale, tali utenti non dovrebbero essere in grado di utilizzare UID molto bassi, ma questo dipende da come sono stati compilati i sorgenti; comunque non è questo un buon motivo per configurare così il file |
Il nome o l'indirizzo di un nodo può essere preceduto da un segno, + o -, con il quale si intende, rispettivamente, includere o escludere il nodo stesso. Come si può intendere, il segno + è predefinito.
Come già accennato, 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 presso i 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.(2)
I dettagli sull'uso di questi file possono essere differenti da un sistema all'altro. In particolare ci possono essere delle restrizioni ai permessi che può avere questo file; infatti, secondo il buon senso, /etc/hosts.equiv dovrebbe appartenere all'utente root, senza consentire accessi in scrittura ad altri utenti; nello stesso modo, il file ~/.rhosts dovrebbe appartenere all'utente al quale si riferisce, senza che altri possano avere permessi di scrittura su questo. Inoltre, 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 parola d'ordine, anche se normalmente è sufficiente predisporre il file ~root/.rhosts.(3) Si veda in ogni caso quanto descritto nelle pagine di manuale hosts.equiv(5) e rhosts(5), se presenti nel proprio sistema.
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 servente occorre un demone in.rlogind (o solo rlogind) e dal lato del cliente il programma rlogin.
La sintassi per avviare demone dal lato del servente è molto semplice:
in.rlogind [opzioni]
Il demone in.rlogin è gestito dal supervisore dei servizi di rete e filtrato dal TCP wrapper. Nell'esempio seguente, viene mostrata la riga di /etc/inetd.conf in cui si dichiara il suo possibile utilizzo per quanto riguarda il caso particolare di Inetd:
login stream tcp nowait root /usr/sbin/tcpd in.rlogind |
| Opzione | Descrizione |
|
| Permette anche all'utente root di utilizzare il file ~/.rhosts. |
Dal lato del cliente il programma rlogin consente di accedere all'elaboratore remoto, come se ci si trovasse sulla console di quello:
rlogin [opzioni] host_remoto
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 in.rshd (o rshd) dal lato servente e rsh dal lato cliente.
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.
Segue la sintassi per l'avvio del demone che offre questo servizio:
in.rshd [opzioni]
Il demone in.rshd è gestito dal supervisore dei servizi di rete e filtrato dal TCP wrapper (tcpd). Nell'esempio seguente, viene mostrata la riga di /etc/inetd.conf in cui si dichiara il suo possibile utilizzo per quanto riguarda il caso particolare di Inetd:
shell stream tcp nowait root /usr/sbin/tcpd in.rshd |
| Opzione | Descrizione |
|
| Permette anche all'utente root di utilizzare il file ~/.rhosts. |
Dal lato del cliente il programma rsh permette di eseguire il comando richiesto nell'elaboratore remoto specificato se su quell'elaboratore è abilitata questa possibilità:
rsh [opzioni] host_remoto [comando]
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.
Segue la descrizione di alcuni esempi per l'utilizzo di rsh.
$ 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 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 file system 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 servente occorre il demone rshd e dal lato del servente serve anche rsh.
La sintassi per l'uso di rcp ricalca in linea di massima quella di cp:
rcp [opzioni] origine destinazione
rcp [opzioni] origine... directory
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.
Seguono alcuni esempi.
$ 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.
daniele @ swlibero.org1) netkit-rsh UCB BSD
2) Si deve fare attenzione al fatto che tra il nome del nodo e il nome dell'utente, ci deve essere uno spazio.
3) Per quanto riguarda le limitazioni all'accesso dell'utente root, si tenta presente che potrebbe essere stato impedito l'accesso da un elaboratore remoto a causa della configurazione del file /etc/securetty.
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome accesso_remoto.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]