12 ms·

SwiftNIO SSH

mrtksn 6y ago
I want Swift-on-server to be a thing because context switching from UI to backend development is taxing enough, at least the language and some of the tooling could remain the same. Maybe you can do that with JS+HTML+CSS on the front end and NodeJS on the backend but Swift is such a nice language to work with. Here is Vapor, a web framework made with Swift: https://vapor.codes https://vapor.codes
- aplummer 6y ago
  Its really fun to work with a shared foundation project containing all your Codable objects across the app and backend, then serialize / deserialize between the same actual class - with the transport being nice readable json.
- bartvk 6y ago
  What's your experience with Vapor? Suppose I've got a Linux box with a MySQL database, setup with a couple of tables. Maybe like a messageboard with Users, Posts and Comments. How many days would it take to implement a REST API for that? And a couple of simple web admin screens?
  - mrtksn 6y ago
    Not much, unfortunately. Some of the integrations that I need, like firebase, don't have official frameworks for Swift beyond iOS. For example, I need to be able connect to Firestore and listen continuously for new data and changes so I can fetch them, do some calculations and put the results back on Firestore. I am doing it with NodeJS because of the official support but I have to tell you that it melts my brain when I have to switch to NodeJS way of thinking and back again. If I could have used Vapor, I would have been able to just use some the already implemented algorithms in the user facing App instead of re-implementing everything in again but this time in a NodeJS way.
  - alexashka 6y ago
    It's a joke compared to the ruby on rails or node ecosystem. It is about ecosystems, not languages. Swift's ecosystem is Apple products. If you're not doing that, don't use Swift. You will have to learn and use multiple languages and multiple ecosystems regardless because each ecosystem insists on using its own language and tools. So just use the most popular one for each - it will be the most polished with the fewest number of gotchas. At this point, the clear winners for each ecosystem are Kotlin, Swift, Typescript, C# and C++ if you're doing games. If you write a todo app on each platform, you'll realize you're using the same set of language features with different syntax - that should lessen the anxiety of learning a new language. Once you're free and nimble, you'd have to be nuts to choose anything but the right tool for the job or when in doubt, the most popular.
    - deleted 6y ago
      [deleted]
    - bartvk 6y ago
      Why do you say it's a joke? Is it because of your experience with it, did you compare features, etc., what is the reason?
  - pjbster 6y ago
    I am in the process of learning Vapor. You need to be comfortable with Swift closures as Vapor uses them everywhere. The SwiftNIO EventLoopFuture is prevalent too and there's a rich API over that which I'm still getting to grips with. To my mind, the best learning resource is Tim Condon et. al.'s Server-Side Swift with Vapor (Ray Wenderlich publishing) but this book needs to be updated. Vapor 4 was released in April but the ORM (Fluent) and template engine (Leaf) weren't upgraded at the same time (June and November, respectively). The first half of the book was updated in September but everything else has been on hold waiting for the Leaf release. My progress through latter part of the book has been slow whilst I translate the examples and wrestle with the compiler errors brought on by my unamiliarity with the above concepts. Tim C. is on the case and is very active and helpful on the forums so I expect the new version of his book will be finished quickly. Anyway, to answer the question: Vapor should be nearly as productive as Rails once you become familiar with it. There's an offically supported MySQL driver for Fluent but no admin screen builder like you might find on Django, for example, so you'd have to put those together yourself.
- oarsinsync 6y ago
  > context switching from UI to backend development is taxing enough, at least the language and some of the tooling could remain the same. I wish I had understood this sooner. Thank you for your comment!
- rnikander 6y ago
  I'd use Swift-on-server for web apps if there were a way to compile Swift to JS, like you can with Kotlin. As far as I know, there is not a good way to do this.
  - Asmod4n 6y ago
    Gave SwiftWasm a try yet?
BillyTheKing 6y ago
I've only very recently started programming in swift (started using it for an ios app) - having done backend development over the past years using primarily node and scala, I gotta say I really really enjoy using swift so far. Don't get me wrong, node and scala are both fun to program in. But swift types (especially) structs that implement immutability throughout, as well as a, let's say, slight 'functional' bias in the language without enforcing it too strictly has really made me want to use it more on the backend as well. I'll definitely check this one out.
- jamil7 6y ago
  It's brilliant for client side applications, it's starts to feel pretty awkward server side. At least right now. I wish the server side team and Vapor people all the best though and hope it gets more traction.
- qaq 6y ago
  Once async gets finalized and lands will be pretty sweet platform for backend development. (provided community develops enough to support decent size ecosystem).
