SSH libraries: SSH vs TLS; libssh
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Adamantiadis, Aris
SSH libraries: what they can do for you, and how different SSH is from TLS/SSL. Specific case of libssh : its API in two words, features and roadmap.
 So my name is Saris. I'm going to present you a few things about SSH and TNS SSL and in particular of her at the SSH. So never be too obsessed with SSH protocol. So a few words of what might say. Okay, I'm a security and cryptography analyst. I came to just as well work for the lead SSH projects. I work at BellNet which is research and research and education internet provider. So we provide internet connectivity to research network and in particular for them this year. There is a job booth so if you have a minute just go there. That's from my website. Okay, I'm very good. I like you. Sorry? Just tell me what you want to make slide. Okay. Press David and that's it. Yes, but my whole slides are interactive so I'm really good. Okay. So I'll start by speaking a little about the differences between SSL and SSH because I'm not sure it's here for everyone and it's a good start to decide if you are going to use SSL or SSH for your next cryptographic application. And then I will talk a little about our project and how it works and how to use it in start. So you can start coding your own SSH clients when going outside of this field. So we know SSL, you know TLS. How many people know the difference between SSL and TLS? In fact, there is almost no difference. Yes, the case starting from 3.1 SSL is the same as TLS, 1.1 but I think it's about the same as that. Okay, there is SSH1 which is almost legacy. It has plenty of hold inside it so nobody uses it anymore. Maybe some hold Cisco routers. Then SSH2, I imagine most of you already use SSH. So what's SSL and TLS? The name is Secure Circuit Layer, Transport Layer Security. The idea is really that it's a secure transport. The goal is to transport data from A to B in a secure efficient way. So it was developed by Netscape. I think version 1 was broken during the presentation. Let's say they came with the version 2.5. Okay, it's very used for HTTPS, HTTPS. I think you know it. Something that's interesting is that the security model of SSL and TLS is based on Netscape online certificates. So that certificates you buy had some CD providers for a lot of money generally and they say you are to be trusted because you gave them money and a proof that you are who you are. Sometimes, yes. There are lots of implementations so the best known are PENSSL, GME TLS. If you are using Firefox, you are using NSS. There will be talk about the BI SSL as well. I think Windows has its own version. I think a complete list will include sort of 4 to 5. So it's very well used. Okay, what about SSH? SSH is a secure shell. So the primary use of SSH was to provide an interactive shell to a server. The goal was to replace TermNet. That wasn't a secure right. Okay, yes. The first version was SSH1 which was almost free software. The OpenSSH team took the code when it was still free and they've made the great OpenSSH project. So it's defined in RFCs. It's recent, quite recent. I think it has been done one or two years ago. So some of the features of SSH, that how well the general scope of SSL are that, well, a secure transfer of the code, but you have that with SSL as well. But we have several channels for communication. So it's possible to have parallel channels of communication in the same SSH stream. It's important. Autunication is omitted inside the protocol. So it's very interesting. I will go to the next one. Okay, so it was done for the shell handling. So everything that goes around Terminals, Terminals size, X11 for writing, and so that's embedded into the protocol. And there is also dedicated a five transfer protocol that is a lot different from FTP because it's based in a binary protocol. I won't go into the detail because it's a little out of the point. Okay. What are you looking into? A security protocol or a security transport protocol? Of course, you are looking for integrity. You do not want that someone with a data can change something in your data stream and cover your files or inject commands into your shell. So a good thing for a transport protocol is that any tampering is detected and if possible, it's avoided. You look also at availability. Availability is a resistance against the denial of service attacks and the fact that you have the most time as possible. So it's not possible to shut down your connection to make it look slow, to stop you from connecting to your server and so. Something you want as well, and I think it's the best known functionality of SSH and TLS, it's confidentiality. You don't want anyone to know what you've done on your integration and your channel. So nobody can interrupt you. And that's the increase that you are sure who you are speaking to. That's very important because if you are sure you are talking into a private and secure channel without anyone after you, but you are not actually speaking to the group person, it has no interest. So it must be embedded into the security of your protocol. Most of implementation of SSH do the same, apply the same solution for all of these programs. So integrity is verified through strong hash marks, cryptographic mechanism that makes possible to verify that a packet is not going to be tampered with. Another problem is that if somebody changes a byte or a bit, flips a bit into your stream, SSH or TLS will detect it and shut down the communication. So much for the reliability, it's still based on TCP which is an insecure protocol. So anybody can send an RST, anybody can send a packet containing garbage and the application running SSH or TLS will not be able to recover from such a situation. So if you are looking for reliability, SSH or TLS is not your solution. Maybe you should look at something around top of IP like IP sake. Okay, confidentiality, it's actually a well-known problem. So strong cifers, a key exchange, and of course, the authentication on the key exchange. The key exchange is the way by which the server and the client agree on a common symmetric key to use for the communication. And by way of another, the server is mixed up. I am that server and my proof is that I signed the key exchange first. Okay. So the main goal of server authentication is to avoid the man in the middle attack. Man in the middle attack is when someone runs right between your server and the client and they fix the server. So in TLS, well, I won't go a lot in the details because I think it's not really the topic right now. But there are a lot of differences between SSH and TLS. For instance, TLS is using X5 or 9 certificates where SSH only use your key pages. So you commit for the first time on your server and you get a hash. Do you trust the server to have that hash with a critical NG5 or a section 1 hash of the public key? And you say yes or no. And then you store it on a computer and you add it. And you store it on a non-host file which is a big difference between SSH which uses a twist chain to verify that the host is legitimate. In addition, their open SSH started using certificates. They're not X5 or 9 certificates but their own certificates on the ground back. They started implementing their own certificates at first because they felt the need for certificates because people having huge farms with hundreds of servers don't take time to exchange and load those files. But they have added the X5 or 9 thing because they felt a lot of vulnerabilities could come from just parsing if they're online. So X5 or 9 is maintained by Ruben Petrov as the server's hash out of the tree. And the certificate support that it's added in open SSH since a few versions back now is really much, much simpler. It's just the keys and just signatures on keys. And they intentionally did not use X5 or 9 because it's complicated. Yes, it's really complicated. It's easy to make errors. But it's new still. So let's take a look. Okay. Now, something that is important as well is that the server must sometimes know the identity of the client, the guy who's typing things in the queue. So with TLS, you don't have so much choice. As for you must use a certificate as well, of course you can use a smart card with the PkC as well. But if you wish to use passwords, OTP, two factors, and see so, you are left to use the application layer. So HTTP or FTP or something. There is nothing integrated right into TLS. And that's a big difference between SSH and TLS that's in SSH. Everything is done inside the protocol to just to... Yeah. You use PSA now. PSA? Yeah, we should be able to do that. That's interesting too. I'm not sure you can do it with SSH. Okay. So, interesting. Okay. So, I'm sorry. So, you can do it with the... The diagram is not really nice. I made it in the memory. So, that's a little bit different between SSH and TLS. In SSH, you have several channels that can be used to communicate with the server. And each channel is dedicated to a service. And all of the channels are protected using authentication layer that you can use to communicate with the server. So, you wish to use OTP authentication, just use keyboard to direct it. So, it's possible to have to send a channel to the client with the client using the host. So, GSSATI, which can be used for cable routes and integration as well. So, what are you going to choose? I'd say it depends on your trust model. For you, a CA model is easier if a lot of people are going to use your service and there is no problem that a channel can forge a certificate for you. Then, TLS is probably the best protocol for you. So, it's a great way to do it. That's one new scheme. You'd use SSH if you have previous of a mass-symmetrical protocol. So, there's the servers and the clients. They are mostly the same, but they are different in the implementation. The host authentication is very simple. So, most users will just have to become accept the first time and that's okay. Yes, for SSH you can find it mostly everywhere. It would be a good idea to actually implement SSH for the access to some widely deployed system services like IMA. Why couldn't a user have access to IMA using all the advantages of the authentication feature of SSH? So, it's time to start. I will have to go to her realtor. So, that's a list of existing SSH and the other one. Actually, I did not test all of them and I can guarantee the whole thing. Okay. Now, I will speak in detail of SSH. So, it's just started like a simple SSH and I started putting some code around to make a library for SSH and then it became a little more serious. Some people were contributing. Andreas, which is a game in 2008 and made a lot of work on the code with a certain infrastructure. So, now, the SSH is around 33,000 lines of code. So, it's one sort of a business agent and it's used by some free software like QTTA. Okay. So, interesting feature of SSH is that it's client-side and server-side as well. So, you can implement both sides of the communication. There are support for SSH2 and SSH1. You can authenticate using passwords that's the most used of SSH but also keyboard iterative. For instance, if you pan on your system, it will rely on keyboard iterative. Public key. So, if you have public key on your system, it will try to authenticate using it. It will also try to authenticate using the SSH agent and the good thing is that if your SSH agent is already compatible with PKCS level, you can also authenticate using the SSH agent. Okay. So, we have some work, a lot of documentation for SSH because we felt it was really important for the library to be correctly documented. So, if you want to work the API documentation and the oxygen documentation is available and that's where you are at. There is also a tutorial that explains all the basic steps to get SSH done. I will show you a few steps of course. Okay. There are also a lot of examples. It's not intended to be really real. That's a look on the main page of the tutorial. So, there is an explanation of how to connect, how to authenticate, how to open a remote shell, SFP, ESCP, provided in connection, so it's a CEP provided, how to handle trades and you are currently writing a tutorial on the server. Okay. We are developing SSH on our own, on our own infrastructure. So, we are using Git with mine and what's interesting is that we are testing a test panel with night verse. So, every night there is a build that is done on several targets. Tests are run using algorithms too and so we get a new, each time we work something. So, if you can have a preview, that's all we've got. So, all the properties used for the SSH, now we have Windows as well and we get a lot of bugs fixed just by using this and getting the most reported by the end. So, it's very, very interesting. Another thing that is interesting is the coverage of the test. So, all the tests cover some part of the code. Right now, you can see it's still orange because we only have 30% of the code that is correctly tested but we only started one or two years ago to do some systematic testing. So, we see not that bad. Okay. So, now the details of the coverage. Okay. That's the sample of how to connect to SSH. Actually, it's pretty straightforward. So, you just create an object for the decision. Just tell, I want to connect to localhost. I want to use the login Paris icon. And then I check the written code to see if the connection was successful. Okay. Then I need to check if the server is known. So, just like on the SSH when you connect to your host, you get a neural message. If you are going to connect to a server, use KSChange. That's the thing. You just get a neural code that tells what the status of the host will be known as. So, server known. Okay. Everything is good. The host is known. Server known changed. That means the key changed. That's very bad. Server from the order that means the server advertised the DSLK for instance, that you only know the RSEK. Final phone and server not known. That's the first time you connect to the server or that you are using SSH. In that case, you just have to update the file. So, question. Yes. Using the open SSH, the same format. Yes. Same format. Same file. Passing it the same way. We pass the configuration file from SSH. It's not complete, but we are, well, I say 70% no 30% no 30% I'm not interested. No, you need to authenticate. Well, there is an interesting code that is a reason for user who's a top of the key, which simply try all the public key, see, represent Italy and will try to connect to you. If you still need to connect to the password, there is a straightforward password authentication code. But of course, there are a lot of, well, yes, I will hurry. There are a lot of other codes that can be made for lower level authentication. Okay. Now, you want to just execute something on a channel, but you have to create a channel to open it. So, you have to pass the server if you can access it. Normally, you should look at the error codes each time you do SSH code, of course, but it was stripped down for the example. So, you just request an execution of the code and then you read the response and when you are done, you close the channel. So, it's pretty straightforward. Now, what we are looking for the future, we are planning to become 100% SSH. So, we want to implement 100% of the entity protocol. We want to be fully integrals on code that is right now, a lot of focus remains in that direction, but it's not really that. So, we want to over-connect the IPI, which will probably be really amounted to, okay, I would like to go into other limits, but still something to do. So, the PKS-S11 is a hot topic because we are here just to speak on PKS-S11. Right now, you can use the SSH and the PKS-S11 for using the SSH agent, but the support will be ready in one month or two after that. Okay. And, of course, we have some work to do on the SSH server part of the SSH. Okay, I'm just in time. I don't know if there are some questions. Yes? Is it a solo or a client service? Both. So, the client-side API is more evolved than the server-part API, but as far as I know, the SSH is the only SSH variant that does the server part. That's why did you implement it as a separate project from SSH? Taking the library now of SSH slowly? Probably not invented here, some group. Sorry, our comment to that is that the OpenSSH codebase is not really... Well, you could make a library out of it, I guess, but it's not made as a library. It's not the same concept. The concept in a library is that you must have an external API to access to the whole elements, while in OpenSSH everything is done to work inside OpenSSH, so it's not really the same. Maybe we could share 50% of the code, not that much. I have a question. Which is the most widespread user of the SSH? The KDE project. So, if you are using KDE on the shoes or so, a Wuntu, and access using Dolphin, SFTP further somewhere on the server, you are using the SSH as a backend. That's actually a... It was a trick question because I think I once shared with you a document that said that the SSH is the most used client for some portnet. That's right. That's right. We have the market leader there. We want to start somewhere. No hanging fruit. Thank you.
 So my name is Saris. I'm going to present you a few things about SSH and TNS SSL and  in particular of her at the SSH. So never be too obsessed with SSH protocol. So a few words  of what might say. Okay, I'm a security and cryptography analyst. I came to just as well  work for the lead SSH projects. I work at BellNet which is research and research and  education internet provider. So we provide internet connectivity to research network  and in particular for them this year. There is a job booth so if you have a minute just go there.  That's from my website. Okay, I'm very good. I like you.  Sorry?  Just tell me what you want to make slide.  Okay.  Press David and that's it.  Yes, but my whole slides are interactive so I'm really good.  Okay.  So I'll start by speaking a little about the differences between SSL and SSH because I'm  not sure it's here for everyone and it's a good start to decide if you are going to use  SSL or SSH for your next cryptographic application. And then I will talk a little about our project  and how it works and how to use it in start. So you can start coding your own SSH clients  when going outside of this field. So we know SSL, you know TLS. How many people know the  difference between SSL and TLS? In fact, there is almost no difference. Yes, the case starting  from 3.1 SSL is the same as TLS, 1.1 but I think it's about the same as that. Okay, there  is SSH1 which is almost legacy. It has plenty of hold inside it so nobody uses it anymore.  Maybe some hold Cisco routers. Then SSH2, I imagine most of you already use SSH. So what's  SSL and TLS? The name is Secure Circuit Layer, Transport Layer Security. The idea is really  that it's a secure transport. The goal is to transport data from A to B in a secure  efficient way. So it was developed by Netscape. I think version 1 was broken during the presentation.  Let's say they came with the version 2.5. Okay, it's very used for HTTPS, HTTPS. I think  you know it. Something that's interesting is that the security model of SSL and TLS is  based on Netscape online certificates. So that certificates you buy had some CD providers  for a lot of money generally and they say you are to be trusted because you gave them  money and a proof that you are who you are. Sometimes, yes. There are lots of implementations  so the best known are PENSSL, GME TLS. If you are using Firefox, you are using NSS.  There will be talk about the BI SSL as well. I think Windows has its own version. I think  a complete list will include sort of 4 to 5. So it's very well used. Okay, what about  SSH? SSH is a secure shell. So the primary use of SSH was to provide an interactive shell  to a server. The goal was to replace TermNet. That wasn't a secure right. Okay, yes. The  first version was SSH1 which was almost free software. The OpenSSH team took the code when  it was still free and they've made the great OpenSSH project. So it's defined in RFCs.  It's recent, quite recent. I think it has been done one or two years ago. So some of  the features of SSH, that how well the general scope of SSL are that, well, a secure transfer  of the code, but you have that with SSL as well. But we have several channels for communication.  So it's possible to have parallel channels of communication in the same SSH stream. It's  important. Autunication is omitted inside the protocol. So it's very interesting. I will  go to the next one. Okay, so it was done for the shell handling. So everything that goes  around Terminals, Terminals size, X11 for writing, and so that's embedded into the protocol.  And there is also dedicated a five transfer protocol that is a lot different from FTP because  it's based in a binary protocol. I won't go into the detail because it's a little out  of the point. Okay. What are you looking into? A security protocol or a security transport  protocol? Of course, you are looking for integrity. You do not want that someone with  a data can change something in your data stream and cover your files or inject commands into  your shell. So a good thing for a transport protocol is that any tampering is detected  and if possible, it's avoided. You look also at availability. Availability is a resistance  against the denial of service attacks and the fact that you have the most time as possible.  So it's not possible to shut down your connection to make it look slow, to stop you from connecting  to your server and so. Something you want as well, and I think it's the best known functionality  of SSH and TLS, it's confidentiality. You don't want anyone to know what you've done  on your integration and your channel. So nobody can interrupt you. And that's the  increase that you are sure who you are speaking to. That's very important because if you are  sure you are talking into a private and secure channel without anyone after you, but you  are not actually speaking to the group person, it has no interest. So it must be embedded  into the security of your protocol. Most of implementation of SSH do the same, apply the  same solution for all of these programs. So integrity is verified through strong hash  marks, cryptographic mechanism that makes possible to verify that a packet is not going  to be tampered with. Another problem is that if somebody changes a byte or a bit, flips  a bit into your stream, SSH or TLS will detect it and shut down the communication. So much  for the reliability, it's still based on TCP which is an insecure protocol. So anybody  can send an RST, anybody can send a packet containing garbage and the application running  SSH or TLS will not be able to recover from such a situation. So if you are looking for  reliability, SSH or TLS is not your solution. Maybe you should look at something around top  of IP like IP sake. Okay, confidentiality, it's actually a well-known problem. So strong  cifers, a key exchange, and of course, the authentication on the key exchange. The key  exchange is the way by which the server and the client agree on a common symmetric key  to use for the communication. And by way of another, the server is mixed up. I am that  server and my proof is that I signed the key exchange first. Okay. So the main goal of  server authentication is to avoid the man in the middle attack. Man in the middle attack  is when someone runs right between your server and the client and they fix the server. So  in TLS, well, I won't go a lot in the details because I think it's not really the topic  right now. But there are a lot of differences between SSH and TLS. For instance, TLS is  using X5 or 9 certificates where SSH only use your key pages. So you commit for the  first time on your server and you get a hash. Do you trust the server to have that hash  with a critical NG5 or a section 1 hash of the public key? And you say yes or no. And  then you store it on a computer and you add it. And you store it on a non-host file which  is a big difference between SSH which uses a twist chain to verify that the host is legitimate.  In addition, their open SSH started using certificates. They're not X5 or 9 certificates  but their own certificates on the ground back. They started implementing their own certificates  at first because they felt the need for certificates because people having huge farms with hundreds  of servers don't take time to exchange and load those files. But they have added the X5  or 9 thing because they felt a lot of vulnerabilities could come from just parsing if they're online.  So X5 or 9 is maintained by Ruben Petrov as the server's hash out of the tree. And the  certificate support that it's added in open SSH since a few versions back now is really  much, much simpler. It's just the keys and just signatures on keys. And they intentionally  did not use X5 or 9 because it's complicated. Yes, it's really complicated. It's easy to  make errors. But it's new still. So let's take a look.  Okay. Now, something that is important as well is that the server must sometimes know  the identity of the client, the guy who's typing things in the queue. So with TLS, you  don't have so much choice. As for you must use a certificate as well, of course you can  use a smart card with the PkC as well. But if you wish to use passwords, OTP, two factors,  and see so, you are left to use the application layer. So HTTP or FTP or something. There  is nothing integrated right into TLS. And that's a big difference between SSH and TLS  that's in SSH. Everything is done inside the protocol to just to...  Yeah. You use PSA now.  PSA?  Yeah, we should be able to do that. That's interesting too. I'm not sure you can do it  with SSH. Okay. So, interesting. Okay. So, I'm sorry.  So, you can do it with the... The diagram is not really nice. I made it in the memory.  So, that's a little bit different between SSH and TLS. In SSH, you have several channels  that can be used to communicate with the server. And each channel is dedicated to a service.  And all of the channels are protected using authentication layer that you can use to  communicate with the server. So, you wish to use OTP authentication, just use keyboard  to direct it. So, it's possible to have to send a channel to the client with the client  using the host. So, GSSATI, which can be used for cable routes and integration as well.  So, what are you going to choose? I'd say it depends on your trust model. For you, a  CA model is easier if a lot of people are going to use your service and there is no problem  that a channel can forge a certificate for you. Then, TLS is probably the best protocol  for you. So, it's a great way to do it. That's one new scheme. You'd use SSH if you have  previous of a mass-symmetrical protocol. So, there's the servers and the clients.  They are mostly the same, but they are different in the implementation. The host authentication  is very simple. So, most users will just have to become accept the first time and that's  okay. Yes, for SSH you can find it mostly everywhere. It would be a good idea to actually implement  SSH for the access to some widely deployed system services like IMA. Why couldn't a user  have access to IMA using all the advantages of the authentication feature of SSH? So,  it's time to start. I will have to go to her realtor. So, that's a list of existing SSH  and the other one. Actually, I did not test all of them and I can guarantee the whole  thing. Okay. Now, I will speak in detail of SSH. So, it's just started like a simple SSH  and I started putting some code around to make a library for SSH and then it became a little  more serious. Some people were contributing. Andreas, which is a game in 2008 and made  a lot of work on the code with a certain infrastructure. So, now, the SSH is around 33,000  lines of code. So, it's one sort of a business agent and it's used by some free software  like QTTA. Okay. So, interesting feature of SSH is that it's client-side and server-side  as well. So, you can implement both sides of the communication. There are support for  SSH2 and SSH1. You can authenticate using passwords that's the most used of SSH but also  keyboard iterative. For instance, if you pan on your system, it will rely on keyboard  iterative. Public key. So, if you have public key on your system, it will try to authenticate  using it. It will also try to authenticate using the SSH agent and the good thing is  that if your SSH agent is already compatible with PKCS level, you can also authenticate  using the SSH agent. Okay. So, we have some work, a lot of documentation for SSH because  we felt it was really important for the library to be correctly documented. So, if you want  to work the API documentation and the oxygen documentation is available and that's where  you are at. There is also a tutorial that explains all the basic steps to get SSH done.  I will show you a few steps of course. Okay. There are also a lot of examples. It's not  intended to be really real. That's a look on the main page of the tutorial. So, there  is an explanation of how to connect, how to authenticate, how to open a remote shell,  SFP, ESCP, provided in connection, so it's a CEP provided, how to handle trades and  you are currently writing a tutorial on the server. Okay. We are developing SSH on our  own, on our own infrastructure. So, we are using Git with mine and what's interesting  is that we are testing a test panel with night verse. So, every night there is a build that  is done on several targets. Tests are run using algorithms too and so we get a new, each time  we work something. So, if you can have a preview, that's all we've got. So, all the properties  used for the SSH, now we have Windows as well and we get a lot of bugs fixed just by using  this and getting the most reported by the end. So, it's very, very interesting. Another thing  that is interesting is the coverage of the test. So, all the tests cover some part of  the code. Right now, you can see it's still orange because we only have 30% of the code  that is correctly tested but we only started one or two years ago to do some systematic  testing. So, we see not that bad. Okay. So, now the details of the coverage. Okay. That's  the sample of how to connect to SSH. Actually, it's pretty straightforward. So, you just  create an object for the decision. Just tell, I want to connect to localhost. I want to  use the login Paris icon. And then I check the written code to see if the connection was  successful. Okay. Then I need to check if the server is known. So, just like on the SSH  when you connect to your host, you get a neural message. If you are going to connect to a  server, use KSChange. That's the thing. You just get a neural code that tells what the  status of the host will be known as. So, server known. Okay. Everything is good. The host  is known. Server known changed. That means the key changed. That's very bad. Server from  the order that means the server advertised the DSLK for instance, that you only know the  RSEK. Final phone and server not known. That's the first time you connect to the server or  that you are using SSH. In that case, you just have to update the file. So, question.  Yes. Using the open SSH, the same format. Yes. Same format. Same file.  Passing it the same way. We pass the configuration file from SSH. It's not complete, but we are,  well, I say 70% no 30% no 30% I'm not interested. No, you need to authenticate. Well, there  is an interesting code that is a reason for user who's a top of the key, which simply  try all the public key, see, represent Italy and will try to connect to you. If you still  need to connect to the password, there is a straightforward password authentication  code. But of course, there are a lot of, well, yes, I will hurry. There are a lot of other  codes that can be made for lower level authentication. Okay. Now, you want to just execute something  on a channel, but you have to create a channel to open it. So, you have to pass the server  if you can access it. Normally, you should look at the error codes each time you do SSH  code, of course, but it was stripped down for the example. So, you just request an execution  of the code and then you read the response and when you are done, you close the channel.  So, it's pretty straightforward. Now, what we are looking for the future, we are planning  to become 100% SSH. So, we want to implement 100% of the entity protocol. We want to be  fully integrals on code that is right now, a lot of focus remains in that direction,  but it's not really that. So, we want to over-connect the IPI, which will probably be really amounted  to, okay, I would like to go into other limits, but still something to do.  So, the PKS-S11 is a hot topic because we are here just to speak on PKS-S11. Right now,  you can use the SSH and the PKS-S11 for using the SSH agent, but the support will be ready  in one month or two after that. Okay. And, of course, we have some work to do on the SSH  server part of the SSH. Okay, I'm just in time. I don't know if there are some questions.  Yes?  Is it a solo or a client service?  Both. So, the client-side API is more evolved than the server-part API, but as far as I  know, the SSH is the only SSH variant that does the server part.  That's why did you implement it as a separate project from SSH?  Taking the library now of SSH slowly?  Probably not invented here, some group.  Sorry, our comment to that is that the OpenSSH codebase is not really... Well, you could  make a library out of it, I guess, but it's not made as a library.  It's not the same concept. The concept in a library is that you must have an external  API to access to the whole elements, while in OpenSSH everything is done to work inside  OpenSSH, so it's not really the same. Maybe we could share 50% of the code, not that much.  I have a question. Which is the most widespread user of the SSH?  The KDE project. So, if you are using KDE on the shoes or so, a Wuntu, and access using  Dolphin, SFTP further somewhere on the server, you are using the SSH as a backend.  That's actually a... It was a trick question because I think I once shared with you a document  that said that the SSH is the most used client for some portnet.  That's right. That's right. We have the market leader there.  We want to start somewhere. No hanging fruit.  Thank you.
security_1345_ssh_adamantiadis_hLrIYREh-fg_2_0_875.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_876_1763.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_1764_4199.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_4200_4295.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_4296_4463.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_4464_5339.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_5340_8063.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_8064_8135.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_8136_10283.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_10284_11831.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_11832_14423.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_14424_18023.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_18024_21215.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_21216_21299.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_21300_21491.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_21492_21863.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_21864_22571.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_22572_22679.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_22680_22763.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_22764_23603.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_23604_23723.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_23724_28715.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_28716_31967.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_31968_37295.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_37296_38843.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_38844_40259.png security_1345_ssh_adamantiadis_hLrIYREh-fg_2_40260_44599.png