Newsgroup: it.comp.os.linux.sys
Titolo: accesso telnet limitato ad una dir

ciao
e' possibile fare in modo che "telnettando" in una linux box si
rimanga solo in quella directory senza poer andare a spasso per il
resto della macchina? Ad intuito direi di si ma non so da dove
iniziare
grazie

Sgranocchiando il cranio di full-name, vi trovai inciso:

dal man di chroot, ma non aspettarti che sia facile..
-- 
Emanuele Balla  aka Skull -  Public Key #661E5CBF on 
www.keyserver.com
+----------------------------------------------------------------------+
"And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports
on it, you know they are just evil lies." (By Linus Torvalds)

full-name wrote:

Bhe ognuno e padrone di buttare il suo tempo come crede...
Scusa l'ironia, ma ti conviene utilizzare il telnet che e considerato uno 
dei servizi piu' pericolosi ed attaccabili???
Al posto di perder tempo con telnet, datti una letta a SSH e vedrai che 
Telnet te loo scorderai.
Buon Lavoro

 dei servizi piu' pericolosi ed attaccabili???
Interessante. Perche'?
Ciao
Marco



sempre le stesse domande. ...
perche' il passaggio dei dati non e' cifrato, bensi' in chiaro.
--
Massimiliano

 servizi piu' pericolosi ed attaccabili???
Non condivido questo tipo di approccio alla sicurezza e i discorsi
puramente teorici lasciano il tempo che trovano.
Per una intranet il telnet va piu' che bene. Bisogna quindi capire se il
servizio e' da usare su internet o su una piccola/media intranet.
Pensa che esistono aziende che rendono disponibili accessi ad AS400 (senza
ssl) via internet ... ovviamente l'accesso all'as400 e' di tipo telnet
--
Massimiliano.

 Se fai questa domanda hai un problema molto grave: usa Google e saprai.
telnet ha un unico problema, il traffico in chiaro (che comunque non
e' una vulnerabilita' propria del servizio), e che qualunque persona 
minimamente competente risolve con ssl;
secondo debian-security (oltre a cert, bugtraq ed il database CVE di
Mitre, parlando solo di linux, niente Cisco) dal 1997 al 2003 c'e' una
sola vulnerabilita' conosciuta contro le otto/nove di ssh (vado a 
memoria, posso sbagliare): da questo punto di vista sono autorizzato a
considerarlo piu 'sicuro, e considerare l' affermazione dell' OP un
pochino azzardata e dilettantesca;
quindi (visto che potrei sempre imparare qualcosa di nuovo) ripeto:
interessante, perche'?
Ciao
Marco

 Poi, chiaramente, ognuno e' libero di farsi del male come preferisce.
Accettando nozioni acriticamente, per esempio.
-- 
If you're stuck at the level of wanting to point at a picture and 
click, you've got to understand that you're basically at the same 
level as a preverbal child...
	-- bear (on comp.lang.scheme)

 la ragione per cui non si possa fare lo stesso con telnet.
concordo, anche se ritengo che questa discussione sia comunque falsata
dal fatto che si sta parlando di ssh come di un telnet crittato, cosa
che palesemente non č.
Posto che si utilizzi ssh *solo* per l'accesso in shell, e solo con
autenticazione classica username+password, allora tantovale usare telnet
su ssl.
Perň diviene per lo piů una limitazione di chi usa il servizio, non tanto
del servizio in sč...
i miei 2 centesimi...


 Forse perche' ssh e' ben piu' di un semplice telnet criptato?
Forse perche' ssh e' _anche_ qualcosa meno di un semplice telnet
(cifrato o no)?
Ciao
Marco

 Poi, chiaramente, ognuno e' libero di farsi del male come preferisce.
sempre pensato che, nonostante si dica che ssh e' il rimpiazzo di 
telnet, siano due strumenti diversi.  
E se adesso l' Op mi rispondesse con parole sue non mi dispiacerebbe;
per me passo e chiudo
Ciao
Marco

 dei servizi piu' pericolosi ed attaccabili???
