Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #166119 > unrolled thread

ssh-ing in inside private network

Back to article view | Back to linux.debian.user

Contents

  ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-03-31 13:50 +0200
    Re: ssh-ing in inside private network <tomas@tuxteam.de> - 2016-03-31 14:10 +0200
      Re: ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-03-31 14:30 +0200
        Re: ssh-ing in inside private network <tomas@tuxteam.de> - 2016-03-31 15:10 +0200
          Re: ssh-ing in inside private network David Wright <deblis@lionunicorn.co.uk> - 2016-03-31 20:20 +0200
        Re: ssh-ing in inside private network Brian <ad44@cityscape.co.uk> - 2016-03-31 16:10 +0200
          Re: ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-05-31 21:40 +0200
            Re: ssh-ing in inside private network John Hasler <jhasler@newsguy.com> - 2016-05-31 22:10 +0200
            Re: ssh-ing in inside private network Joe <joe@jretrading.com> - 2016-05-31 23:00 +0200
              Re: ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-06-01 00:30 +0200
                Re: ssh-ing in inside private network Joe <joe@jretrading.com> - 2016-06-01 09:50 +0200
            Re: ssh-ing in inside private network Stephen Powell <zlinuxman@fastmail.com> - 2016-06-01 01:00 +0200
              Re: ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-06-01 01:30 +0200
                Re: ssh-ing in inside private network Stephen Powell <zlinuxman@fastmail.com> - 2016-06-01 01:50 +0200
                  Re: ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-06-01 02:20 +0200
                    Re: ssh-ing in inside private network John Hasler <jhasler@newsguy.com> - 2016-06-01 02:30 +0200
                      Re: ssh-ing in inside private network Richard Hector <richard@walnut.gen.nz> - 2016-06-01 09:50 +0200
                      Re: ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-06-01 12:30 +0200
            Re: ssh-ing in inside private network Richard Hector <richard@walnut.gen.nz> - 2016-06-01 01:00 +0200
              Re: ssh-ing in inside private network John Hasler <jhasler@newsguy.com> - 2016-06-01 01:20 +0200
              Re: ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-06-01 01:20 +0200
                Re: ssh-ing in inside private network Dan Purgert <dan@djph.net> - 2016-06-01 14:20 +0200
                  Re: ssh-ing in inside private network Mark Fletcher <mark27q1@gmail.com> - 2016-06-01 15:50 +0200
                    Re: ssh-ing in inside private network Dan Purgert <dan@djph.net> - 2016-06-01 17:00 +0200
                      Re: ssh-ing in inside private network David Wright <deblis@lionunicorn.co.uk> - 2016-06-01 20:00 +0200
                        Re: ssh-ing in inside private network Dan Purgert <dan@djph.net> - 2016-06-02 22:20 +0200
                        Re: ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-06-03 11:10 +0200
                    Re: ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-06-03 11:10 +0200
                      Running without X was: Re: ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-06-03 11:30 +0200
                        Re: Running without X was: Re: ssh-ing in inside private network Dan Purgert <dan@djph.net> - 2016-06-03 15:50 +0200
                        Re: Running without X was: Re: ssh-ing in inside private network David Wright <deblis@lionunicorn.co.uk> - 2016-06-03 16:40 +0200
                          Re: Running without X was: Re: ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-06-03 18:40 +0200
            Re: ssh-ing in inside private network David Wright <deblis@lionunicorn.co.uk> - 2016-06-02 00:10 +0200
              Re: ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-06-03 11:00 +0200
                Re: ssh-ing in inside private network Lisi Reisz <lisi.reisz@gmail.com> - 2016-06-03 11:40 +0200
        Re: ssh-ing in inside private network Bob Bernstein <poobah@ruptured-duck.com> - 2016-03-31 19:50 +0200
      Re: ssh-ing in inside private network Brian <ad44@cityscape.co.uk> - 2016-03-31 14:40 +0200
        Re: ssh-ing in inside private network <tomas@tuxteam.de> - 2016-03-31 15:20 +0200
          Re: ssh-ing in inside private network Brian <ad44@cityscape.co.uk> - 2016-03-31 15:50 +0200
            Re: ssh-ing in inside private network <tomas@tuxteam.de> - 2016-03-31 16:20 +0200

