Dispatch hangs using Rundeck 1.2.0

[Anthony Shortland]

We're working with a client whose local (non-queued) execution of a command using dispatch of the following command:

[anthony@rundeck etc]$ dispatch -v -L -I node1 -- uname -a

verbose: preparing for remote execution ...

Linux rundeck 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

... to a remote node hangs just after "verbose: preparing for remote execution ..." and never returns.

Bizarrely the command works just fine through the Rundeck web UI when executed on both local and remote nodes and also works via dispatch when executed on the local node.

Is there any level of debug or other troubleshooting approach that will shed more light on the source of this problem? What happens between the verbose message and the first output seen from the remote node? What is the difference in execution between the dispatch command and the web UI?

Anthony.

[Greg Schueler]

If you can do a thread dump at that point it could be useful (kill -QUIT)

[hom]

I killed "kill -QUIT <pid>" the process running ExecTool, the
following output was capture from the terminal running the dispatch
command.

verbose: preparing for remote execution ...

2011-04-21 14:00:00
Full thread dump OpenJDK 64-Bit Server VM (14.0-b16 mixed mode):

"Low Memory Detector" daemon prio=10 tid=0x0000000006d2d000 nid=0x2a8a
runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"CompilerThread1" daemon prio=10 tid=0x0000000006d2a800 nid=0x2a89
waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"CompilerThread0" daemon prio=10 tid=0x0000000006d26800 nid=0x2a88
waiting on condition [0x0000000000000000] java.lang.Thread.State:
RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x0000000006d24000 nid=0x2a87
runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x0000000006cfd000 nid=0x2a86 in
Object.wait() [0x0000000041e43000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00002aaaae5e1210> (a
java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:
133)
- locked <0x00002aaaae5e1210> (a java.lang.ref.ReferenceQueue
$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:
149)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:
177)

"Reference Handler" daemon prio=10 tid=0x0000000006cfb000 nid=0x2a85
in Object.wait() [0x0000000041d42000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00002aaaae5e1078> (a java.lang.ref.Reference
$Lock)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:
133)
- locked <0x00002aaaae5e1078> (a java.lang.ref.Reference$Lock)

"main" prio=10 tid=0x0000000006c96000 nid=0x2a83 runnable
[0x0000000040bac000]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:236)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:
273)
at java.io.BufferedInputStream.read(BufferedInputStream.java:
334)
- locked <0x00002aaaae5f0e08> (a java.io.BufferedInputStream)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:282)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:324)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:176)
- locked <0x00002aaaaf470710> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:153)
at java.io.BufferedReader.readLine(BufferedReader.java:316)
- locked <0x00002aaaaf470710> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:379)
at
com.sun.security.auth.callback.TextCallbackHandler.readLine(TextCallbackHandler.java:
151)
at
com.sun.security.auth.callback.TextCallbackHandler.handle(TextCallbackHandler.java:
119)
at
com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:
767)
at
com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:
646)
at
com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:
559)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
at javax.security.auth.login.LoginContext.access
$000(LoginContext.java:203)
at javax.security.auth.login.LoginContext
$5.run(LoginContext.java:721)
at javax.security.auth.login.LoginContext
$5.run(LoginContext.java:719)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:
718)
at
javax.security.auth.login.LoginContext.login(LoginContext.java:590)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:264)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:
153)
at sun.security.jgss.krb5.Krb5InitCredential
$1.run(Krb5InitCredential.java:346)
at sun.security.jgss.krb5.Krb5InitCredential
$1.run(Krb5InitCredential.java:344)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:
343)
at
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:
145)
at
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:
123)
at
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:
189)
at
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:
220)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:
213)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:
180)
at
com.jcraft.jsch.jgss.GSSContextKrb5.init(GSSContextKrb5.java:129)
at
com.jcraft.jsch.UserAuthGSSAPIWithMIC.start(UserAuthGSSAPIWithMIC.java:
135)
at com.jcraft.jsch.Session.connect(Session.java:419)
at com.jcraft.jsch.Session.connect(Session.java:150)
at
com.dtolabs.rundeck.core.tasks.net.ExtSSHExec.openSession(ExtSSHExec.java:
467)
at
com.dtolabs.rundeck.core.tasks.net.ExtSSHExec.execute(ExtSSHExec.java:
212)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:
106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at
org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
at
com.dtolabs.rundeck.core.cli.TaskCallable.call(TaskCallable.java:45)
at
com.dtolabs.rundeck.core.cli.DefaultNodeDispatcher.executeNodedispatch(DefaultNodeDispatcher.java:
163)
at
com.dtolabs.rundeck.core.execution.script.CommandAction.doAction(CommandAction.java:
194)
at
com.dtolabs.rundeck.core.execution.DispatchedScriptExecutor.executeDispatchedScript(DispatchedScriptExecutor.java:
65)
at
com.dtolabs.rundeck.core.execution.DispatchedScriptExecutor.executeItem(DispatchedScriptExecutor.java:
55)
at
com.dtolabs.rundeck.core.execution.ExecutionServiceImpl.executeItem(ExecutionServiceImpl.java:
49)
at
com.dtolabs.rundeck.core.cli.ExecTool.runAction(ExecTool.java:542)
at
com.dtolabs.rundeck.core.cli.ExecTool.runAction(ExecTool.java:484)
at com.dtolabs.rundeck.core.cli.ExecTool.run(ExecTool.java:
405)
at com.dtolabs.rundeck.core.cli.ExecTool.main(ExecTool.java:
668)

