[C++] Telnet

[misterx]

ciao,
devo far eseguire ad un utente un certo comando su un server unix e dar modo allo stesso di verificarne l'output.
Creata la socket ed inviato il messaggio con nome utente e password sulla porta 23, quello che ottengo è un errore 5 di "accesso negato", non mi spiego allora se deve essere una connessione particolare.
Uso il medesimo sistema per connettermi con degli apparati cisco per automatizzare certi controlli e funziona correttamente, questi, accettano comandi ed inviano le relative risposte, non capisco cosa mi sfugge nel caso di unix.

Grazie

[pabloski]

Originariamente inviato da misterx

non capisco cosa mi sfugge nel caso di unix.

Grazie

Direi niente. Il protocollo telnet è questo https://tools.ietf.org/html/rfc854

Piuttosto mi domando se in ascolto sulla porta 23 ci sia veramente telnet. E' possibilissimo ( e alcuni admin lo fanno ) metteri ssh e allora hai voglia a mandare comandi telnet.

Prova ad usare nmap -sV su quella porta, almeno lui dovrebbe darti informazioni certe su che tipo di servizio c'è veramente dietro.

[misterx]

Originariamente inviato da pabloski

Direi niente. Il protocollo telnet è questo https://tools.ietf.org/html/rfc854

Piuttosto mi domando se in ascolto sulla porta 23 ci sia veramente telnet. E' possibilissimo ( e alcuni admin lo fanno ) metteri ssh e allora hai voglia a mandare comandi telnet.

Prova ad usare nmap -sV su quella porta, almeno lui dovrebbe darti informazioni certe su che tipo di servizio c'è veramente dietro.

in ascolto c'è telnet sul server che gestisco io, ma sto leggendo in merito ad ssh che credo il mio compilatore non supporti, credo

[pabloski]

Originariamente inviato da misterx

in ascolto c'è telnet sul server che gestisco io, ma sto leggendo in merito ad ssh che credo il mio compilatore non supporti, credo

Il problema è che ssh è proprio un altro protocollo, con supporto alla crittografia, ecc... per cui l'handshake per la connessione è parecchio diverso.

Però se sei assolutamente sicuro che il servizio remoto sia telnet, bisogna supporre che il problema sia un altro. Per esempio la porta 23 è aperta e visibile sempre? Alcuni admin implementano il port knocking.

Ti conviene guardare com'è configurato il servizio remoto, altrimenti è difficile venirne a capo.

[misterx]

ti risulta che telnet implementato in windows XP implementi ssh durante una connessione?

[pabloski]

Originariamente inviato da misterx

ti risulta che telnet implementato in windows XP implementi ssh durante una connessione?

L'ho usato in passato ed era un normalissimo telnet.

[misterx]

Originariamente inviato da pabloski

L'ho usato in passato ed era un normalissimo telnet.

sto notando che la connessione tra client e server unix viene creata, verificata con netstat, ma non mi arriva il messaggio dal server unix di richiesta username e password, cosa che invece avviene regolarmente con gli apparati cisco.

[pabloski]

Originariamente inviato da misterx

sto notando che la connessione tra client e server unix viene creata, verificata con netstat, ma non mi arriva il messaggio dal server unix di richiesta username e password, cosa che invece avviene regolarmente con gli apparati cisco.

Hanno soppresso il banner. In genere si fa per evitare agli hacker di capire quale software specifico fornisce il servizio.

Però deve comunque accettare i successivi comandi.

[misterx]

Originariamente inviato da pabloski

Hanno soppresso il banner. In genere si fa per evitare agli hacker di capire quale software specifico fornisce il servizio.

Però deve comunque accettare i successivi comandi.

forse sto capendo qualcosa, forse. Il server, dopo aver creato la socket, mi invia questa sequenza di caratteri ÿþ%ÿý che ho scoperto essere una sequenza di comandi telnet attraverso i quali, credo, il server stesso mi sta chiedendo alcuni parametri per la connessione; io dovrei rispondere in un qualche modo, ma ancora non so come. I cisco sono più tolleranti non mi chiedono nulla.

[pabloski]

Originariamente inviato da misterx

forse sto capendo qualcosa, forse. Il server, dopo aver creato la socket, mi invia questa sequenza di caratteri ÿþ%ÿý che ho scoperto essere una sequenza di comandi telnet attraverso i quali, credo, il server stesso mi sta chiedendo alcuni parametri per la connessione; io dovrei rispondere in un qualche modo, ma ancora non so come. I cisco sono più tolleranti non mi chiedono nulla.

