2012-12-17 7 views
5

Qual è il modo corretto per chiudere una connessione SSH a conchiglia Twisted? C'è un modo esplicito per farlo?Qual è il modo corretto per chiudere una connessione SSH a conchiglia Twisted?

Tutti gli esempi di conchiglie contorte ho visto chiudere il canale SSH e quindi arrestare il reattore. Lo spegnimento del reattore sembra gestire la chiusura della connessione. Comunque, sto usando il wxreactor con wxPython e non voglio fermare il reattore, ma voglio chiudere la connessione ssh quando ho finito con esso.

Dopo aver osservato la connessione t.c.s.sembrava che il metodo serviceStopped() fosse la strada da percorrere. Si chiude tutti i canali aperti e corre _cleanupGlobalDeferreds() al termine, ma poi ho cominciato a ricevere eccezioni come quella qui sotto:

Unhandled Error 
Traceback (most recent call last): 
    File "C:\Users\me\venv\lib\site-packages\twisted\internet\tcp.py", line 203, in doRead 
    return self._dataReceived(data) 
    File "C:\Users\me\venv\lib\site-packages\twisted\internet\tcp.py", line 209, in _dataReceived 
    rval = self.protocol.dataReceived(data) 
    File "C:\Users\me\venv\lib\site-packages\twisted\conch\ssh\transport.py", line 438, in dataReceived 
    self.dispatchMessage(messageNum, packet[1:]) 
    File "C:\Users\me\venv\lib\site-packages\twisted\conch\ssh\transport.py", line 460, in dispatchMessage 
    messageNum, payload) 
--- <exception caught here> --- 
    File "C:\Users\me\venv\lib\site-packages\twisted\python\log.py", line 84, in callWithLogger 
    return callWithContext({"system": lp}, func, *args, **kw) 
    File "C:\Users\me\venv\lib\site-packages\twisted\python\log.py", line 69, in callWithContext 
    return context.call({ILogContext: newCtx}, func, *args, **kw) 
    File "C:\Users\me\venv\lib\site-packages\twisted\python\context.py", line 118, in callWithContext 
    return self.currentContext().callWithContext(ctx, func, *args, **kw) 
    File "C:\Users\me\venv\lib\site-packages\twisted\python\context.py", line 81, in callWithContext 
    return func(*args,**kw) 
    File "C:\Users\me\venv\lib\site-packages\twisted\conch\ssh\service.py", line 44, in packetReceived 
    return f(packet) 
    File "C:\Users\me\venv\lib\site-packages\twisted\conch\ssh\connection.py", line 228, in ssh_CHANNEL_DATA 
    channel = self.channels[localChannel] 
exceptions.KeyError: 0 

Sembra che sto ancora ricevendo i dati dal server dopo che il canale è stato chiuso. Qualcuno in #twisted sembrava pensare che non dovrei chiamare serviceStopped() me stesso perché dovrebbe essere chiamato automaticamente da una parte diversa di Twisted.

Ho fatto qualche ricerca nel codice sorgente Twisted e ho trovato che serviceStopped dovrebbe essere chiamato da t.c.s.t.SSHClientTransport.connectionLost().

Sto tenendo traccia dei miei oggetti client SFTP e accedo alla connessione SSH tramite il loro attributo di trasporto. Ecco un esempio che puoi eseguire localmente per dimostrare il problema. Il raw può essere recuperato here.

from os.path import basename 
import sys 

from twisted.conch.client.connect import connect 
from twisted.conch.client.options import ConchOptions 
from twisted.internet.defer import Deferred 
from twisted.conch.ssh import channel, userauth 
from twisted.conch.ssh.common import NS 
from twisted.conch.ssh.connection import SSHConnection 
from twisted.conch.ssh.filetransfer import FXF_WRITE, FXF_CREAT, \ 
    FXF_TRUNC, FileTransferClient 
from twisted.internet import reactor, defer 
from twisted.python.log import startLogging 

ACTIVE_CLIENTS = {} 
USERNAME = 'user'   # change me! 
PASSWORD = 'password'  # change me! 
HOST = ('hostname', 22)  # change me! 
TEST_FILE_PATH = __file__ 
TEST_FILE_NAME = basename(__file__) 


def openSFTP(user, host): 
    conn = SFTPConnection() 
    options = ConchOptions() 
    options['host'], options['port'] = host 
    conn._sftp = Deferred() 
    auth = SimpleUserAuth(user, conn) 
    connect(options['host'], options['port'], options, verifyHostKey, auth) 
    return conn._sftp 


def verifyHostKey(ui, hostname, ip, key): 
    return defer.succeed(True) 


class SimpleUserAuth(userauth.SSHUserAuthClient): 
    def getPassword(self): 
     return defer.succeed(PASSWORD) 


class SFTPConnection(SSHConnection): 
    def serviceStarted(self): 
     self.openChannel(SFTPChannel()) 


class SFTPChannel(channel.SSHChannel): 
    name = 'session' 

    def channelOpen(self, ignoredData): 
     d = self.conn.sendRequest(self, 'subsystem', NS('sftp'), 
            wantReply=True) 
     d.addCallback(self._cbFTP) 
     d.addErrback(self.printErr) 

    def _cbFTP(self, ignore): 
     client = FileTransferClient() 
     client.makeConnection(self) 
     self.dataReceived = client.dataReceived 
     ACTIVE_CLIENTS.update({self.conn.transport.transport.addr: client}) 
     self.conn._sftp.callback(None) 

    def printErr(self, msg): 
     print msg 
     return msg 