- martontoth 6y ago
  If you like swift you should seriously give kotlin a go. Kotlin on the backend has a quite mature ecosystem (mostly because of its java heritage) and the language is a delight to work with.
  - jpgvm 6y ago
    ^ this but also try out Rust. Swift and Rust have a lot of ideas in common but Rust has a better backend story for the foreseeable future. However I really can't speak more highly of Kotlin, it's the most productive language I have used in large part because of access to the massive JVM ecosystem but with a modern, highly expressive language with amazing tooling (IntelliJ, YourKit, lightRecorder) and excellent performance.
    - 6y ago
est31 6y ago
Personally, I think that Rust is a way better language from a design point of view, but if you want to make a living, then Go and Swift are better.
- jb1991 6y ago
  Rust is also a much bigger investment for the developer to learn and master. Much of the beauty of Rust is in Swift -- heck, the same language designers have worked in both languages.
  - pjmlp 6y ago
    Much of the beauty of ML is in Rust and Swift.
    - TurboHaskal 6y ago
      To some degree, yes. Until you try to write what would be idiomatic SML code in those and the lack of tracing GC comes to bite you. Nevertheless, I guess it's good sum types are making it into the mainstream.
      - pjmlp 6y ago
        Agreed, that is also a reason why I think in the end GC by default (regardless of the algorithm) + affine types will win adoption across mainstream languages, and pure affine type languages like Rust will find their niche on scenarios like those where certifications like MISRA are required, or kernel stuff.
  - est31 6y ago
    You mean Graydon moving from Rust to Swift? On Rust he had a tremendous influence, but while he was on the team, I'm not sure about his influence on Swift. I think Swift is more constrained, having to have good compatibility with objective C. Rust is only compatible with C, and thus has more freedom to do away with decisions that turned out to be bad. Edit: probably Gankra too. IIRC she had an internship at mozilla designing important parts of the Rust standard library then later went to work at Apple.
formerly_proven 6y ago
Listing "EDCSA [sic, maybe wishful thinking it actually is an Ed25519-like scheme instead of ECDSA?] over secp256" (plus siblings) and AES-GCM as "Modern cryptographic primitives only" is genuinely funny. This library does not do Chapoly1305, which has largely been the default choice for SSH since a few years, since it's both fast and secure without dedicated instructions.
- riobard 6y ago
  https://github.com/apple/swift-nio-ssh/issues/48 https://github.com/apple/swift-nio-ssh/issues/48 The dev said it's basically because Swift Crypto API does not support chacha20-poly1305@openssh.com, which is a non-standard construction (compared to chacha20-ietf-poly1305).
- fay59 6y ago
  What are the benefits of chacha20-poly1305 over what’s currently implemented?
jws 6y ago
This sounds like a great addition for servers written in Swift. Pair it with the very easy to use and clean command line arguments package and it should be "trivial" to add management/diagnostic console full of commands to your server. Traditionally for HTTP servers I carve off a URL prefix, e.g. /diagnostics/ or listen on a different port, and make handlers there to let me know how things are going. The downside is that I then have to protect those which collides with whatever other authentication is going on. Moving that to a command console eliminates all those ways to screw up and let evil people into my diagnostic functions. The command line parser package is trivial to use once you get the hang of it and generates acceptable "help" automatically, so you'll end up with a custom CLI of your diagnostic commands with a "help" function to remember them for essentially zero coding and maintenance effort. Now I have to spend all day resisting the urge to weld this into my latest HTTP server to see how it goes. Update: There is an example server in the Sources/NIOSSHServer directory of the repository. 5 files, about 500 lines total to implement a "bash" command executer and a remote port forwarder. Update 2: 50 minutes in and I have an ssh server embedded in my server. Maybe. When I send a command it explodes my process with a Posix.close() to a bad file descriptor tripping a precondition check. So, maybe don't rush this to a live server.
- jws 6y ago
  For anyone following in these footsteps: It works well. I spent more time fighting Swift Argument Parser than the NIOSSH. Fundamentally, there is not a way to pass context down to a command that is run. Fine when you are a whole program reading its commands and everything is implicitly global, but if you have a bunch of SSH connections coming in then just getting the output to the right one needs context. I'm not real happy with my solution, but its clean and it works. Figure two days to get a usable subsystem working. I have a few more things to try to clean up my mess. If it works I'll tidy up the package and publish it.
  - jws 6y ago
    Two days in. The package is useful and mostly complete. See https://github.com/jimstudt/SSHConsole https://github.com/jimstudt/SSHConsole if you have needs, or just want to see another example of using NIOSS on the server. This one includes the public key authentication which in retrospect is trivial-ish.
ogre_codes 6y ago
This is good. I've been searching around for a good SSH client library for an app I've been working on. I've used NMSSH for some time, but its Objective C and I'd like a more swift friendly implementation. Now I just need to dust it off, it's been sitting on that code-shelf over there for 2 years.

