int128/groovy-ssh

SSH automation tool based on Groovy DSL

Groovy SSH

Groovy SSH is an automation tool based on DSL providing the remote command execution and file transfer.

https://gradle-ssh-plugin.github.io

Contributions

This is an open source software licensed under the Apache License Version 2.0. Feel free to open issues or pull requests.

Unit test

We can run the unit test as follows:

./gradlew :core:check

Server integration test

We can run the server integration test using Apache MINA SSHD server as follows:

./gradlew :server-integration-test:check

CLI test

We can run the integration test of CLI as follows:

./gradlew :cli:check

OS integration test

We can run the OS integration tests using int128/sshd image as follows:

# Run a sshd container
./os-integration-test/run-sshd.sh

# Run the tests
./gradlew :os-integration-test:check

Gradle SSH Plugin integration test

We can run the test with Gradle SSH Plugin. See plugin-integration/run-plugin-integration-test.sh for details.

If you are planning to release with specification change breaking backward compatibility, create groovy-ssh-acceptance-test branch on Gradle SSH Plugin to pass the acceptance test.

groovy-ssh's Issues

Release v1.1.6

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  
• Update Gradle SSH Plugin dependencies and tests
  
• Update Gradle SSH Plugin README
  
• Update the release note
  
• Publish Gradle SSH Plugin on Bintray JCenter
  
• Publish Gradle SSH Plugin on Maven Central via Bintray
  
• Update the user guide of Gradle SSH Plugin
  
• Announce on Blog

Release 2.2.0

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  

Script hangs if SFTP subsystem is disabled

Reported #68 by @jordihs.

Release 2.1.0: Merge pull request #135 from int128/scp

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  

Release 1.0.6

• groovy-ssh
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
• Gradle SSH Plugin
  • Update dependencies and tests
  • Update README
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
  • Update the user guide
• Announce
  • Blog

Release 1.1.9

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  
• Update the user guide of Gradle SSH Plugin
  
• Announce on Blog

CI eventually fails due to file transfer corruption

We verify behavior of CLI JAR on CI but it sometimes fails due to file corruption while SFTP put.

$ java -jar cli/build/libs/gssh.jar cli/gssh-example.groovy
2016-03-19 14:21:34.232 INFO  Connected to tester
2016-03-19 14:21:37.163 INFO  Sending 46% to tester: .
2016-03-19 14:21:38.968 INFO  Sent file to tester: cli/build/libs/gssh.jar -> .
2016-03-19 14:21:39.133 INFO  Started command tester#1: java -jar gssh.jar --version
2016-03-19 14:21:39.303 ERROR tester#1|Error: Unable to access jarfile gssh.jar
2016-03-19 14:21:39.335 ERROR Failed command tester#1 with status 1: java -jar gssh.jar --version
2016-03-19 14:21:39.349 ERROR Error: org.hidetake.groovy.ssh.session.BadExitStatusException: Command tester#1 returned exit status 1: java -jar gssh.jar --version
2016-03-19 14:21:39.349 INFO  Run with -s or --stacktrace option to get the stack trace

SftpOperations and FileTransferLogger always log to slf4j

When using put, log output always goes to SLF4J and never to System.out. Even when this is set:

ssh.settings { logging = 'stdout' }

all log entries related to the SFTP are still logged using the SLF4J logger.

Release 1.5.1

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  

What about an expect-like interaction support?

Hi,
I have some use cases in which an expect-like syntax for interacting with the ssh server would be preferable.
In this approach, you send commands and expect the server to answer with a pattern.
I found this java implementation, and adapted it to the context of groovy-ssh; the result is in this branch of my forked repository. I did not alter any file of the original source, and put the new code in a different package, for the sake of readability.

This is a fragment of a unit test that explains the function:

ssh.run {
    session(ssh.remotes.testServer) {
        shellExpect {
            send 'hello server'
            expectOrThrow 1,'please enter password:'
            send 'Welcome1'
            expectOrThrow 1, 'password OK'
        }
    }
}

If you think this could be useful, I can define a pull request, removing the custom package name.

Release 1.6.0

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  

Some test eventually failed

Maybe case executeBackground handles lines.

Condition not satisfied:

resultActual == resultExpected
|            |  |
second line  |  some result
             |  second line
             false
             12 differences (47% similarity)
             s(--)e(--------~--)cond line
             s(om)e( result\nse)cond line
 <Click to see difference>

    at org.hidetake.groovy.ssh.server.BackgroundCommandExecutionSpec.executeBackground should return output of the command: #description(BackgroundCommandExecutionSpec.groovy:190)