"VM Thread" prio=10 tid=0x0000000006cf6000 nid=0x2a84 runnable

"VM Periodic Task Thread" prio=10 tid=0x0000000006d2f800 nid=0x2a8b
waiting on condition

JNI global references: 863

Heap
def new generation total 78656K, used 15432K [0x00002aaaae5e0000,
0x00002aaab3b30000, 0x00002aaac3b30000)
eden space 69952K, 22% used [0x00002aaaae5e0000,
0x00002aaaaf4f21a0, 0x00002aaab2a30000)
from space 8704K, 0% used [0x00002aaab2a30000, 0x00002aaab2a30000,
0x00002aaab32b0000)
to space 8704K, 0% used [0x00002aaab32b0000, 0x00002aaab32b0000,
0x00002aaab3b30000)
tenured generation total 174784K, used 0K [0x00002aaac3b30000,
0x00002aaace5e0000, 0x00002aaaee5e0000)
the space 174784K, 0% used [0x00002aaac3b30000,
0x00002aaac3b30000, 0x00002aaac3b30200, 0x00002aaace5e0000)
compacting perm gen total 21248K, used 11119K [0x00002aaaee5e0000,
0x00002aaaefaa0000, 0x00002aaaf8de0000)
the space 21248K, 52% used [0x00002aaaee5e0000,
0x00002aaaef0bbc38, 0x00002aaaef0bbe00, 0x00002aaaefaa0000)
No shared spaces configured.

[Greg Schueler]

Hmm, it looks like it is waiting to read input, and traces back to this;

        at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:767)
        at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:646)
        at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:559)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        .....

        at com.jcraft.jsch.jgss.GSSContextKrb5.init(GSSContextKrb5.java:129)
        at com.jcraft.jsch.UserAuthGSSAPIWithMIC.start(UserAuthGSSAPIWithMIC.java:135)
        at com.jcraft.jsch.Session.connect(Session.java:419)

So it seems the SSH connection is trying to prompt for username/password

do you have Private key auth configured successfully so you can ssh to the host without entering a password?

[hom]

Yes, the keys have been exchanged, ssh from the command line to the
remote server works without any password prompting.
Command dispatching via the gui also works
Only command dispatching from the command line is hanging

example of ssh from the command line to the remote host
{code}
[rundeck@ctier ~]$ ssh ctier@xymon hostname
xymon
{code}

On Apr 21, 2:12 pm, Greg Schueler <g...@controltier.com> wrote:
> Hmm, it looks like it is waiting to read input, and traces back to this;
>

>         at com.sun.security.auth.module.*Krb5LoginModule.promptForName*

> (Krb5LoginModule.java:767)
>         at
> com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:646)
>         at
> com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:559)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         .....
>         at com.jcraft.jsch.jgss.GSSContextKrb5.init(GSSContextKrb5.java:129)
>         at
> com.jcraft.jsch.UserAuthGSSAPIWithMIC.start(UserAuthGSSAPIWithMIC.java:135)

>         at com.jcraft.jsch.*Session.connect*(Session.java:419)

> ...
>
> read more »

[Charles Scott]

we looked at that and yes....

we verified that this all works thru ctlcenter and rundeck UI's

does not work thru  the equivalent command lines as defined in the UI (respective ctl-exec and dispatch commands do not work)

ssh equivalency is in place and is verified

we have never seen a situation where the UI works and command line does not.  The reverse problem we have seen at times so this appears to be unprecedented.

[Anthony Shortland]

And if you deprive an account of key-based authentication you get:

[rundeck@rundeck etc]$ dispatch -v -p Development -L -I node1 -- id

verbose: preparing for remote execution ...

Failed execution for node: node1: com.jcraft.jsch.JSchException: Auth cancel