I want Swift-on-server to be a thing because context switching from UI to backend development is taxing enough, at least the language and some of the tooling could remain the same. Maybe you can do that with JS+HTML+CSS on the front end and NodeJS on the backend but Swift is such a nice language to work with. Here is Vapor, a web framework made with Swift: https://vapor.codes https://vapor.codes

aplummer 6y ago
Its really fun to work with a shared foundation project containing all your Codable objects across the app and backend, then serialize / deserialize between the same actual class - with the transport being nice readable json.
bartvk 6y ago
What's your experience with Vapor? Suppose I've got a Linux box with a MySQL database, setup with a couple of tables. Maybe like a messageboard with Users, Posts and Comments. How many days would it take to implement a REST API for that? And a couple of simple web admin screens?
- mrtksn 6y ago
  Not much, unfortunately. Some of the integrations that I need, like firebase, don't have official frameworks for Swift beyond iOS. For example, I need to be able connect to Firestore and listen continuously for new data and changes so I can fetch them, do some calculations and put the results back on Firestore. I am doing it with NodeJS because of the official support but I have to tell you that it melts my brain when I have to switch to NodeJS way of thinking and back again. If I could have used Vapor, I would have been able to just use some the already implemented algorithms in the user facing App instead of re-implementing everything in again but this time in a NodeJS way.
- alexashka 6y ago
  It's a joke compared to the ruby on rails or node ecosystem. It is about ecosystems, not languages. Swift's ecosystem is Apple products. If you're not doing that, don't use Swift. You will have to learn and use multiple languages and multiple ecosystems regardless because each ecosystem insists on using its own language and tools. So just use the most popular one for each - it will be the most polished with the fewest number of gotchas. At this point, the clear winners for each ecosystem are Kotlin, Swift, Typescript, C# and C++ if you're doing games. If you write a todo app on each platform, you'll realize you're using the same set of language features with different syntax - that should lessen the anxiety of learning a new language. Once you're free and nimble, you'd have to be nuts to choose anything but the right tool for the job or when in doubt, the most popular.
  - deleted 6y ago
    [deleted]
  - bartvk 6y ago
    Why do you say it's a joke? Is it because of your experience with it, did you compare features, etc., what is the reason?
- pjbster 6y ago
  I am in the process of learning Vapor. You need to be comfortable with Swift closures as Vapor uses them everywhere. The SwiftNIO EventLoopFuture is prevalent too and there's a rich API over that which I'm still getting to grips with. To my mind, the best learning resource is Tim Condon et. al.'s Server-Side Swift with Vapor (Ray Wenderlich publishing) but this book needs to be updated. Vapor 4 was released in April but the ORM (Fluent) and template engine (Leaf) weren't upgraded at the same time (June and November, respectively). The first half of the book was updated in September but everything else has been on hold waiting for the Leaf release. My progress through latter part of the book has been slow whilst I translate the examples and wrestle with the compiler errors brought on by my unamiliarity with the above concepts. Tim C. is on the case and is very active and helpful on the forums so I expect the new version of his book will be finished quickly. Anyway, to answer the question: Vapor should be nearly as productive as Rails once you become familiar with it. There's an offically supported MySQL driver for Fluent but no admin screen builder like you might find on Django, for example, so you'd have to put those together yourself.
oarsinsync 6y ago
> context switching from UI to backend development is taxing enough, at least the language and some of the tooling could remain the same. I wish I had understood this sooner. Thank you for your comment!
rnikander 6y ago
I'd use Swift-on-server for web apps if there were a way to compile Swift to JS, like you can with Kotlin. As far as I know, there is not a good way to do this.
- Asmod4n 6y ago
  Gave SwiftWasm a try yet?

BillyTheKing 6y ago

I've only very recently started programming in swift (started using it for an ios app) - having done backend development over the past years using primarily node and scala, I gotta say I really really enjoy using swift so far. Don't get me wrong, node and scala are both fun to program in. But swift types (especially) structs that implement immutability throughout, as well as a, let's say, slight 'functional' bias in the language without enforcing it too strictly has really made me want to use it more on the backend as well. I'll definitely check this one out.

jamil7 6y ago
It's brilliant for client side applications, it's starts to feel pretty awkward server side. At least right now. I wish the server side team and Vapor people all the best though and hope it gets more traction.
qaq 6y ago
Once async gets finalized and lands will be pretty sweet platform for backend development. (provided community develops enough to support decent size ecosystem).
martontoth 6y ago
If you like swift you should seriously give kotlin a go. Kotlin on the backend has a quite mature ecosystem (mostly because of its java heritage) and the language is a delight to work with.
- jpgvm 6y ago
  ^ this but also try out Rust. Swift and Rust have a lot of ideas in common but Rust has a better backend story for the foreseeable future. However I really can't speak more highly of Kotlin, it's the most productive language I have used in large part because of access to the massive JVM ecosystem but with a modern, highly expressive language with amazing tooling (IntelliJ, YourKit, lightRecorder) and excellent performance.
  - 6y ago