E uso le virgolette perché palesemente la risposta non ha niente a che
fare con la domanda.
Sfortunatamente è diffuso lo sport di far bella mostra di quel po' di
conoscenza che si ha, acquisita e è suffragata dalla vox populi e
quindi apparentemente intoccabile (vedi appunto ``telnet non si usa'',
ma anche ``i filesystem NTFS non si ridimensionano'', o ``ricompilando
acceleri''), anche quando il nesso con il contesto è vago a dir poco.
(Non mi pare di aver letto qualcuno esporsi con ``usa piuttosto APOP''
o ``usa IMAPS'' parlando di posta, per esempio.)

 wrappare telnet con stunnel o simili.
Non ce n'è bisogno (e credo che Marco ne sia al corrente).
bard@prism:~$ apt-cache show telnet-ssl
Package: telnet-ssl
Description: The telnet client with SSL encryption support.
 The telnet command is used for interactive communication with another host
 using the TELNET protocol.
 .
 SSL telnet(d) replaces normal telnet(d) using SSL authentication and
 encryption. It interoperates with normal telnet(d) in both directions.
 It checks if the other side is also talking SSL, if not it falls back
 to normal telnet protocol.
 .
 Advantages over normal telnet(d): Your passwords and the data you send
 will not go in cleartext over the line. Nobody can get it with
 tcpdump or similar tools. With SSLtelnet you can also connect to
 https-server like 
https://www.netscape.com
. Just do
 'telnet 
www.netscape.com
 443'
-- 
Programming languages should be designed not by piling feature on top
of feature, but by removing the weaknesses and restrictions that make
additional features appear necessary.
                                                        (R5RS, Introduction)

 Non ce n'è bisogno (e credo che Marco ne sia al corrente).
uff.
Allora nell'ordine:
RISPOSTE ALLA _PRIMA_ DOMANDA (utente di shell limitato)
- a seconda della "serieta`" dell'implementazione puoi usare rbash o un
  ambiente chroot, per non permettere all'utente di "uscire" dalla
directory. Attenzione che se implementi un ambiente chroot, devi anche
_replicare_ le funzionalita` permesse (la roba in /usr/bin ad esempio,
che viceversa diventa inaccessibile).
RISPOSTE ALLA _SECONDA_ DOMANDA (telnet vs ssh)
- ssh e` un _sostituto_ di telnet e di rsh
- ssh e` estremamente configurabile e con diverse feature
- ssh _sopratutto_ permette diversi tipi di autenticazione, tra cui, la
  fondamentale autenticazione con _chiavi_. Questa e` una differenza
evidente. Se tra fare "login" via telnet-ssl e ssh, fa poca differenza,
l'autentica con chiave, cambia un bel po` le carte in tavola.
- il paragone "astronave/bicicletta" e` IMHO poco calzante: puoi fare
  login anche con netcat, se e` per questo, e` nel tuo paragone e` il
monopattino. Magari e poco sensato-utile-comodo, ecc. Tutti _ottimi_
motivi per preferirgli ssh.
Sulla questione "vulnerabilita`" ti ha gia` risposto _eloquentemente_
Whiplash.
Ciao.
/me che PasswordAuthentication no, e serve.
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
If you're not part of the solution, be part of the problem!

 
e non solo serve, e` anche piu` comodo :-)
- non digitando la password, non corri il rischio che nessuno alle tue 
spalle cerchi di spiarla
- e molto comodo/semplice usare scp se fai l'auth con chiave
my 2 ç
Banana

 Description: The telnet client with SSL encryption support.
Certo, esattamente
Ciao
Marco

 Oh beh..
Mi spiace, e' solo il mio modo per dire "se non c'e' nient'altro", ma
se vuoi, continuiamo pure.
Ciao
Marco

 Un esempio?
Volentieri, due:
opie: che io sappia (a qualche mese fa) non esiste la possibilita'
di utilizzo con ssh;
la sua diffusione: un client telnet lo trovi ovunque, un client ssh
forse meno.
(non vorrei aver dato l' impressione di essere un sostenitore di
telnet vs. ssh, perche' cio' non e' vero: li considero due strumenti
diversi con funzionalita' parzialmente sovrapposte e semplicemente li
utilizzo nel modo e nell' occasione a me piu' conveniente; il tutto
nasce da quella baggianata iniziale)
Ciao
Marco

 l'autentica con chiave, cambia un bel po` le carte in tavola.