com.jcraft.jsch.JSchException: Auth cancel

        at com.dtolabs.rundeck.core.tasks.net.ExtSSHExec.execute(ExtSSHExec.java:244)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.lang.reflect.Method.invoke(Method.java:616)

        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)

        at org.apache.tools.ant.Task.perform(Task.java:348)

        at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)

        at com.dtolabs.rundeck.core.cli.TaskCallable.call(TaskCallable.java:45)

        at com.dtolabs.rundeck.core.cli.DefaultNodeDispatcher.executeNodedispatch(DefaultNodeDispatcher.java:163)

        at com.dtolabs.rundeck.core.execution.script.CommandAction.doAction(CommandAction.java:194)

        at com.dtolabs.rundeck.core.execution.DispatchedScriptExecutor.executeDispatchedScript(DispatchedScriptExecutor.java:65)

        at com.dtolabs.rundeck.core.execution.DispatchedScriptExecutor.executeItem(DispatchedScriptExecutor.java:55)

        at com.dtolabs.rundeck.core.execution.ExecutionServiceImpl.executeItem(ExecutionServiceImpl.java:49)

        at com.dtolabs.rundeck.core.cli.ExecTool.runAction(ExecTool.java:542)

        at com.dtolabs.rundeck.core.cli.ExecTool.runAction(ExecTool.java:484)

        at com.dtolabs.rundeck.core.cli.ExecTool.run(ExecTool.java:405)

        at com.dtolabs.rundeck.core.cli.ExecTool.main(ExecTool.java:668)

Caused by: com.jcraft.jsch.JSchException: Auth cancel

        at com.jcraft.jsch.Session.connect(Session.java:451)

        at com.jcraft.jsch.Session.connect(Session.java:150)

        at com.dtolabs.rundeck.core.tasks.net.ExtSSHExec.openSession(ExtSSHExec.java:467)

        at com.dtolabs.rundeck.core.tasks.net.ExtSSHExec.execute(ExtSSHExec.java:212)

        ... 17 more

error: com.jcraft.jsch.JSchException: Auth cancel

... not a hang ... could we be looking at some interaction with the Kerberos at the system level perhaps?

Anthony.

[Greg Schueler]

I think it must be kerberos. is kerberos authentication configured for the server?

if the dispatch command is picking up the auth config used by the server, perhaps the Jsch is trying to use kerberos then

[hom]

depriving the remote of the key still results in a hang of the
dispatch command

On Apr 21, 2:37 pm, Anthony Shortland <anthony.shortl...@me.com>
wrote:

> ...
>
> read more »

[hom]

we use likewise for AD authentication on our servers, and likewise
uses kerberos

> >         at com.sun.security.auth.module.*Krb5LoginModule.promptForName*

> > (Krb5LoginModule.java:767)
> >         at
> > com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:646)
> >         at
> > com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:559)
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >         .....
> >         at
> > com.jcraft.jsch.jgss.GSSContextKrb5.init(GSSContextKrb5.java:129)
> >         at
> > com.jcraft.jsch.UserAuthGSSAPIWithMIC.start(UserAuthGSSAPIWithMIC.java:135)

> >         at com.jcraft.jsch.*Session.connect*(Session.java:419)

>
> > So it seems the SSH connection is trying to prompt for username/password
>
> > do you have Private key auth configured successfully so you can ssh to the
> > host without entering a password?
>

> ...
>
> read more »

[Anthony Shortland]

