Interesting stuff. Yeah, the main thing that got me into libssh was being able to create a program that would be accessible over SSH, kind of like how people used to access games and other software over telnet. A good modern example is "SSH Tron", where someone "hosted" a multi-player Tron game on his/her server. S/he used Go, which is not a language I know (or really want to know, lol), so I've been looking into alternatives. Of course for anything other than a game, using sshd and a key beats the heck out of username/password, and sshd handles that nicely too... and yes I like my admin user to still have access to the standard Bash shell (lol)... so I guess that is the way to go for my purposes. Thanks for explaining the pros and cons, that was what I was trying to figure out. I don't need to get granular at all with the details of the SSH session, just that it exists and that users are not able to get out of my program into a shell. So yeah, usermod command with a chroot "jail" looks like it would work perfectly for that.
Sent with Proton Mail secure email. On Friday, January 19th, 2024 at 3:52 AM, Jakub Jelen <jje...@redhat.com> wrote: > Hi, > it mostly depends on the granularity you need in the control of the > SSH session or a limitation of the target system. If you just want > some CLI program to execute remotely, wrapping it in some existing ssh > server (openssh) as a forced command is much less error-prone and much > less work. Its also useful if you still want to keep the standard SSH > service running on the same machine on the same port for management. > > On the other hand, if you need more control of the sessions, > authentication, transfers, users, implementing ssh server using libssh > might be your best bet. Its also significantly smaller in regards to > LoC, that the whole OpenSSH, which can limit the attack vector. libssh > can also run with much smaller cryptographic libraries than OpenSSL, > which might be useful for smaller systems/ You can tune many things > using configuration in OpenSSH, but there are limits. In libssh you > can implement callbacks for most of the stuff handling incoming > connection, callbacks, authentication, various requests, which is not > possible with OpenSSH. > > Jakub > > On Fri, Jan 19, 2024 at 3:31 AM The Geek on Skates > geekonska...@protonmail.com wrote: > > > Good evening and happy Friday! :) > > > > What I mean, process-wise, is something like: > > > > At a terminal, user runs ssh gameorwhatever@myserver > > The request goes to sshd, with the key or password or whatever, and the > > user is in. > > The "gameorwhatever" user's shell is set to /path/to/some/program, and a > > chroot is in place, so the user uses the game or whatever, and when s/he is > > done s/he is disconnected from the server. > > > > On the other hand, the other way (and the way I was originally thinking of > > going for this project), was: > > > > At a terminal, user runs ssh gameorwhatever@myserver > > The request goes to /path/to/some/program, which hopefully handles the key > > stuff correctly, and hopefully does all the sending/receiving correctly, > > and all that. > > > > So I've been thinking, just out of curiosity, why (and when) would I choose > > one strategy over the other? If I want to set up something other than a > > full-on OS shell, and make it accessible over SSH, what would be the pros > > and cons of using libssh to create a server program vs. creating a user > > with minimal access to stuff, doing the whole chroot thing I don't fully > > understand (YET), and just changing that user's "shell" to the new program? > > It seems to me that way would eliminate a lot of the learning curve (and > > room for noob error and easy cracking). You wouldn't have to do any of the > > networking stuff yourself, it would be like creating any other command-line > > app (and assuming you know about things like buffer overflows etc. it's > > pretty easy to create terminal apps that don't have gaping security holes > > in them, lol). And if users accessed it with the standard ssh client, your > > program would be what reads any parameters people might try (like "ssh > > user@server /bin/bash" or whatever), so it's not like there's an easy way > > for someone to get around your program into a Bash shell. That, compared > > with implementing a server "from scratch" (well not really from scratch - > > using libssh I mean) just sounds so much more error-prone, if you don't > > know all the intricate nuts and bolts of how SSH is supposed to work under > > the hood. I'm just kind of curious about your thoughts on the advantages of > > doing it one way vs. the other. I know C and C++ really well, but apart > > from some minimal tinkering with the sockets APIs idk much about how to > > work with SSH (beyond the obvious - I can SSH into servers, create keys and > > stuff like that - but even the SSH setup I always have to re-research every > > time lol). Or maybe I'm just overthinking things. :D > > > > Don't get me wrong - I still want to learn to use libssh (I've heard of > > some cool things people are doing with their own clients... idk why u would > > necessarily need/want that, but real-time communications over SSH does > > sound awesome). I'm not trying to say one approach or the other to my > > specific question is better - I'm just interested in getting your thoughts > > on the best way to "host" (for lack of a better term) a command-line app > > over SSH. > > > > Anyway, hope you guys have a nice night (or morning), and looking forward > > to reading your two cents on the subject. :) > >
