Re: ssh-ing in inside private network
On Wed 01 Jun 2016 at 14:47:11 (-0000), Dan Purgert wrote:
> Mark Fletcher wrote:
> > --001a114056c6437ae5053437ad41
> > Content-Type: text/plain; charset=UTF-8
> >
> > On Wed, Jun 1, 2016 at 9:10 PM Dan Purgert <dan@djph.net> wrote:
> >
> >> Lisi Reisz wrote:
> >> > On Tuesday 31 May 2016 23:56:02 Richard Hector wrote:
> >> >> On 01/06/16 07:31, Lisi Reisz wrote:
> >> >> > Now to do what I really wanted to do all along, and ssh in to run
> >> level
> >> >> > one as root:
Could I take the liberty of requoting an earlier version of this statement:
"Now to do what I really wanted to do all along, and ssh in to run
level one as root: [...]
"[...] This was the point of the whole exercise. I want CLI only
(no X running) access to the Ubuntu installation on Hermes."
AIUI one can configure a box to run X in all runlevels but 1;
however, there's no need to do it that way. None of my machines
run X automatically at runlevel 2: I have to use startx.
> >> >> > lisi@Tux-II:~$ ssh root@192.168.0.5
> >> >> > ssh: connect to host 192.168.0.5 port 22: No route to host
> >> >> > lisi@Tux-II:~$ ssh lisi@192.168.0.5
> >> >>
> >> >> Run level one? AKA single user mode? I wouldn't expect to find sshd
> >> >> running in single user mode. Without checking, I'm not sure I'd even
> >> >> expect networking to be up.
> >> >>
> >> >> Richard
> >> >
> >> > Yes, I had come to the conclusion that that was probably the problem.
> >> > Networking does appear to be up since nmap found a host having scanned
> >> > the ports.
> >>
> >> You'll need to reset the init script to fire at runlevel 1. Not sure
> >> how you go about this in a systemd setup.
> >>
> >> That being said, the 'init' manpage has the following warning:
> >>
> >> # On a Debian system, entering runlevel 1 causes all processes to be
> >> # killed except for kernel threads and the script that does the killing
> >> # and other processes in its session. As a consequence of this, it isn't
> >> # safe to return from runlevel 1 to a multi-user runlevel: daemons that
> >> # were started in runlevel S and are needed for normal operation are no
> >> # longer running. The system should be rebooted.
> >>
> >> I'm not sure if this holds for systemd-init though.
> >>
> >>
> >>
> > To add to that, and not to make value judgements, but the point of
> > Runlevel 1 is that it is single user mode. The whole point is that
> > there is only one person logged in, _via the console_, and no one else
> > can be logged in doinanything, and therefore it is safe to perform
> > maintenance like taking disks offline to back them up (back in the
> > days when that was the main / only way to do it) or other similar
> > maintenance tasks.
> >
> > So, running the ssh daemon in Runlevel 1 is like, well, like trying to fit
> > brake blocks to a tomato. It just doesn't make a lot of sense. I think I
> > missed what you were actually trying to do but does it really need to be
> > done in Runevel 1? Because Runlevel 1 and remote access to the machine
> > aren't concepts that belong in the same sentence, at least without a
> > negative.
> >
> > Sorry, probably not what you wanted to hear but...
>
> I came "late" to the party myself, and missed the post where I imagine
> why Lisi is after runlevel 1.
>
> Personally, with the exception of my laptop, everything starts in
> runlevel 3 here.
IIRC Debian has always left it to the admin to make runlevels 2 and 3
distinct from one another. (OTOH I've never thought about how to
implement that in either sysvinit or systemd.)
I have a couple of other queries for Lisi though. Is it particularly
important that X is not running at all on host A when logging in as
root from host B? (After all, you still get a CLI on host B.)
And if it is, would it be sufficient for root to pkill xinit (or,
as I do: pkill xinit; sleep 5; kill -KILL xinit) if and when required?
Cheers,
David.
Reply to: