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

Alex Sherwin commented on SSHD-1266:
------------------------------------

I can sympathize with that sentiment, but I would like to point out there are 
some great use-cases for having native JVM code which can generate OpenSSH 
Certificates (which, is already merged in MINA, this PR is just about fixing 
encoding of the optional critical options data)

For example, one can (.. and has) used this functionality to build a security 
gateway application around SSH certificate based access (covering terminal 
sessions, file transfers and port forwarding) using MINA as client code only 
(targeting OpenSSH server's on VMs.

Being able to generate OpenSSH Certificates from JVM code greatly simplifies 
this, beforehand we had to drop down to using ssh-keygen, which is can be 
painful to orchestrate (doesn't support streaming data in/out), and hard to do 
in a strictly secure mechanism with copying around files, permissions etc. 

Moving that process in-band in the JVM is a great boon to all kinds of use 
cases where a complex client application wants to generate OpenSSH Certificates 
for time-boxed, limited capability credentials on-demand

> OpenSSH certificate is not properly encoded when critical options are included
> ------------------------------------------------------------------------------
>
>                 Key: SSHD-1266
>                 URL: https://issues.apache.org/jira/browse/SSHD-1266
>             Project: MINA SSHD
>          Issue Type: Bug
>    Affects Versions: 2.8.0
>            Reporter: Zeljko Vukovic
>            Priority: Minor
>          Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> If critical options are included when OpenSSH certificate is created same 
> can't be read with OpenSSH.
>  
> In oder to reproduce issue we can use existing test 
> [https://github.com/apache/mina-sshd/blob/master/sshd-core/src/test/java/org/apache/sshd/certificates/GenerateOpenSSHClientCertificateTest.java#L152]
>  and just add critical options (as in the example bellow)
> {code:java}
> final OpenSshCertificate signedCert = 
> OpenSshCertificateBuilder.userCertificate()
>                .serial(0L)                
>                .publicKey(clientPublicKey)                
>                .id("user01")                
>                .principals(Collections.singletonList("user01"))               
>  
>                .criticalOptions(Arrays.asList(
>                         new 
> OpenSshCertificate.CertificateOption("force-command", "wget url"),
>                         new 
> OpenSshCertificate.CertificateOption("source-address", "127.0.0.1/32")))      
>     
>                .extensions(Arrays.asList(
>                         new 
> OpenSshCertificate.CertificateOption("permit-X11-forwarding"),
>                         new 
> OpenSshCertificate.CertificateOption("permit-agent-forwarding"),
>                         new 
> OpenSshCertificate.CertificateOption("permit-port-forwarding"),
>                         new 
> OpenSshCertificate.CertificateOption("permit-pty"),
>                         new 
> OpenSshCertificate.CertificateOption("permit-user-rc")))
>                 .sign(caKeypair, signatureAlgorithm); {code}
>  
> Once we check such certificate we get following error 
> {code:java}
> > ssh-keygen -L -f  /path/to/cert.pub 
> Type: ecdsa-sha2-nistp256-cert-...@openssh.com user certificate
>         Public key: ECDSA-CERT 
> SHA256:0ITcONLKI/H/FNpXZVZMaEYB0STXD4BQNBkSSuDpk5U
>         Signing CA: ECDSA SHA256:KPz5LunqQBL9hWJx5eDk11T16anJCn40d/g480PfuKw 
> (using ecdsa-sha2-nistp384)
>         Key ID: "user01"
>         Serial: 0
>         Valid: forever
>         Principals: 
>                 user01
>         Critical Options: 
> show_options: buffer error: string is too large {code}
> and similar for the other cert types(RSA, EC, Ed25519).
> I was tracing this issue and it looks like related to this code 
> [https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/util/buffer/Buffer.java#L840]
>  but I was not able to figure out what exactly.  
>  
> Interesting is that parsing certificate is working as expected 
> [https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/util/buffer/Buffer.java#L370]
> from code but also even if I create certificate directly with ssh-keygen
> {code:java}
> ssh-keygen -t rsa -b 4096 -f user_ca -C user_ca
> ssh-keygen -f user-key -b 4096 -t rsa
> ssh-keygen -s user_ca -I certN -n user -O source-address="127.0.0.1/32" -O 
> force-command="wget url" -V +10d user-key.pub {code}
>  
> [~alex.sher...@gmail.com] / [~twolf]  please if any hints what to check(it 
> looks to me that there is something wrong with encoding certificate option 
> data 
> [https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/util/buffer/Buffer.java#L838-L845]
>  , like these tuples should be written somehow differently) I am more than 
> open to support and create PR.
> This is working as expected for extensions as these are all empty(do not have 
> data) but once we include critical options which have data than there is 
> mentioned failure 
> ([https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.certkeys#L221-L268]
>  ).
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Reply via email to