Page 2 of 2 — ← Prev page 1 [2]

#168375

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:
> >
> > 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.

Thanks,
Lisi

[toc] | [prev] | [next] | [standalone]

#168397

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:
>> >
>> > 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.

-- 
Registered Linux user #585947
Github: https://github.com/dpurgert

[toc] | [prev] | [next] | [standalone]

#168398

[Multipart message — attachments visible in raw view] — view raw

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:
> >> >
> >> > 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 doing
anything, 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...

Mark

[toc] | [prev] | [next] | [standalone]

#168399

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:
>> >> >
>> >> > 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.

[toc] | [prev] | [next] | [standalone]

#168405

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.

[toc] | [prev] | [next] | [standalone]

#168445

David Wright wrote:
> On Wed 01 Jun 2016 at 14:47:11 (-0000), Dan Purgert wrote:
>> [snip]
>> 
>> 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.)

>From what I can tell, runlevels 2-5 all look identical in a default
(Jessie) install.

I've always used systems that have "standard" runlevels

0 = halt
1 = single user
2 = (unused /user-defined)
3 = multi-user, X disabled
4 = (unused / user-defined)
5 = multi-user, X enabled

Though, in playing with Debian, I'm finding they set runlevel2 =
"standard runlevel5".  Haven't gotten around to "fixing" it.

-- 
Registered Linux user #585947
Github: https://github.com/dpurgert

[toc] | [prev] | [next] | [standalone]

#168464

On Wednesday 01 June 2016 18:52:40 David Wright wrote:
> 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.

This is indubitably true, but irrelevant to the problem at hand.  It does 
however suggest that it would be worth setting up a, say Run Level 3, without 
X.  

But a default Ubuntu installation does not have it.

Lisi

[toc] | [prev] | [next] | [standalone]

#168466

On Wednesday 01 June 2016 14:43:29 Mark Fletcher wrote:
> 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:
> > >> >
> > >> > 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 doing
> anything, 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...

What I wanted to do was learn!  This is obvious once one thinks about it, but 
hitting it was a good way to learn.  I shall not forget in a hurry that no 
servers are running by default in Run Level 1.  I wanted to log in without X 
and runlevel 1 has no X.

Thanks for your time and help, Mark and Dan (and Richard, and everyone else, 
of course).

Lisi  

[toc] | [prev] | [next] | [standalone]

#168467 — Running without X was: Re: ssh-ing in inside private network

On Friday 03 June 2016 10:07:13 Lisi Reisz wrote:
>  I wanted to log in without X
> and runlevel 1 has no X.

So I next tried to shut X down.  I have tried this before without success, so 
I googled again, and gathered that what I needed to do in fact was shut down 
my dm.  See:

https://wiki.debian.org/Xorg#Configure_X

I wanted to log-in without X in order to do:

$ cd /etc/X11/
# Xorg -configure

But I couldn't.  So I tried:

# /etc/init.d/gdm stop && /etc/init.d/gdm3 stop && /etc/init.d/kdm stop 
&& /etc/init.d/xdm stop

Here is what happened from then on (still over ssh, which may be relevant):
lisi@Hermes:~$ sudo su
[sudo] password for lisi:
root@Hermes:/home/lisi# /etc/init.d/gdm stop && /etc/init.d/gdm3 stop 
&& /etc/init.d/kdm stop && /etc/init.d/xdm stop
bash: /etc/init.d/gdm: No such file or directory

So Google for systemd, which is what I  think Ubuntu 16.04 is using.  Then:

root@Hermes:/home/lisi# systemctl list-units | grep -i manager
init.scope                                                                               
loaded active running   System and Service Manager
lightdm.service                                                                          
loaded active running   Light Display Manager
ModemManager.service                                                                     
loaded active running   Modem Manager
NetworkManager-wait-online.service                                                       
loaded active exited    Network Manager Wait Online
NetworkManager.service                                                                   
loaded active running   Network Manager
resolvconf.service                                                                       
loaded active exited    Nameserver information manager
systemd-udevd.service                                                                    
loaded active running   udev Kernel Device Manager
udisks2.service                                                                          
loaded active running   Disk Manager
user@1000.service                                                                        
loaded active running   User Manager for UID 1000
root@Hermes:/home/lisi# systemctl stop lightdm.service       