@defer.inlineCallbacks 
def main(): 
    d = openSFTP(USERNAME, HOST) 
    _ = yield d 

    client = ACTIVE_CLIENTS[HOST] 
    d = client.openFile(TEST_FILE_NAME, FXF_WRITE | FXF_CREAT | FXF_TRUNC, {}) 
    df = yield d 

    sf = open(TEST_FILE_PATH, 'rb') 
    d = df.writeChunk(0, sf.read()) 
    _ = yield d 

    sf.close() 
    d = df.close() 
    _ = yield d 

    ACTIVE_CLIENTS[HOST].transport.loseConnection() 
    # loseConnection() call above causes the following log messages: 
    # [SSHChannel session (0) on SSHService ssh-connection on SSHClientTransport,client] sending close 0 
    # [SSHChannel session (0) on SSHService ssh-connection on SSHClientTransport,client] unhandled request for exit-status 
    # [SSHChannel session (0) on SSHService ssh-connection on SSHClientTransport,client] remote close 
    # [SSHChannel session (0) on SSHService ssh-connection on SSHClientTransport,client] closed 
    # I can see the channel closed on the server side: 
    # sshd[4485]: debug1: session_exit_message: session 0 channel 0 pid 4486 
    # sshd[4485]: debug1: session_exit_message: release channel 0 
    # sshd[4485]: debug1: session_by_channel: session 0 channel 0 

    ACTIVE_CLIENTS[HOST].transport.conn.transport.loseConnection() 
    # loseConnection() call above does not close the SSH connection. 

    reactor.callLater(5, reactor.stop) 
    # Stopping the reactor closes the SSH connection and logs the following messages: 
    # [SSHClientTransport,client] connection lost 
    # [SSHClientTransport,client] Stopping factory <twisted.conch.client.direct.SSHClientFactory instance at 0x02E5AF30> 
    # [-] Main loop terminated. 
    # On the server side: 
    # sshd[4485]: Closing connection to xxx.xxx.xxx.xxx 


if __name__ == '__main__': 
    startLogging(sys.stdout) 
    reactor.callWhenRunning(main) 
    reactor.run() 

Per chiudere la connessione SSH, sto chiamando ACTIVE_CLIENTS[HOST].transport.conn.transport(t.c.c.d.SSHClientTransport instance).loseConnection() che chiama t.c.c.d.SSHClientTransport.sendDisconnect(). Ecco il metodo sendDisconnect():

def sendDisconnect(self, code, reason): 
    if self.factory.d is None: 
     return 
    d, self.factory.d = self.factory.d, None 
    transport.SSHClientTransport.sendDisconnect(self, code, reason) 
    d.errback(error.ConchError(reason, code)) 

self.factory.d sembra essere sempre None quando questo metodo viene chiamato in modo che ritorna senza chiamare t.c.s.t.SSHClientTransport.sendDisconnect(). Penso che originariamente fosse un insieme posticipato in t.c.c.d.connect, ma ad un certo punto è impostato su None.

Sospetto che SSHClientTransport.loseConnection() sia il modo corretto per chiudere le connessioni SSH, ma perché self.factory.d è impostato su None quando twisted si aspetta che sia qualcos'altro?

Se lossConnection() non è il modo corretto per chiudere le connessioni SSH, qualcuno potrebbe indicarmi la giusta direzione?

risposta

4

Sembra che tu stia usando twisted.conch.client.direct.SSHClientFactory e twisted.conch.client.direct.SSHClientTransport. Queste classi sono più direttamente destinate ad essere utilizzate per implementare lo strumento da riga di comando conch. Ciò significa che sono abbastanza utili per creare un client SSH, poiché è esattamente ciò che è conch.

Tuttavia, sono anche un po 'meno generalmente utili di quanto si possa immaginare, dal momento che non prestano molta attenzione a fare qualcosa di "altro" rispetto all'implementazione dello strumento da riga di comando conch.

La classe di trasporto client SSH più applicabile è twisted.conch.ssh.transport.SSHClientTransport. Questa classe non ha alcuna logica aggiuntiva per l'implementazione di alcuni comportamenti particolari dello strumento da riga di comando conch. Ha solo la logica client SSH. Ad esempio, non ha un controllo self.factory.d non spiegato all'interno di sendDisconnect - la sua implementazione sendDisconnect invia semplicemente un pacchetto di disconnessione e quindi chiude la connessione.

1

Mi imbatto nello stesso problema. Sono convinto che sia un bug che sendDisconnect() non chiama l'implementazione genitore. Chiamare loseConnection() su SSHClientTransport non chiude la connessione TCP per me, che posso vedere utilizzando lsof -p PID. Per risolvere questo problema, utilizzo il mio metodo connect() per iniettare la mia implementazione di SSHClientTransport. Il problema è risolto con il seguente codice:

class SSHClientTransport(direct.SSHClientTransport): 
    ''' 
    Orignal sendDisconnect() is bugged. 
    ''' 

    def sendDisconnect(self, code, reason): 
     d, self.factory.d = self.factory.d, None 
     # call the sendDisconnect() on the base SSHTransport, 
     # not the imediate parent class 
     transport.SSHClientTransport.sendDisconnect(self, code, reason) 
     if d: 
      d.errback(error.ConchError(reason, code)) 
Problemi correlati