assolutamente si, specialmente dove l' autenticazione con chiave non
e' possibile e tu resti chiuso fuori. 
(Leggo volentieri le tue risposte, so che sei competente e di sicuro 
ti verra' in mente almeno un' occasione in cui cio' puo' capitare:
quando vuoi parlarne...).
Ciao
Marco

 __declspec(dllexport) and __declspec(dllimport)
That's a complicated question.  Essentially, the MS engineers were on crack
when they designed Windows DLLs.    (C. Thompson on the Cygwin mailing list)

 dico di usare ssh o che altrimenti è butta il suo tempo.
Ma guarda, la mia personale opinione e`: critichiamo i contenuti o i
"modi". Personalmente, sara` che sono un vecchio rincoglionito, sara`
che sono "troppo stanco per queste cose", preferisco concentrarmi su i
contenuti e dare poco/nullo peso ai modi.
Ognuno ha il suo carattere, e francamente, non ho interesse ad educare
nessuno. Ovviamente, vale per me.
Detto questo, che _oggettivamente_ ssh e` un _miglior_ sostituto di
telnet/rsh mi pare evidente, e nel caso, mi piacerebbe discutere di
questo. Sul fatto che venga proposto "male", o altro, attiene ad una
sfera (o a sfere) molto diverse su cui occorrerebbe fare mille
considerazioni.
Comprendo quello che vuoi dire, ma inevitabilmente, temo, ci sia poco da
fare, va parte della "varieta`".
Ora, vado a spararmi un martini. :)
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
HELO. My $name is 
sendmail.cf
. Prepare to vi.

 quando vuoi parlarne...).