Release v1.1.5

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  
• Send pull request for gssh on Homebrew
  
• Update Gradle SSH Plugin dependencies and tests
  
• Update README of Gradle SSH Plugin
  
• Update release note of Gradle SSH Plugin
  
• Publish Gradle SSH Plugin on Bintray JCenter
  
• Publish Gradle SSH Plugin on Maven Central via Bintray
  
• Update user guide of Gradle SSH Plugin
  
• Announce on Blog

Release 0.0.0

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  

Show version for issue inspection

Provides eash way to show version of Groovy SSH, JSch and Groovy.

Release 1.1.0

• groovy-ssh
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
• Gradle SSH Plugin
  • Update dependencies and tests
  • Update README
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
  • Update the user guide
• Announce
  • Blog

Cannot connect

Hi,

Cannot connect, getting error message reject HostKey: 192.168.4.104

I have tried hostname instead of IP and using password instead of key file but the result is the same.
With ssh on console I can connect without problem.

This is gradle debug output

16:58:17.836 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter] Executing actions for task ':deploy'.
16:58:17.900 [DEBUG] [org.hidetake.groovy.ssh.session.Executor] Executing 1 session(s)
16:58:17.915 [DEBUG] [org.hidetake.groovy.ssh.connection.ConnectionManager] Establishing a connection to Remote raspberry [192.168.4.104:22]
16:58:18.022 [DEBUG] [org.hidetake.groovy.ssh.connection.ConnectionManager] Using known-hosts file: /Users/vista/.ssh/known_hosts
16:58:18.027 [DEBUG] [org.hidetake.groovy.ssh.connection.ConnectionManager] Establishing a connection to Remote raspberry [192.168.4.104:22]
16:58:18.034 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: Connecting to 192.168.4.104 port 22
16:58:18.049 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: Connection established
16:58:18.149 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: Remote version string: SSH-2.0-OpenSSH_6.7p1 Raspbian-5
16:58:18.149 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: Local version string: SSH-2.0-JSCH-0.1.52
16:58:18.150 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
16:58:18.615 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: aes256-ctr is not available.
16:58:18.616 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: aes192-ctr is not available.
16:58:18.616 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: aes256-cbc is not available.
16:58:18.616 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: aes192-cbc is not available.
16:58:18.617 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
16:58:18.714 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
16:58:18.719 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: SSH_MSG_KEXINIT sent
16:58:18.720 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: SSH_MSG_KEXINIT received
16:58:18.720 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: server: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
16:58:18.721 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: server: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
16:58:18.721 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: server: aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected]
16:58:18.721 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: server: aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected]
16:58:18.721 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: server: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
16:58:18.722 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: server: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
16:58:18.722 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: server: none,[email protected]
16:58:18.722 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: server: none,[email protected]
16:58:18.723 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: server:
16:58:18.723 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: server:
16:58:18.724 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: client: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
16:58:18.724 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: client: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
16:58:18.724 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
16:58:18.725 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc
16:58:18.725 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
16:58:18.725 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
16:58:18.725 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: client: none
16:58:18.726 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: client: none
16:58:18.726 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: client:
16:58:18.726 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: client:
16:58:18.727 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: server->client aes128-ctr hmac-sha1 none
16:58:18.727 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: kex: client->server aes128-ctr hmac-sha1 none
16:58:18.766 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: SSH_MSG_KEXDH_INIT sent
16:58:18.766 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: expecting SSH_MSG_KEXDH_REPLY
16:58:18.912 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: ssh_rsa_verify: signature true
16:58:18.914 [DEBUG] [org.hidetake.groovy.ssh.connection.JSchLogger] JSch: Disconnecting from 192.168.4.104 port 22
16:58:18.919 [DEBUG] [org.hidetake.groovy.ssh.connection.ConnectionManager] Waiting for pending operations
16:58:18.924 [DEBUG] [org.hidetake.groovy.ssh.connection.ConnectionManager] Finished all operations including background commands
16:58:18.926 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':deploy'
16:58:18.926 [LIFECYCLE] [class org.gradle.TaskExecutionLogger] :deploy FAILED

Release 1.0.3

Tasks for release 1.0.3

• groovy-ssh
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
• Gradle SSH Plugin
  • Update dependencies
  • Update tests
  • Update the user guide
• Announce
  • Blog

Division by zero in progress logging for small file transfers

Hi, for small file transfers the elapsed time may be 0ms which is causing an exception:

Put a local file (test.yml) to remote (/deploy)
Starting transfer 1,667 bytes.