root@Hermes:/home/lisi# systemctl stop lightdm.service
root@Hermes:/home/lisi# cd /etc/X11/
root@Hermes:/etc/X11# Xorg -configure

X.Org X Server 1.18.3
Release Date: 2016-04-04
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.13.0-85-generic x86_64 Ubuntu
Current Operating System: Linux Hermes 4.4.0-22-generic #40-Ubuntu SMP Thu May 
12 22:03:46 UTC 2016 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-22-generic 
root=UUID=d2c7c24d-c672-4ff9-bb54-57537ca2123f ro quiet splash vt.handoff=7
Build Date: 07 April 2016  09:18:50AM
xorg-server 2:1.18.3-1ubuntu2 (For technical support please see 
http://www.ubuntu.com/support)
Current version of pixman: 0.33.6
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Jun  1 16:34:34 2016
List of video drivers:
        radeon
        vmware
        qxl
        ati
        intel
        amdgpu
        modesetting
        nouveau
        vesa
        fbdev
No devices to configure.  Configuration failed.
(EE) Server terminated with error (2). Closing log file.
root@Hermes:/etc/X11#


root@Hermes:/etc/X11# logout
bash: logout: not login shell: use `exit'
root@Hermes:/etc/X11# exit
exit
lisi@Hermes:~$ logout
Connection to 192.168.0.5 closed.
lisi@Tux-II:~$ 
-----------------------------------------------------

Where next???  Ubuntu on Hermes is currently unusable because of the graphics.  
Debian Jessie with TDE 14.0.4 on the same machine is running beautifully, and 
I didn't have to do anything other than choose a setting in the Control 
Center.

Yes, I know that this is the Debian list.  Half of me wants you to tell me to 
get rid of Ubuntu, even as a dual boot!!  But hey!  I am learning a bit about 
systemd as well as ssh.  Can't be bad. ;-/

FWIW it is Ubuntu-MATE (16.04).

Lisi

[toc] | [prev] | [next] | [standalone]

#168483 — Re: Running without X was: Re: ssh-ing in inside private network

Lisi Reisz wrote:
> On Friday 03 June 2016 10:07:13 Lisi Reisz wrote:
>>  I wanted to log in without X
>> and runlevel 1 has no X.
>
> So I next tried to shut X down.  I have tried this before without success, so 
> I googled again, and gathered that what I needed to do in fact was shut down 
> my dm.  See:
>
> https://wiki.debian.org/Xorg#Configure_X
>
> I wanted to log-in without X in order to do:
> [snip]
>
> Where next???  Ubuntu on Hermes is currently unusable because of the
> graphics. 
> Debian Jessie with TDE 14.0.4 on the same machine is running
> beautifully, and I didn't have to do anything other than choose a
> setting in the Control Center.

Honestly, I don't know how to do it with systemd (it will be installed
on one of my boxen over my dead body).

With sysvinit (or, Upstart, or any sane init system), it's as
simple as going into /etc/rc[X].d/ and then moving 'S##mdm' to
'K##mdm'[1], then changing /etc/inittab (for sysvinit) if you edited
your "not default" runlevel.  In my case, Debian defaults to RL2, so I
edited RL3 and set that as the default (to match the "standard" of
"Multi-User, without X).

For Upstart, you can do similar things, but it's a little different:

 - the "default" settings are in /etc/init/rc-sysinit.conf
 - the Upstart script needs to be told individually which runlevel(s) it
   can run at.

[X] = this is your runlevel (e.g. /etc/rc3.d/ for RL3)
[1] I just pulled mdm out of thin air.  If you're using something else
(gdm, slim, whatever), change that one instead.

>
> Yes, I know that this is the Debian list.  Half of me wants you to
> tell me to get rid of Ubuntu, even as a dual boot!!  But hey!  I am
> learning a bit about systemd as well as ssh.  Can't be bad. ;-/

get rid of systemd. ;)

Watch out in case you have systemd 230 (or if you don't and it becomes
an update) -- the systemd devs have decided that processes should die
when the user logs out - *EVEN THOSE THAT HAVE BEEN EXPLICITLY ALLOWED
WITH NOHUP*.

-- 
Registered Linux user #585947
Github: https://github.com/dpurgert

[toc] | [prev] | [next] | [standalone]

#168492 — Re: Running without X was: Re: ssh-ing in inside private network

On Fri 03 Jun 2016 at 10:28:32 (+0100), Lisi Reisz wrote:
> On Friday 03 June 2016 10:07:13 Lisi Reisz wrote:
> >  I wanted to log in without X
> > and runlevel 1 has no X.
> 
> So I next tried to shut X down.  I have tried this before without success, so 
> I googled again, and gathered that what I needed to do in fact was shut down 
> my dm.  See:
> 
> https://wiki.debian.org/Xorg#Configure_X
> 
> I wanted to log-in without X in order to do:
> 
> $ cd /etc/X11/
> # Xorg -configure
> 
> But I couldn't.  So I tried:
> [various sysvinit things to kill X]

> Here is what happened from then on (still over ssh, which may be relevant):

Well, I thought it might be, but when I tried it, all went smoothly,
and I got results identical with when I had done it locally.

> [various systemd things to kill X]

> root@Hermes:/etc/X11# Xorg -configure
> 
> X.Org X Server 1.18.3
> Release Date: 2016-04-04
> X Protocol Version 11, Revision 0
> Build Operating System: Linux 3.13.0-85-generic x86_64 Ubuntu
> Current Operating System: Linux Hermes 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64
> Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-22-generic root=UUID=d2c7c24d-c672-4ff9-bb54-57537ca2123f ro quiet splash vt.handoff=7
> Build Date: 07 April 2016  09:18:50AM
> xorg-server 2:1.18.3-1ubuntu2 (For technical support please see http://www.ubuntu.com/support)
> Current version of pixman: 0.33.6
[...]
>         vesa
>         fbdev
> No devices to configure.  Configuration failed.
> (EE) Server terminated with error (2). Closing log file.
> root@Hermes:/etc/X11#

Just to note (you probably know this) that, apart from "No devices to
configure" and the lack of action, the failure message is normal.

> Where next???  Ubuntu on Hermes is currently unusable because of the graphics.  

I haven't followed everything you did earlier wrt X. I take it that X
(which you killed above) is "working", but not to your liking? which
is why you want to (re)configure the Xserver. In which case, the
problem is way over my head, but AFAICT nothing to do with your using
ssh to do things through.

If X wasn't working at all (ie when you boot ubuntu, you get nothing)
then it would suggest there's no driver loaded that can run the
hardware. Unusual for ubuntu.

Sorry about the lack of further ideas. In tracking what you've been
doing, I did discover that it's obvious if you try to Xorg -configure
while X is running ((EE) Server is already active for display 0) and
that the point of failure when run as a user is the juggling of log
files; I had thought it would check for $UID=0 earlier than that.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#168497 — Re: Running without X was: Re: ssh-ing in inside private network

On Friday 03 June 2016 15:32:14 David Wright wrote:
>  I did discover that it's obvious if you try to Xorg -configure
> while X is running

There's a hole in the bucket, dear Eliza....

This is why I was trying to do it at single user level, to be *certain* that X 
wasn't running. :-)

X is there, but unusable because the resolution is taking almost everything 
off the screen.  Ubuntu is such a GUI based OS that I am getting nowhere 
fast.

But I have had some practice with ssh, with which I am getting more confident.  
I do now know roughly how to use it and just have to learn more.  Ubuntu is 
and was an aside.  I just have to decide what I want to do to nuke it and get 
my Debian back unmolested.

Thanks everyone for all the help.  I'll do a "SOLVED" and a proper report on 
my original post over the weekend.

Lisi

[toc] | [prev] | [next] | [standalone]

#168410

On Tue 31 May 2016 at 20:31:32 (+0100), Lisi Reisz wrote:
> On Thursday 31 March 2016 15:08:24 Brian wrote:
> > On Thu 31 Mar 2016 at 13:27:35 +0100, Lisi Reisz wrote:
> > > On Thursday 31 March 2016 12:28:57 tomas@tuxteam.de wrote:
> > > > 1. Each computer should have an SSH server running (on Debian that
> > > > would be package openssh-server: in Debian it has priority "optional":
> > > > I'd double-check that it's installed)
> > >
> > > It is installed.  How do I check that it is running?
> >
> > Use 'ssh user@somewhere'. 'Connection refused' is a good indication
> > there is no ssh server on port 22.
> >
> > > Previously (under Wheezy) using Fish, I have been getting the first part
> > > of the message and asked if I want to accept the new identification. 
> > > Fish presumably then edited the file.  So I need static IPs fast!  or a
> > > hosts file?  I have some learning to do.  Static IPs I have no problem
> > > over, I just
> >
> > The IP and host in /etc/hosts is fine. Alternatively, with avahi-daemon
> > on the machines you would do 'ssh someone@eros.local'. Use with static
> > or dynamic IPs and not have the bother of maintaining a hosts file.
> 
> Right, I am making (slow) progress.  My next question is at the end after my 
> progress report.
> 
> Here is how far I have got:
> 
> I tried and failed to edit ~/.ssh/known_hosts because it was encrypted. So I 
> googled, and set it in ssh_conf to unencrypted.  It remained encrypted, of 
> course, so I did the following:

The commands in https://lists.debian.org/debian-user/2016/03/msg01299.html
handle encrypted ~/.ssh/known_hosts without your having to weaken security.

$ ssh-keygen -l -v -f ~/.ssh/known_hosts -t ecdsa -F foo        <-test
$ ssh-keygen -f ~/.ssh/known_hosts -t ecdsa -R foo              <-remove
(foo is the hostname or IP#.)

> [...]
> 
> So - the key changed when you change operating system.  A nuisance but hardly 
> surprising, and easily remediable after you kind souls showed me the way.

If you copy the keys from one OS to another (on the same host, of course),
you shouldn't have this rigmarole. The files concerned are:

$ ls -l1 /etc/ssh/*key*
-rw------- 1 root root  668 Apr 28  2014 /etc/ssh/ssh_host_dsa_key
-rw-r--r-- 1 root root  599 Apr 28  2014 /etc/ssh/ssh_host_dsa_key.pub
-rw------- 1 root root  227 Apr 28  2014 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r-- 1 root root  171 Apr 28  2014 /etc/ssh/ssh_host_ecdsa_key.pub
-rw------- 1 root root 1679 Apr 28  2014 /etc/ssh/ssh_host_rsa_key
-rw-r--r-- 1 root root  391 Apr 28  2014 /etc/ssh/ssh_host_rsa_key.pub
$ 

The posting referred to above also contained a quick fix to temporarily
circumvent said rigmarole (without copying the keys) if you need to
flip between OSes a lot (ie use /dev/null as your known_hosts file).

ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null user@host

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#168463

On Wednesday 01 June 2016 23:07:55 David Wright wrote:
> On Tue 31 May 2016 at 20:31:32 (+0100), Lisi Reisz wrote:
> > On Thursday 31 March 2016 15:08:24 Brian wrote:
> > > On Thu 31 Mar 2016 at 13:27:35 +0100, Lisi Reisz wrote:
> > > > On Thursday 31 March 2016 12:28:57 tomas@tuxteam.de wrote:
> > > > > 1. Each computer should have an SSH server running (on Debian that
> > > > > would be package openssh-server: in Debian it has priority
> > > > > "optional": I'd double-check that it's installed)
> > > >
> > > > It is installed.  How do I check that it is running?
> > >
> > > Use 'ssh user@somewhere'. 'Connection refused' is a good indication
> > > there is no ssh server on port 22.
> > >
> > > > Previously (under Wheezy) using Fish, I have been getting the first
> > > > part of the message and asked if I want to accept the new
> > > > identification. Fish presumably then edited the file.  So I need
> > > > static IPs fast!  or a hosts file?  I have some learning to do. 
> > > > Static IPs I have no problem over, I just
> > >
> > > The IP and host in /etc/hosts is fine. Alternatively, with avahi-daemon
> > > on the machines you would do 'ssh someone@eros.local'. Use with static
> > > or dynamic IPs and not have the bother of maintaining a hosts file.
> >
> > Right, I am making (slow) progress.  My next question is at the end after
> > my progress report.
> >
> > Here is how far I have got:
> >
> > I tried and failed to edit ~/.ssh/known_hosts because it was encrypted.
> > So I googled, and set it in ssh_conf to unencrypted.  It remained
> > encrypted, of course, so I did the following:
>
> The commands in https://lists.debian.org/debian-user/2016/03/msg01299.html
> handle encrypted ~/.ssh/known_hosts without your having to weaken security.
>
> $ ssh-keygen -l -v -f ~/.ssh/known_hosts -t ecdsa -F foo        <-test
> $ ssh-keygen -f ~/.ssh/known_hosts -t ecdsa -R foo              <-remove
> (foo is the hostname or IP#.)

Thanks, David.  The main underlying purpose of all this is to do something 
about my woeful ignorance of, and lack of skill with, ssh-ing, via some real 
problems I need to solve.  When you sent that email originally I'm afraid I 
glazed over and didn't understand it, particularly as it is the kind of thing 
I have physical difficulty reading.  I didn't know what foo was anyway.  
Thanks for having the patience to repeat the information in a different way.

> > [...]
> >
> > So - the key changed when you change operating system.  A nuisance but
> > hardly surprising, and easily remediable after you kind souls showed me
> > the way.
>
> If you copy the keys from one OS to another (on the same host, of course),
> you shouldn't have this rigmarole.

I had worked that out as a principle, but not worked out how to do it in 
practice.  That was for another day!

> The files concerned are: 

So thank you very much for this.
>
> $ ls -l1 /etc/ssh/*key*
> -rw------- 1 root root  668 Apr 28  2014 /etc/ssh/ssh_host_dsa_key
> -rw-r--r-- 1 root root  599 Apr 28  2014 /etc/ssh/ssh_host_dsa_key.pub
> -rw------- 1 root root  227 Apr 28  2014 /etc/ssh/ssh_host_ecdsa_key
> -rw-r--r-- 1 root root  171 Apr 28  2014 /etc/ssh/ssh_host_ecdsa_key.pub
> -rw------- 1 root root 1679 Apr 28  2014 /etc/ssh/ssh_host_rsa_key
> -rw-r--r-- 1 root root  391 Apr 28  2014 /etc/ssh/ssh_host_rsa_key.pub
> $
>
> The posting referred to above also contained a quick fix to temporarily
> circumvent said rigmarole (without copying the keys) if you need to
> flip between OSes a lot (ie use /dev/null as your known_hosts file).
>
> ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null
> user@host

I hadn't picked this up either.  I simply hadn't understood the email.  This 
may be the best solution for 198.162.0.5, Hermes.

Thanks for the help, 

Lisi

[toc] | [prev] | [next] | [standalone]

#168468

On Friday 03 June 2016 09:59:29 Lisi Reisz wrote:
> I didn't know what foo was anyway.

I meant that I didn't know specifically what foo was in that context.

Lisi

[toc] | [prev] | [next] | [standalone]

#166134

On Thu, 31 Mar 2016, Lisi Reisz wrote:

> So I need static IPs fast!  or a hosts file?

That's how I do it. Only make that "or" above an "and!"

Also, liberal use of public-keys practically automates the whole 
thing, so that you don't have to bother with pesky passwords on 
your private 'net.


-- 
I am animated by distrust of all high guesses, and by sympathy
with the old prejudices and workaday opinions of mankind: they
are ill expressed, but they are well grounded.

                                   George Santayana

[toc] | [prev] | [next] | [standalone]

#166122

On Thu 31 Mar 2016 at 13:28:57 +0200, tomas@tuxteam.de wrote:

> On Thu, Mar 31, 2016 at 12:43:49PM +0100, Lisi Reisz wrote:
> > I want all the computers on my private network to be able to shh into each 
> > other.  In Jessie, what do I have to do where in what config file?  
> > Presumably some port is shut??
> 
> 0. Each computer should be able to "see" port 22 (ssh) of each other's
>    (I'm assuming you go with the default port for ssh, this can be
>    changed, but I wouldn't do that without some reason)
> 
> 1. Each computer should have an SSH server running (on Debian that would
>    be package openssh-server: in Debian it has priority "optional": I'd
>    double-check that it's installed)
> 
> 3. To connect, you need also an openssh-client (since this has priority
>    "standard" n Debian, chances are that it's there already)
>    You can check all these three by trying from each host "ssh user@the-other-host"
>    and studying the responses.
> 
> Since your question was pretty general, I preferred to go with a terse,
> bird's perspective answer. Let's tackle the details when they come up.

There is also dropbear as a lightweight SSH2 server and client. Using
it in preference to openssh is useful for resource constrained machines.

[toc] | [prev] | [next] | [standalone]

#166125

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Mar 31, 2016 at 01:32:05PM +0100, Brian wrote:

[...]

> There is also dropbear as a lightweight SSH2 server and client. Using
> it in preference to openssh is useful for resource constrained machines.

Yes, there are nifty tricks like embedding dropbear in the initrd, so
you can, e.g. enter the LUKS encryption passphrase to a server over the
'net.

But I'd consider all of that "advanced usage" :-)

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEUEARECAAYFAlb9Gi0ACgkQBcgs9XrR2kbp5ACdFL/yVtPBr3NJDnVFvsOvAVOo
iusAmLp27frMU6a2y6Al6SFmgycBS+k=
=6Vrz
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#166126

On Thu 31 Mar 2016 at 14:38:05 +0200, tomas@tuxteam.de wrote:

> On Thu, Mar 31, 2016 at 01:32:05PM +0100, Brian wrote:
> 
> [...]
> 
> > There is also dropbear as a lightweight SSH2 server and client. Using
> > it in preference to openssh is useful for resource constrained machines.
> 
> Yes, there are nifty tricks like embedding dropbear in the initrd, so
> you can, e.g. enter the LUKS encryption passphrase to a server over the
> 'net.
> 
> But I'd consider all of that "advanced usage" :-)

Indeed it is.

I had in mind a machine with 1GB of disk space; every MB of usage
counts. openssh-server takes six times as much space as dropbear; and
that is without taking its dependencies into account! If all the
features of openssh are not needed dropbear is as simple to install and
use. Most people would not notice any difference.

[toc] | [prev] | [next] | [standalone]

#166128

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Mar 31, 2016 at 02:40:58PM +0100, Brian wrote:
> On Thu 31 Mar 2016 at 14:38:05 +0200, tomas@tuxteam.de wrote:
> 
> > On Thu, Mar 31, 2016 at 01:32:05PM +0100, Brian wrote:
> > 
> > [...]
> > 
> > > There is also dropbear as a lightweight SSH2 server and client. Using
> > > it in preference to openssh is useful for resource constrained machines.
> > 
> > Yes, there are nifty tricks like embedding dropbear in the initrd, so
> > you can, e.g. enter the LUKS encryption passphrase to a server over the
> > 'net.
> > 
> > But I'd consider all of that "advanced usage" :-)
> 
> Indeed it is.
> 
> I had in mind a machine with 1GB of disk space; every MB of usage
> counts.

Nah -- 1GB is luxury: the whole openssh server is less than 0.8 MB.
Now with 4MB we're talking (one of my customers has a small embedded
Linux thing with 4MB flash and 4GB RAM; besides it's some 486 without
floating point: there we have to tread carefully :-)

But the openssh server from "back then" was smaller too...

> openssh-server takes six times as much space as dropbear; and
> that is without taking its dependencies into account! If all the
> features of openssh are not needed dropbear is as simple to install and
> use. Most people would not notice any difference.

But yes, basically agreed. If I had to redo the thing above, I'd
consider dropbear; that said, a re-doing would mean some raspi-like
hardware, which will be a "supercomputer" compared to what's installed
there now :-)

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlb9KLgACgkQBcgs9XrR2kZDKgCfbqipMdGpiu0SSIPqr5IzwUbh
XMYAni35beWnv3zny3DViFB2qlpTcsTk
=niKY
-----END PGP SIGNATURE-----

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web