Considera che il rfc 854 supporta un certo numero di sequenze di caratteri speciali per definire vari parametri di comunicazione. Il rfc 855 aggiunge la possibilità di implementare opzioni e comandi proprietari. E il rfc 5198 aggiunge il supporto unicode, per cui occhio che quella stringa potrebbe non essere ascii.

L'inghippo è che bisogna implementare per bene il protocollo telnet. Oppure usare una qualche libreria già fatta tipo questa https://github.com/seanmiddleditch/libtelnet

Sarebbe interessante vedere che succede se provi a collegarti tramite un client telnet di quelli comunemente disponibili.

[misterx]

telnet di windows funziona regolarmente, ma a me serve una implementazione specifica. Proverò col solito wireshark a catturare qualche pacchetto durante una sessione telnet, anche se dubito che si veda qualcosa a meno che non si vada per tentativi



http://mud-dev.wikidot.com/telnet:negotiation

[pabloski]

Originariamente inviato da misterx

telnet di windows funziona regolarmente, ma a me serve una implementazione specifica. Proverò col solito wireshark a catturare qualche pacchetto durante una sessione telnet, anche se dubito che si veda qualcosa a meno che non si vada per tentativi

Almeno sai che il server implementato il protocollo telnet come definito dai relativi rfc. Mi sa che ti conviene usare wireshark. Si tratta senz'altro di comandi di subnegoziazione.

[misterx]

ok, funziona.

dopo la connessione attraverso socket si ha che:

server invia:
ff fe 25 ff fd 18

client risponde:
ff fc 25
ff fb 18 ff fb 1f

server invia:
ff fd 1f ff fd 18 ff fa 18 01 ff f0

client risponde:
ff fb 18 ff fa 18 00 41 4e 53 49 ff f0

server invia:
dati presentazione tipo SO etc... bla bla bla

client risponde:
ff fd 01

server
richiesta nome utente e poi password


lo lascio per chi ha necessità simile alla mia. Rappresenta la sequenza di comandi scambiati durante una sessione di connessione tra un server unix e telnet a linea di comando di Windows sulla porta 23

grazie 1000 pabloski per il tuo utilissimo supporto


p.s.
per la cattura dei pacchetti ho usato questo sorgente: https://gist.github.com/Accalmie/d328287c05f0a417892f
documentazione necessaria: https://it.wikipedia.org/wiki/Transm...ntrol_Protocol

[misterx]

ok, l'implementazione funziona però mi è rimasto un enorme dubbio. Approfondendo il discorso socket e TCP, ho letto che in ambiente unix i messaggi che transitano su socket non hanno confini ma vale anche per windows?

Il senso di confine credo, sia che se mi aspetto un comando fatto da 3 byte, TCP potrebbe inviarmi 3 byte in un unico messaggio, oppure 2 o 1 o addirittura 0.
Se ho capito bene, significa che devo implementare una sorta di buffer "elastico" e poi comportarmi in base a quello che trovo: è così?

Grazie

[pabloski]

Si e no. In Linux la massima dimensione di un pacchetto TCP è indicato da TCP_MAXSEG ( va letto chiamando getsockopt ). La dimensione effettiva dipende da altri fattori, come il MTU. Per normali reti ethernet è 1500 bytes, che possono salire a 9000 per i jumbo frame.

Windows implementa lo stack tcp di BSD, quindi vale lo stesso discorso.

Comunque il discorso lascia il tempo che trova, nel senso che comunque leggerai i dati dal socket tramite read e quindi gli passerai un buffer e la relativa dimensione e lui non andrà in overflow e ti restituirà il numero di bytes effettivamente letti. Poi fai un while numbytes>0 e leggi i vari pezzi dello stream. Questa semplificazione ovviamente non vale per UDP e lì la cosa diventa effettivamente laboriosa.

[misterx]

Originariamente inviato da pabloski

Si e no. In Linux la massima dimensione di un pacchetto TCP è indicato da TCP_MAXSEG ( va letto chiamando getsockopt ). La dimensione effettiva dipende da altri fattori, come il MTU. Per normali reti ethernet è 1500 bytes, che possono salire a 9000 per i jumbo frame.

Windows implementa lo stack tcp di BSD, quindi vale lo stesso discorso.

Comunque il discorso lascia il tempo che trova, nel senso che comunque leggerai i dati dal socket tramite read e quindi gli passerai un buffer e la relativa dimensione e lui non andrà in overflow e ti restituirà il numero di bytes effettivamente letti. Poi fai un while numbytes>0 e leggi i vari pezzi dello stream. Questa semplificazione ovviamente non vale per UDP e lì la cosa diventa effettivamente laboriosa.

