ssh without ssh daemon

decuser

decuser

This is less a FreeBSD question and more of an ssh question, but I'm open to FreeBSD answers :). Is it possible to use ssh to log in to my server without setting up the ssh daemon? In my mind, I thought it'd be easy... something along the lines of ssh -l 22 on fenris and then remoting to fenris from loki via ssh fenris. Maybe a different port, but other than that it didn't seem like an outrageous idea, but I can't figure it out after reading dozens of tunneling tutorials which all seem to just tunnel a port on one end to a port on the other end, which presumes there's a listener on one end or the other. Netcat sorta works along these lines nc -l 2222, then nc fenris 2222. But I can't see any comparable feature with the ssh client. Is it there?

Thanks!
 
The way your question is posed, no, there is no way to "use ssh without an sshd daemon." Look at the difference between connect(2) and accept(2), or read the first chapter of Stevens for a fuller introduction.

I think what you mean is that you want to run sshd(8) in the foreground in a shell session. This is accomplished by using the -D flag as the man page says. You can provide a path to a config file with -f if you don't want to use the system one at /etc/ssh/sshd_conf for some reason. You can also specify config options using -o if you don't want to use a config file .
 
  • Like
Reactions: a6h
Jose, I see where I went sideways on this question now! On FreeBSD, sshd is included with the base install, which is smart. I am on a machine that doesn't have sshd installed and the lan it's on doesn't have access to the internet. It would be convenient to use ssh on the lan. I was hoping to run the client in listen mode (nc can do this, vnc can too, I was hoping the same for the ssh client, but it doesn't seem promising. I'll take your advice on the man reading front... can never get enough background on these things.
 
The ssh client is installed but sshd is not? Are you at the console of the machine?

The vnc and netcat binaries contain both the server and the client. You choose which to run with a command line parameter. This selects different code paths inside the binary that do radically different things.

I'm not sure why you would allow vnc and nc on a network but not ssh.
 
Jose, it's not a FreeBSD specific question and I didn't think it through posting in the forum, because FreeBSD includes the server in Base. I was thinking it was a generic question, but in light of the fact that FreeBSD puts sshd in base, it makes the question very confusing to FreeBSD folks... my bad! The actual environment is another *nix box (not FreeBSD) and yes, the client is installed, but not sshd. With respect to nc, yes, it's installed by default, vnc I brought into the discussion because it also provides the service capability in the client.

I think you hinted at the anwer, though, when you said nc and vnc contain both client and server in the same binary. If this isn't the case with ssh, then no, it can't 'listen'.
 
Most network protocols use a client-server model, and UNIX usually has separate programs for the client side and for the server side. In this case, ssh(1) implements the client side only, and sshd(8) implements the server side only. In theory, you can put both into the same program, but there are reasons to keep it separate, for example it’s easier to isolate potential security problems.

By the way, netcat a.k.a. nc(1) does not implement a specific protocol. It’s a generic TCP / UDP network tool. In particular, you can use it to make a simple proxy, and this requires client and server code at once, because this is how a proxy works (it both accepts and initiates connections). For the same reason, VNC contains client and server code, because it has a feature to proxy connections within a LAN (if you ask me, this is rather an undesirable “feature”, but that’s a different story).
 
Ok, yes, you COULD do this, but it would be ridiculous.

SSH from the "no-server" machine (A) to another machine you control (B). Use the -R option on this connection to bind a local socket on B to A. Then use netcat on A to get creative with connecting the socket to a shell. Access control to the local socket is done on B by restricting logins ?.

You can then freely connect to A by doing a -L connection to B and then connecting to that port on your machine.

Don't do this, though.
 
Gonna solve it by installing FreeBSD, which comes with a reasonable default system and userland :).
 
decuser said:
I was thinking it was a generic question, but in light of the fact that FreeBSD puts sshd in base, it makes the question very confusing to FreeBSD folks... my bad!
Click to expand...
No worries. I like thinking about networking problems. I'm still staggered by the no-server ssh install. Every Linux distro I ever used installed both when you installed the SSH package. I'm also hoping this is not an ignorant attempt at security. Netcat and vnc are far more dangerous than sshd, and the latter can make a lot of situations actually safer.

decuser said:
I think you hinted at the anwer, though, when you said nc and vnc contain both client and server in the same binary. If this isn't the case with ssh, then no, it can't 'listen'.
Click to expand...
No need to put listen(2) in quotes. It's one of the syscalls you need to set up a TCP/UDP server.
 
