[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


98. 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.

98.1 Identificazione

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 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'.

98.1.1 /etc/hosts.equiv

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 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 `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, e comunque non è un buon motivo per configurare in questo modo il file `/etc/hosts.equiv'.

98.1.2 ~/.rhosts

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*

98.1.3 Utenti speciali

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*

98.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 `rlogind' e dal lato del cliente il programma `rlogin'.

98.2.1 # rlogind

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
Alcune opzioni

-h

Permette anche all'utente `root' di utilizzare il file `~/.rhosts'.

98.2.2 $ rlogin

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.

Alcune opzioni

-l <utente>

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.

-8

Abilita la connessione utilizzando una comunicazione a 8 bit in modo da poter utilizzare caratteri speciali che vanno oltre l'ASCII tradizionale.

98.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 `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.

98.3.1 rshd

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
Alcune opzioni

-h

Permette anche all'utente `root' di utilizzare il file `~/.rhosts'.

98.3.2 $ rsh

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'.

Alcune opzioni

-l <utente>

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.

Esempi

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.

98.4 Copia tra elaboratori

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 servente occorre il demone `rshd'.

98.4.1 $ rcp

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.

Alcune opzioni

-r

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.

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.

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 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'.


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]