org.gradle.api.tasks.TaskExecutionException: Execution failed for task 'deploy'.
...
Caused by: java.lang.ArithmeticException: Division by zero
at org.hidetake.gradle.ssh.internal.operation.FileTransferLogger$Status.getKiloBytesPerSecond(FileTransferLogger.groovy:70)
at org.hidetake.gradle.ssh.internal.operation.FileTransferLogger.end(FileTransferLogger.groovy:48)
at com.jcraft.jsch.ChannelSftp._put(ChannelSftp.java:682)
... 75 more

Release 1.1.4

• groovy-ssh
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
• Gradle SSH Plugin
  • Update dependencies and tests
  • Update README
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
  • Update the user guide
• Announce
  • Blog

Release 2.3.0

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  

Packet corrupt errors after upgrading from 1.1.5 to 1.1.7

I just upgraded from 1.1.5 to 1.1.7 and then discovered that the SSH retry mechanism stopped working.

We run:

def hostConfigMap = ...
hostConfigMap.retryCount = 20
hostConfigMap.retryWaitSec = 30

ssh.run {
  session(hostConfigMap) {
    execute "echo hello world"
  }
}

The output is:

Retrying: com.jcraft.jsch.JschException: java.net.NoRouteToHostException: No route to host
Retrying: com.jcraft.jsch.JschException: java.net.ConnectException: Connection refused
Retrying: com.jcraft.jsch.JschException: java.net.ConnectException: Connection refused
Retrying: com.jcraft.jsch.JschException: Auth fail
Retrying: com.jcraft.jsch.JschException: Packet corrupt
Retrying: com.jcraft.jsch.JschException: Packet corrupt
... etc

ConnectionKeepAlive support

I'm having problems with long running tasks resulting in the connection being hanged because the server closes it since there's no client interaction for a long time.
This can be solved by adding support for something similar to OpenSSH ConnectionKeepAlive functionality.

Release 1.1.3

• groovy-ssh
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
• Gradle SSH Plugin
  • Update dependencies and tests
  • Update README
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
  • Update the user guide
• Announce
  • Blog

Port forwarding support?

Is there a way to set up SSH port forwarding. Do you expose the jsch Session anywhere?

The method I am interested in calling is something like session.setPortForwardingL(8000, "localhost", 8000)

It seems like it could be added fairly simply to

groovy-ssh/src/main/groovy/org/hidetake/groovy/ssh/connection/ConnectionManager.groovy

Line 62 in 198fb09

