[ 
https://issues.apache.org/jira/browse/SSHD-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575060#comment-14575060
 ] 

Guillaume Nodet edited comment on SSHD-473 at 6/5/15 7:43 PM:
--------------------------------------------------------------

The only point I do really get is that you don't understand.

Mina SSHD provides a client and a server supporting the SSHD protocol.  You can 
use the client only (similar to jsch or other java ssh client libraries) to 
connect to any existing ssh server (native to whatever).  You can use the mina 
sshd server and connect to it from any client (be it mina, jsch, native client 
or whatever).  You can of course use the sshd library for both the client and 
server.  Both the client and server share a lot of code (that's why they are in 
the same library) but they are independent.

But the mina sshd server is in no way a wrapper.  It's a full blown 
implementation of the server side ssh layer, same as your native OS ssh server. 
 If you use mina sshd server, you need to provide your own custom 
PasswordAuthenticator to actually perform the authentication, it won't delegate 
to the OS.  For the shell, it can be implemented in java or delegated by 
launching the {{/bin/sh}} executable on the OS, but that's a different problem. 
 The main use case for the *server* is when you have a java based server and 
you want to connect securely and execute commands inside it, hence the custom 
security layer and custom commands which are usually implemented.

Again, if you want an integration with the native OS security layer and the 
native shell, why don't you just use the client part and connect to your native 
sshd server ?




was (Author: gnt):
The only point I do really get is that you don't understand.

Mina SSHD provides a client and a server supporting the SSHD protocol.  You can 
use the client only (similar to jsch or other sshd client libraries) to connect 
to any existing ssh server (native to whatever).  You can use the mina sshd 
server and connect from any client (be it mina, jsch, native client or 
whatever).  You can of course use the sshd library for both the client and 
server.  Both the client and server share a lot of code (that's why they are in 
the same library) but they are independent.

But the mina sshd server is in no way a wrapper.  It's a full blown 
implementation of the server side ssh layer, same as your native OS ssh server. 
 If you use mina sshd server, you need to provide your own custom 
PasswordAuthenticator to actually perform the authentication, it won't delegate 
to the OS.  For the shell itself, it can be implemented in java or delegated by 
launching the {{/bin/sh}} executable on the OS, but that's a different problem. 
 The main use case for the *server* is when you have a java based server and 
you want to connect securely and execute commands inside it, hence the custom 
security layer and custom commands which are usually implemented.

Again, if you want an integration with the native OS security layer and the 
native shell, why don't you just use the client part and the native sshd server 
?



> PasswordAuthentifikation
> ------------------------
>
>                 Key: SSHD-473
>                 URL: https://issues.apache.org/jira/browse/SSHD-473
>             Project: MINA SSHD
>          Issue Type: Bug
>    Affects Versions: 0.14.0
>         Environment: Windows 7, Java 8, Eclipse JUNO
>            Reporter: Jochen Seliger
>            Priority: Critical
>         Attachments: Loggs.doc, SSHDPasswordAuthenticator.java, 
> SSHDPasswordAuthenticator.java, SSH_SERVER.java, SSH_SERVER.java, 
> createSSHDClient-method.doc
>
>
> I run the sshd and the ssh client both on the windos mashine.
> The sshd I start on port 8000 and with password authentificator ans an own 
> atthenicator class, which shall shoe a messagebox when envoced.
> The client I start aftercreating it as SshClient.setUpDefaultClient(); 
> without stting any factury with the statement ClientSession session = 
> client.connect("Jochen","192.168.100.13",8000).await().getSession(); (Jochen 
> is an existing user on the mashine).
> But till shellChannel I can proceed only when setting after session creation 
> session.addPasswordIdentity("Jochen"); (it is tha same user as provided at 
> session creation)
> There is no functionality to set the password.
> The method authPassword is depreciated.
> 1. My first question: How to proceed th use PasswordAuthentification?
> As stated I can proceesd til ssh-Shell, but the server is logging at a first 
> run an autentification failure and at a second run authentification success:
> Mai 22, 2015 12:14:21 PM org.apache.sshd.client.session.ClientSessionImpl 
> readIdentification
> INFORMATION: Server version string: SSH-2.0-SSHD-CORE-0.14.0
> Mai 22, 2015 12:14:22 PM 
> org.apache.sshd.client.keyverifier.AcceptAllServerKeyVerifier verifyServerKey
> WARNUNG: Server at /192.168.100.13:8000 presented unverified DSA key: 
> e4:76:f3:c2:15:64:7f:e4:5f:b7:86:35:a5:3e:85:35
> Mai 22, 2015 12:14:22 PM org.apache.sshd.common.session.AbstractSession 
> doHandleMessage
> INFORMATION: Dequeing pending packets
> Mai 22, 2015 12:14:22 PM 
> org.apache.sshd.client.session.ClientUserAuthServiceNew processUserAuth
> INFORMATION: Received SSH_MSG_USERAUTH_FAILURE
> Mai 22, 2015 12:14:22 PM 
> org.apache.sshd.client.auth.UserAuthKeyboardInteractive process
> INFORMATION: Received Password authentication  en-US
> Mai 22, 2015 12:14:22 PM 
> org.apache.sshd.client.session.ClientUserAuthServiceNew processUserAuth
> INFORMATION: Received SSH_MSG_USERAUTH_SUCCESS
> ShellChannell opened
> Microsoft Windows [Version 6.0.6001]
> Copyright (c) 2006 Microsoft Corporation. Alle Rechte vorbehalten.
> C:\Users\Jochen\workspace\USF_SSH_WS>
> allthoug I did not provide an password.
> 2. Why thes two runs are processed?
> 3. Why the first run fails and the second one succedes?
> 4. How to proceede to get a functioning password and keypair authentication?
> Regards
> Jochen Seliger



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to