|
|
|
|
Strumenti |
09-02-2018, 08:31 | #1 |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
[C++] Telnet
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 |
09-02-2018, 15:10 | #2 |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
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. |
09-02-2018, 17:27 | #3 | |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
Quote:
|
|
10-02-2018, 09:44 | #4 | |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
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. |
|
10-02-2018, 12:16 | #5 |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
ti risulta che telnet implementato in windows XP implementi ssh durante una connessione?
|
10-02-2018, 16:32 | #6 |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
|
12-02-2018, 14:47 | #7 |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
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.
|
12-02-2018, 15:28 | #8 | |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
Però deve comunque accettare i successivi comandi. |
|
12-02-2018, 15:56 | #9 |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
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.
Ultima modifica di misterx : 12-02-2018 alle 15:58. |
12-02-2018, 16:11 | #10 | |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
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. |
|
12-02-2018, 18:16 | #11 |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
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 Ultima modifica di misterx : 12-02-2018 alle 18:50. |
13-02-2018, 09:10 | #12 |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
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.
|
13-02-2018, 09:41 | #13 |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
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 Ultima modifica di misterx : 13-02-2018 alle 10:32. |
23-02-2018, 11:36 | #14 |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
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 |
23-02-2018, 14:33 | #15 |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
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. |
23-02-2018, 15:48 | #16 | |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
Quote:
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? |
|
23-02-2018, 16:37 | #17 | |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
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 Codice:
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 |
|
23-02-2018, 19:05 | #18 |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
è 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: Codice:
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 } Ultima modifica di misterx : 23-02-2018 alle 19:07. |
24-02-2018, 10:46 | #19 |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
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. |
24-02-2018, 11:33 | #20 | |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
Quote:
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. |
|
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 00:19.