Ah! Looks like something in the code path during dispatch (that's different from a similar execution in the Rundeck UI) is hitting a Kerberos related problem, then.

Are there obvious differences in the way JSch is used in these two modes? Something that may be context sensitive? Configuration dependent?

Here's some doc: http://epaul.github.com/jsch-documentation/javadoc/com/jcraft/jsch/UserAuthGSSAPIWithMIC.html ... but perhaps Greg could take a look at JSch code to understand why this class' start method is being invoked in the first place ...

Anthony.

[hom]

I confirmed a rundeck dispatch to a client without likewise installed
works correctly. If I want to use rundeck however, I'll need to make
it work on a likewise installed client. The differences in /etc/
krb5.conf are below. Any ideas?

{code}
7c7
< default_realm = EXAMPLE.COM
---
> default_realm = WI
9c9
< dns_lookup_kdc = false
---
> dns_lookup_kdc = true
11a12,22
> default_keytab_name = /etc/krb5.keytab
> default_tgs_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
> default_tkt_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
> preferred_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
> pkinit_kdc_hostname = <DNS>
> pkinit_anchors = DIR:/var/lib/likewise/trusted_certs
> pkinit_cert_match = &&<EKU>msScLogin<PRINCIPAL>
> pkinit_eku_checking = kpServerAuth
> pkinit_win2k = true
> pkinit_win2k_require_binding = false
> pkinit_identities = PKCS11:/opt/likewise/lib64/libpkcs11.so
18a30,35
> WI = {
> auth_to_local = RULE:[1:$0\$1](^WI\\.*)s/^WI/NTNET/
> auth_to_local = RULE:[1:$0\$1](^WI\\.*)s/^WI/NTNET/
> auth_to_local = RULE:[1:$0\$1](^CAN\.WI\\.*)s/^CAN\.WI/NTCAN/
> auth_to_local = DEFAULT
> }
22a40,41
> .wi = WI
> .can.wi = CAN.WI
30a50,55
> mappings = NTNET\\(.*) $1@WI
> validate = true
> }
> httpd = {
> mappings = NTNET\\(.*) $1@WI
> reverse_mappings = (.*)@WI NTNET\$1
{code}

> >         at com.sun.security.auth.module.*Krb5LoginModule.promptForName*

> > (Krb5LoginModule.java:767)
> >         at
> > com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:646)
> >         at
> > com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:559)
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >         .....
> >         at
> > com.jcraft.jsch.jgss.GSSContextKrb5.init(GSSContextKrb5.java:129)
> >         at
> > com.jcraft.jsch.UserAuthGSSAPIWithMIC.start(UserAuthGSSAPIWithMIC.java:135)

> >         at com.jcraft.jsch.*Session.connect*(Session.java:419)

>
> > So it seems the SSH connection is trying to prompt for username/password
>
> > do you have Private key auth configured successfully so you can ssh to the
> > host without entering a password?
>

> ...
>
> read more »

[Greg Schueler]

Looking at the commandline process you had running, I see this:   -Djava.security.auth.login.config=/etc/rundeck/jaas-loginmodule.conf 

is that where you have configured kerberos for the server?

That security property is supposed to be used for the server, and I wonder if it is conflicting with Jsch's SSH implementation when you execute the commandline tool.

what is the value of the RDECK_JVM environment variable when you execute the client?

[hom]

No, each *clients* kerberos information is modified in /etc/krb5.conf
via the open likewise installer, all of which was run before rundeck
was ever installed on the *server*.

The /etc/rundeck/jaas-loginmodule.conf hasn't been touched since
rundeck was installed on the server. It contains:
{code}
RDpropertyfilelogin {
org.mortbay.jetty.plus.jaas.spi.PropertyFileLoginModule required
debug="true"
file="/etc/rundeck/realm.properties";
};
{code}

To answer the other question, I don't see where RDECK_JVM is being
set. Where should it be set?

> ...
>
> read more »

[hom]

I've run a remote ssh command from the rundeck server to a client with
likewise installed using ssh -v (output below). Is there a way to get
an equivalent output verbosity using the java ssh implementation
rundeck uses? The "Unknown code krb5 195" output below is interesting
too ...

{quote}
[rundeck@ctier ~]$ ssh -v ctier@xymon hostname
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to xymon [172.20.90.51] port 22.
debug1: Connection established.
debug1: identity file /home/rundeck/.ssh/identity type -1
debug1: identity file /home/rundeck/.ssh/id_rsa type -1
debug1: identity file /home/rundeck/.ssh/id_dsa type 2
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version
OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xymon' is known and matches the RSA host key.
debug1: Found key in /home/rundeck/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-
mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more
information
Unknown code krb5 195

debug1: Unspecified GSS failure. Minor code may provide more
information
Unknown code krb5 195

debug1: Unspecified GSS failure. Minor code may provide more
information
Unknown code krb5 195

debug1: Next authentication method: publickey
debug1: Trying private key: /home/rundeck/.ssh/identity
debug1: Trying private key: /home/rundeck/.ssh/id_rsa
debug1: Offering public key: /home/rundeck/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: hostname
xymon
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0

{quote}

> ...
>
> read more »

[hom]

More details on this:

native ssh commands with key exchange, ssh first tries gssapi which
fails, then uses publickey which works
presumably, commands dispatched via the gui using openssh do the same
thing
ctl-exec from the command line using jsch hang on a password prompt
while trying gssapi

setting "GSSAPIAuthentication no" in sshd_config on the remote works
around the problem

jsch doesn't handle the gssapi error the same way openssh does. In
the verbose ssh connection, the error is:

debug1: Unspecified GSS failure. Minor code may provide more
information
Unknown code krb5 195

> > > > >    ...
>
> read more »