[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [volume] [parte]


Capitolo 293.   Accesso remoto

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)

293.1   Identificazione e fiducia

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 /etc/hosts.equiv.

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.

Secondo la sintassi tradizionale di questo file, si può inserire una riga contenente soltanto il segno +, allo scopo di consentire l'accesso a qualunque nodo. In questo senso si spiega poi la presenza del segno - per escludere poi qualche nodo particolare.

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.

293.2   Accesso remoto normale

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
-h
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] nodo_remoto
Opzione Significato mnemonico Descrizione
-l utente
login 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 parola d'ordine in ogni caso.
-8
Abilita la connessione utilizzando una comunicazione a 8 bit in modo da poter utilizzare caratteri speciali che vanno oltre l'ASCII tradizionale.

293.3   Shell remota

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 esegue un comando presso l'elaboratore remoto. Il problema sta quindi nel comprendere quale sia effettivamente il comando che viene poi eseguito nell'elaboratore remoto, tenendo conto anche della shell che viene 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
-h
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] nodo_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.

Opzione Significato mnemonico Descrizione
-l utente
login 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 parola d'ordine in ogni caso.

Segue la descrizione di alcuni esempi per l'utilizzo di rsh.

293.4   Copia tra elaboratori

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@]nodo:]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.

Opzione Significato mnemonico Descrizione
-r
recursive 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.
-p
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.

Seguono alcuni esempi.

Appunti di informatica libera 2007.02 --- Copyright © 2000-2007 Daniele Giacomini -- <daniele (ad) swlibero·org>


1) 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.htm

[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico]

Valid ISO-HTML!

CSS validator!