private Session establishViaGateway(Remote remote) {

if you could provide local/remote forwards in the remotes closure. I might have a go at it, but I don't have clear idea of how it fits together at the moment.

Is it possible to make it work via TOR socks 5 proxy?

Putty works through TOR normally, but java do not
Error is "ProxySOCKS5: com.jcraft.jsch.JSchException: fail in SOCKS5 proxy" but TOR is open and putty works with it.

proxies {
    socks {
        host = 'localhost'
        port = 1080
        type = SOCKS
        socksVersion = 5
    }
}

remotes {
    testServer {
        host = 'main.exmaple.com'
        user = 'root'
        if (System.properties['os.name'].toLowerCase().contains('windows')) {
            identity = file( System.getProperty("user.home") + /\.ssh\id_rsa.ppk/)
        } else {
            identity = file(System.getProperty("user.home") + '/.ssh/id_rsa')
        }
        passphrase='mypassphraze'
                proxy = proxies.socks
    }

} 

Release 2.1.1

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  

Release 2.0.0: Merge pull request #128 from int128/per-remote-settings

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  

Release 1.0.7

• groovy-ssh
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
• Gradle SSH Plugin
  • Update dependencies and tests
  • Update README
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
  • Update the user guide
  • Update the template project
• Announce
  • Blog

Improve SCP performance

Performance test on Travis CI container https://travis-ci.org/int128/gradle-ssh-plugin/builds/128732593

Test Item	Time [sec]	scp vs sftp
task ':performance:should get a large file via scp'	10580	419%
task ':performance:should get a large file via sftp'	2525
task ':performance:should get many files via scp'	882	75%
task ':performance:should get many files via sftp'	1179
task ':performance:should put a large file via scp'	3056	144%
task ':performance:should put a large file via sftp'	2129
task ':performance:should put many files via scp'	13525	1025%
task ':performance:should put many files via sftp'	1319

Released JAR contains wrong version string

Released version should be shown on run the JAR:

% java -jar groovy-ssh.jar
usage: [option...] [-e script-text] [script-filename | --stdin] [script-args...]
 -d,--debug     Set log level to debug.
 -e <arg>       Specify a command line script.
 -h,--help      Shows this help message.
 -i,--info      Set log level to info. (default)
 -n,--dry-run   Do a dry run without connections.
 -q,--quite     Set log level to warn.
    --stdin     Specify standard input as a source.
groovy-ssh-1.0.5

but actually wrong version is shown:

% java -jar groovy-ssh.jar
usage: [option...] [-e script-text] [script-filename | --stdin] [script-args...]
 -d,--debug     Set log level to debug.
 -e <arg>       Specify a command line script.
 -h,--help      Shows this help message.
 -i,--info      Set log level to info. (default)
 -n,--dry-run   Do a dry run without connections.
 -q,--quite     Set log level to warn.
    --stdin     Specify standard input as a source.
groovy-ssh-SNAPSHOT

Provides offline feature

Provides the fat JAR which contains all dependencies.

Release 2.1.2: Merge pull request #142 from int128/scp-progress

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  

Dry run option for CLI

such as groovy-ssh --dry-run example.groovy

Release v1.1.8: Merge pull request #78 from int128/fix-retry-scope

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  
• Update the user guide of Gradle SSH Plugin
  
• Announce on Blog

Add acceptance test

as standalone SSH tool like groovysh

Release 1.5.0

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  

Release 2.4.0

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  

Release 1.0.4

Tasks for release 1.0.4

• groovy-ssh
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
• Gradle SSH Plugin
  • Update dependencies and tests
  • Update README
  • Update the user guide
• Announce
  • Blog

Include an SCP option?

I know this might seem redundant with the SFTP functionality, but there are cases where SFTP doesn't work and SCP does. It would be great to allow the someone to use scp in the 'put' file operation, kind of how pscp allows the either with a flag: http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter5.html (-scp or -sftp)

session should accept a collection of remote

session() requires braces [] for now:

session([remotes.web01, remotes.web02]) {
  //execute ...
}

Following code causes an error but should work:

session(remotes.web01, remotes.web02) {
  //execute ...
}

See also: gradle-ssh-plugin/gradle-ssh-plugin.github.io#4

Release v1.1.7

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  
• Update Gradle SSH Plugin dependencies and tests
  
• Update Gradle SSH Plugin README
  
• Update the release note
  
• Publish Gradle SSH Plugin on Bintray JCenter
  
• Publish Gradle SSH Plugin on Maven Central via Bintray
  
• Update the user guide of Gradle SSH Plugin
  
• Announce on Blog

Release 1.4.0: Merge pull request #106 from int128/logging

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  

Release 1.3.0: Merge pull request #98 from int128/sftp-rm

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  

Gateway does not close after usage, blocks script exit

I use gateway to do ssh tunelling. This works great, but I found that my scripts using this will not exit at the end because the gateway keeps running. I tried looking for a way to signal it to close but can not find a hook into it.
My only option is to call System.exit()

Demo

    def service = new Service()
    service.remotes {
        gw {
            host = 'gatewaydevice'
            user = 'myuser'
            password = 'mypassword'
            knownHosts = service.settings.allowAnyHosts
        }
        target {
            host = 'targetdevice'
            user = 'myuser'
            password = 'mypassword'
            gateway = service.remotes.gw
        }
    }
    service.run {
        session(service.remotes.target) {
            execute('virsh list') {result ->
                println result
            }
        }
    }

This will not quit when run as Groovy script unless you kill it hard

Release 1.0.5

Tasks for release 1.0.5

• groovy-ssh
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
• Gradle SSH Plugin
  • Update dependencies and tests
  • Update README
  • Update the release note
  • Publish on Bintray JCenter
  • Publish on Maven Central via Bintray
  • Update the user guide
• Announce
  • Blog

Migrate tests from gradle-ssh-plugin project

Migrate server integration tests from here.

kerberos authentication?

I'm new to using this project and JSch, so this might be a naive question, but would it be possible to allow SSH auth via kerberos? e.g., by adding gssapi-with-mic.krb5 to the list of PreferredAuthentications in the JSch part of session setup, e.g.:

session.setConfig('PreferredAuthentications', 'publickey,keyboard-interactive,password,gssapi-with-mic.krb5')

or by just making the 'PreferredAuthentications' config option settable via Groovy SSH settings?

Thanks...

Hostname does not appear in console log if logging is stdout

Since v1.0.0, hostname of the current session is appeared in the console log, but it is not appeared if logging is set to stdout.

Release 1.2.0

• Update the release note
  
• Publish on Bintray JCenter
  
• Publish on Maven Central via Bintray
  
• Update the user guide of Gradle SSH Plugin
  
• Announce on Blog