Re: usermod -S /path/to/app vs. custom server program with libssh

[The Geek on Skates <geekonskates@xxxxxxxxxxxxxx>]

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 <jjelen@xxxxxxxxxx> 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
> geekonskates@xxxxxxxxxxxxxx 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. :)
> 
>