Intanto mi permetto di dire: troppo buono messere.
Poi, parliamone (volentieri).
Personalmente, mi piace scindere in due "categorie" i problemi: generali
e specifici.
Perche` diversamente, e` troppo facile dire tutto e il contrario di
tutto. E` evidente che se non ci sono le condizioni (una macchina linux,
o una macchina con un client ssh completo), ssh non e` comodo.
Ma questo e` un caso specifico. Su una macchina remota, se non va la
rete, non ci arrivo. Anche questo e` un caso specifico.
In questo caso (rete down) posso operare due scelte: o ritengo che il
problema non merita un urgenza tale da garantire un "fallback service"
(leggi, ci attacco un modem e una tty), oppure si. Ma qui si esce dal
problema "servizio", e si entra nel problema "rindondanza del servizio".
Per ssh uguale: personalmente, uso le mie stazioni di lavoro ed esse
hanno _tutto_ quello che mi serve. Portatili compresi.
Se il mio problema e` diverso (sono da un cliente, devo usare mezzi
suoi, ecc), allora si parla d'altro ma non mi pare che questo "leda" il
principio di cui sopra. Semplicemente e` un caso particolare che va
trattato in base a quello che possiedi, ma per limiti ben diversi di
"implementazione del software di collegamento".
Viceversa, non ho capito quello che volevi dire (il che e` facile,
nonostante le tue belle parole. :)).
Ciao.
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------


 una buona soluzione (pant, pant), _forse_ e` il caso di segnalarlo.
Ad esempio, AFAIK rsync funziona su ssh, su telnet no, criptato o meno.
Ed rsync č sul serio comodo...
-- 
Ciao da Villo    -    GPG public key available
                      Ferrara LUG 
http://ferrara.linux.it
		      Revome "+nospam" for email replies
Protect your Freedom: 
http://www.againsttcpa.com/index.shtml

 "implementazione del software di collegamento".
Immagino tu lo conosca PuTTY...
Funziona anche da CD, chiavi comprese.


 No, stunnel e' escluso dalla prova..
Pier, perdinci, un' interrogazione a sorpresa! Sono piu' di vent' anni
e sono emozionato. Punto da subito al 18. Vediamo.
Messa giu' cosi sembra una trappoletta, ci sono poche informazioni (e 
anche un po' confuse, eh). Cosa intendi per amministrazione? Tu per 
tunnel intendi un canale cifrato, no? pero' lo vuoi fatto con telnet
che di suo non cifra nulla (lo abbiamo detto tutti). Quindi se e'
questo che mi chiedi, e' irrealizzabile per definizione. 
Cosi al buio io farei telnet(ssl) 
https://localhost
 443
Puoi specificare meglio?
Ciao
Marco

 Viceversa, non ho capito quello che volevi dire (il che e` facile,
No no, hai capito perfettamente.
Ciao
Marco

 incluso nell'insieme di cio' che puo' essere fatto con ssh.
credo che Maurizio abbia scritto (in generale/particolare, scusa il
gioco di parole) di un caso in cui questo non e' vero.
Ciao
Marco

 Ora, vado a spararmi un martini. :)
Bastardo, non potevi che terminare con un'affermazione
inconfutabile. :-)
/me segue l'esempio e va a versarsi due dita di vodka
-- 
Windows Configuration
=====================
   No, there's nothing here about X, so be quiet.
                                                       (From Gnus info file)

 Funziona anche da CD, chiavi comprese.
Io lo conosco. Non lo uso (*giggle*) perche` non ne ho necessita` (vedi
precedente messaggio), ma lo conosco, e sono certo che anche l'altro
amico lo conosce.
Il senso cmq era altro. Puo` esistere un caso specifico. Ma in tal caso,
il problema e` altro. (es, magari solo client Mac... che ne so...).
Cmq, il mio fido portatile ha tutto quello che mi serve (a parte che sto
scancherando per l'accelerazione video, non si vive di solo ssh, eh.).
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
There are three kinds of people: Those who can count & those who can't.

 	life ne abbiamo tutti).
E' tutto vero. Ma in questo senso, introdurrei un ulteriore argomento:
quello "storico". Immagino che un po` di anni fa, ci siano state
"diatribe" analoghe tra il "nuovo" telnetd, e il "rodato" rlogin/rsh. E
immagino che anche in tal caso si potevano utilizzare queste ottime
argomentazioni (che non sono ne sbagliate, ne giuste, sono in fondo
commenti d'uso. Non mi e` parso, fin qui, che ci fosse una "ragione" e
un "torto").
Per inciso, puoi ancora usare .rhosts come forma d'autenticazione
(magari via ssh <grin>), ma "purtroppo", per tanti motivi anche
"storici" (la solita storia che l'internet di prima generazione e` ben
diversa da quella attuale), e` stato "sostituito".
In questo senso, telnet rimane ancora una garanzia, ma _imho_ dovrebbe
essere sostituito da strumenti piu` efficenti, e/o "attuali" per
problematiche, feature e altro ancora.
In questo senso, non biasimo chi consiglia ssh tout-court, come non mi
sento di biasimare nessuna delle tue argomentazioni che trovo molto
assennate e condivisibili.
Semplicemente, pero` telnet (come tanti altri strumenti/software/os
prima di lui), ha fatto il suo tempo e _deve_ morire. :)
Ovviamente, non e` una "tautologia", solo il commento di un accaldato
Tannoiser. :)
Ciao.
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------


 /me segue l'esempio e va a versarsi due dita di vodka
/me offer to.
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------


 stupidaggini. E per quanto mi riguarda l'argomento e' chiuso.
Ah, la saggezza popolare.
http://www.google.it/search?q=cache:EY8KJQafXAoJ:www.netgraphicsbox.altervista.org/favole/%63%6F%64%61%70%61%67%6C%69%61%2E%70%64%66

 aspetta, riassumo (sono tutti post in sequenza, basta leggerli):
un consiglio: lascialo perdere.
ci guadagni in salute.
girera' e rigirera', alla fine ti dira' che sei un idiota e poi ti
mettera' nel killfile. Non sa far altro.
--
Massimiliano.

 un "torto").
esatto, ho sempre scritto pensando alle occasioni, non alle ragioni.
Ciao
Marco

 Biggolo bongo, tu non sabere gosa essere abblighescion server? Ma avere
eh, spiegamelo tu, va'
Ciao
Marco

Cavolo ragazzi! Io volevo dare un consiglio Spassionato mica scatenare una 
guerra!!
Mancavo da qualche giorno e ho visto quella sfilza di risposte.
A dir la verità quando ho letto che non valeva la pena usare ssh in una 
intranet  ho smesso di leggere gli altri. Ho letto con piacere che qualcuno 
ha spiegato il perchè al nostro amico del ng. Quest'ultimo deve sperare che 
nella SUA intranet ci sia sempre gente poco competente.
Sentito Mai parlare di SOCIAL ENGENEERING??
Buon Ferragosto a tutti

 gente poco competente.  Sentito Mai parlare di SOCIAL ENGENEERING??
Una sparata sola non bastava?  Repetita iuvant?