est31 6y ago

Personally, I think that Rust is a way better language from a design point of view, but if you want to make a living, then Go and Swift are better.

jb1991 6y ago
Rust is also a much bigger investment for the developer to learn and master. Much of the beauty of Rust is in Swift -- heck, the same language designers have worked in both languages.
- pjmlp 6y ago
  Much of the beauty of ML is in Rust and Swift.
  - TurboHaskal 6y ago
    To some degree, yes. Until you try to write what would be idiomatic SML code in those and the lack of tracing GC comes to bite you. Nevertheless, I guess it's good sum types are making it into the mainstream.
    - pjmlp 6y ago
      Agreed, that is also a reason why I think in the end GC by default (regardless of the algorithm) + affine types will win adoption across mainstream languages, and pure affine type languages like Rust will find their niche on scenarios like those where certifications like MISRA are required, or kernel stuff.
- est31 6y ago
  You mean Graydon moving from Rust to Swift? On Rust he had a tremendous influence, but while he was on the team, I'm not sure about his influence on Swift. I think Swift is more constrained, having to have good compatibility with objective C. Rust is only compatible with C, and thus has more freedom to do away with decisions that turned out to be bad. Edit: probably Gankra too. IIRC she had an internship at mozilla designing important parts of the Rust standard library then later went to work at Apple.

formerly_proven 6y ago

Listing "EDCSA [sic, maybe wishful thinking it actually is an Ed25519-like scheme instead of ECDSA?] over secp256" (plus siblings) and AES-GCM as "Modern cryptographic primitives only" is genuinely funny. This library does not do Chapoly1305, which has largely been the default choice for SSH since a few years, since it's both fast and secure without dedicated instructions.

riobard 6y ago
https://github.com/apple/swift-nio-ssh/issues/48 https://github.com/apple/swift-nio-ssh/issues/48 The dev said it's basically because Swift Crypto API does not support chacha20-poly1305@openssh.com, which is a non-standard construction (compared to chacha20-ietf-poly1305).
fay59 6y ago
What are the benefits of chacha20-poly1305 over what’s currently implemented?

jws 6y ago

This sounds like a great addition for servers written in Swift. Pair it with the very easy to use and clean command line arguments package and it should be "trivial" to add management/diagnostic console full of commands to your server. Traditionally for HTTP servers I carve off a URL prefix, e.g. /diagnostics/ or listen on a different port, and make handlers there to let me know how things are going. The downside is that I then have to protect those which collides with whatever other authentication is going on. Moving that to a command console eliminates all those ways to screw up and let evil people into my diagnostic functions. The command line parser package is trivial to use once you get the hang of it and generates acceptable "help" automatically, so you'll end up with a custom CLI of your diagnostic commands with a "help" function to remember them for essentially zero coding and maintenance effort. Now I have to spend all day resisting the urge to weld this into my latest HTTP server to see how it goes. Update: There is an example server in the Sources/NIOSSHServer directory of the repository. 5 files, about 500 lines total to implement a "bash" command executer and a remote port forwarder. Update 2: 50 minutes in and I have an ssh server embedded in my server. Maybe. When I send a command it explodes my process with a Posix.close() to a bad file descriptor tripping a precondition check. So, maybe don't rush this to a live server.

jws 6y ago
For anyone following in these footsteps: It works well. I spent more time fighting Swift Argument Parser than the NIOSSH. Fundamentally, there is not a way to pass context down to a command that is run. Fine when you are a whole program reading its commands and everything is implicitly global, but if you have a bunch of SSH connections coming in then just getting the output to the right one needs context. I'm not real happy with my solution, but its clean and it works. Figure two days to get a usable subsystem working. I have a few more things to try to clean up my mess. If it works I'll tidy up the package and publish it.
- jws 6y ago
  Two days in. The package is useful and mostly complete. See https://github.com/jimstudt/SSHConsole https://github.com/jimstudt/SSHConsole if you have needs, or just want to see another example of using NIOSS on the server. This one includes the public key authentication which in retrospect is trivial-ish.

ogre_codes 6y ago

This is good. I've been searching around for a good SSH client library for an app I've been working on. I've used NMSSH for some time, but its Objective C and I'd like a more swift friendly implementation. Now I just need to dust it off, it's been sitting on that code-shelf over there for 2 years.