Jose said:
Every Linux distro I ever used installed both when you installed the SSH package.
Click to expand...

Code: 
[fu@blap:~]$ apt-cache search ssh | grep '^ssh '                                                                                
ssh - secure shell client and server (metapackage)
[fu@blap:~]$ apt-cache search openssh | grep '^openssh-[^\-]* '                                                                 
openssh-client - secure shell (SSH) client, for secure access to remote machines
openssh-server - secure shell (SSH) server, for secure access from remote machines

Only if you use the meta package but then i don't know which distributions you've used so maybe it's different elsewhere.
 
You need to have running sshd on your server machine, then you can login to
it running ssh on your client machine. You need neither ssh on
the server machine nor sshd on the client machine. That is all.

Do you really have a server?! How do you login to it if not with ssh?!

Again, per definition the server is the program that accepts connections. A machine that
do not run the program for accepting connections will not accept a connection.

Per definition the client is a program to make a connection. Without such program you
will not be able to initialise a connection.

You mean we are confused because we have machines with both, ssh and
sshd, per default?! What an insult!!!! Please, reflect a little about who is
confussed.

decuser said:
Gonna solve it by installing FreeBSD, which comes with a reasonable default system and userland
Click to expand...

To install an entire operating system when you only need sshd is an abstruse
"solution", and perhaps no solution, because with that you will learn nothing and will still
have problems.
 
hruodr said:
You mean we are confused because we have machines with both, ssh and
sshd, per default?! What an insult!!!! Please, reflect a little about who is
confussed.


To install an entire operating system when you only need sshd is an abstruse
"solution", and perhaps no solution, because with that you will learn nothing and will still
have problems.
Click to expand...

Re confusion: Hardly meant to insult, but the question as I originally framed it presumed the lack of sshd... which, in a FreeBSD context is unlikely to occur. Therefore, it is completely understandable that someone using FreeBSD would not grok the situation properly. If you read my post fully, you would see that I said it was my framing that was at fault.

Re abstruse: Nah. Just expedient. I set the machine up in a lab for a *nix environment for students to explore. I want them to have the ability to ssh into the machine. I like FreeBSD just fine (been using it for a decade plus alongside Linux/Windows/Mac) and I use it for systems programming, so it's handy for all kinds of reasons. It takes what, 5 minutes to set up? The problem with just adding ssh-server to the box, as it exists, is that it requires me to download the package and it's dependencies to a usb stick and sneakernet the files to the machine. I don't mind doing it, really, but it's a hassle I'd just as soon forgo. Kali has both server and client installed, but I'm reserving that for some other machines in the lab. So, I'm happy to put FreeBSD on the machine and be glad of having a sane environment to use.
 
ekvz
ekvz said:
Code: 
[fu@blap:~]$ apt-cache search ssh | grep '^ssh '                                                                              
ssh - secure shell client and server (metapackage)
[fu@blap:~]$ apt-cache search openssh | grep '^openssh-[^\-]* '                                                               
openssh-client - secure shell (SSH) client, for secure access to remote machines
openssh-server - secure shell (SSH) server, for secure access from remote machines

Only if you use the meta package but then i don't know which distributions you've used so maybe it's different elsewhere.
Click to expand...

ekvz, this is a great supplemental answer. It is where I eventually landed after Jose and olli@ pointed out the split. The lab machine under consideration is currently Linux Mint 20, and openssh-client is installed there as part of the base, but not openssh-server. I agree with Jose that this is staggering... and pretty inconvenient to fix. It requires the downloading of additional packages and dependencies to even be able to remotely log into the machine. However, Mint, as great as it is, isn't really configured to be a server out of the box, so I'll cut it some slack and be grateful for the learning experience.
 
By the way, if you have netcat installed on that machine (usually the command name is “nc”), you can easily use it in server mode (with the -l option) to transfer files to that machine, so you don’t have to use a USB stick or whatever. For example:

nc -l 4444 > /tmp/myfile

And on the other machine (the one that is providing the file):

nc firsthost 4444 < myfile

That way you can transfer files, one at a time, be it binary files, libraries, software packages, or whatever. If you want to transfer a larger number of files, just put them into a .tar.gz archive that you can copy over at once.
 
Jose said:
That's just goofy. Even Macs come with sshd installed.
Click to expand...

Been a while so don't quote on it but i think most Debian based systems don't install the daemon by default (likely in part because installing the package automatically activates it - unlike for example dropbear sshd which needs a line in /etc/default edited to start) with minimal installs not even having the client.
 
You must log in or register to reply here.
Back
Top