ma c'è modo di conoscere prima di invocare la read quanti dati sono presenti sulla socket in modo da dimensionare il buffer e leggere tutti i dati con una sola read oppure non ha senso?

[pabloski]

Originariamente inviato da misterx

ma c'è modo di conoscere prima di invocare la read quanti dati sono presenti sulla socket in modo da dimensionare il buffer e leggere tutti i dati con una sola read oppure non ha senso?

No, è totalmente opaco. TCP è pensato in modo tale che il programmatore lo debba vedere come uno stream, quindi leggi i dati finchè non arriva l'equivalente dell'EOF.

Se ti serve necessariamente sapere quanti bytes inviare/ricevere ( ad esempio quando s'invia un file tramite HTTP ) ci deve pensare il livello applicativo.

Per esempio l'esempio del file che citavo produce una cosa del genere

POST /blahblahblah HTTP/1.1
Host: blahblah
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Accept-Charset: utf-8
Keep-Alive: 115
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------xxxxxxxxxxxxxxxx
Content-Length: lunghezza-del-file

Come puoi notare, la lunghezza del file è specificata in un apposito campo del protocollo HTTP.

[misterx]

è quell'EOF che non mi è chiaro.
Pensando al protocollo telnet ad esempio:

il server dopo la richiesta della connession invia: ff fe 25 ff fd 18

ma potrebbe decidere per una qualsiasi ragione (rete trafficata, server sovraccarico, client lento etc...) di iniziare ad inviarmi solo ff e solo successivamente il resto?

Quello che ho fatto io è stato quello di creare due buffer, uno A che cancello ogni volta e l'altro B che continua a riempirsi e si svuoterà solo quando si verifica una certa condizione, come ad esempio la condizione di messaggio completo:

in codice Borland:

AnsiString MyBuffer;
int BytesRicevuti;
 
    int SizeMessaggio = Socket->ReceiveLength(); // questo mi comunica le dimensioni del pacchetto/messaggio
   
    if (SizeMessaggio > 0) // se ho dati da collettare in MyBuffer
    {
        char *Buffer = new char[Size]; // ridimensiono il Buffer temporaneo
        if ((BytesRicevuti = Socket->ReceiveBuf(Buffer, Size) > 0))
         MyBuffer += AnsiString(Buffer, BytesReceived);
        delete[] Buffer;
    }

if(strstr(MyBuffer, "ff fe 25 ff fd 18")) // questo mi dicono che non è il modo corretto di trattare i messaggi telnet
{
    elaboro MyBuffer; // spedisco le risposte al server
    MyBuffer=""; // e lo resetto per il successivo utilizzo 
}

[pabloski]

Il punto è che un EOF ( nel senso dei file ) non c'è. Infatti se si guarda com'è fatto un pacchetto TCP, si nota che non c'è nulla che dica quant'è la dimensione dei dati inviati.



Ma la read ( o la recv ) ti restituisce zero se l'altro host ha chiuso la comunicazione. Cioè l'EOF c'è quando almeno uno dei due conclude.

Nel mezzo c'è una comunicazione dove arrivano, ad intervalli incerti, dati in varie quantità.

Il protocollo applicativo li interpreta man mano che arrivo e, se manca qualcosa, è evidente che manca un pezzo d'informazione e bisogna continuare a leggere.

[misterx]

Originariamente inviato da pabloski

Il punto è che un EOF ( nel senso dei file ) non c'è. Infatti se si guarda com'è fatto un pacchetto TCP, si nota che non c'è nulla che dica quant'è la dimensione dei dati inviati.



Ma la read ( o la recv ) ti restituisce zero se l'altro host ha chiuso la comunicazione. Cioè l'EOF c'è quando almeno uno dei due conclude.

Nel mezzo c'è una comunicazione dove arrivano, ad intervalli incerti, dati in varie quantità.

Il protocollo applicativo li interpreta man mano che arrivo e, se manca qualcosa, è evidente che manca un pezzo d'informazione e bisogna continuare a leggere.

in definitiva si deve continuare a leggere sino a quando si trova quello che serve e comportarsi di conseguenza.

Non sapendo come è implementato la ReceiveLength() ho sempre pensato che mi dicesse quanti dati mi sta inviando il server ed invece, ora penso che mi dica solo quanti dati ha in "canna" windows per il mio applicativo.