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
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.
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
Re: ssh-ing in inside private network
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
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 exitedNetwork Manager Wait Online NetworkManager.service loaded active running Network Manager resolvconf.service loaded active exitedNameserver 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
Re: ssh-ing in inside private network
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
Re: ssh-ing in inside private network
On Wednesday 01 June 2016 14:43:29 Mark Fletcher wrote: > On Wed, Jun 1, 2016 at 9:10 PM Dan Purgert 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
Re: ssh-ing in inside private network
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 to...@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
Re: ssh-ing in inside private network
David Wright wrote: > On Wed 01 Jun 2016 at 14:47:11 (-), 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
Re: ssh-ing in inside private network
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 to...@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.
Re: ssh-ing in inside private network
On Wed 01 Jun 2016 at 14:47:11 (-), 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 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.
Re: ssh-ing in inside private network
Mark Fletcher wrote: > --001a114056c6437ae5053437ad41 > Content-Type: text/plain; charset=UTF-8 > > On Wed, Jun 1, 2016 at 9:10 PM Dan Purgert 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.
Re: ssh-ing in inside private network
On Wed, Jun 1, 2016 at 9:10 PM Dan Purgert 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
Re: ssh-ing in inside private network
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
Re: ssh-ing in inside private network
On Wednesday 01 June 2016 01:20:52 John Hasler wrote: > Lisi writes: > > The pipe symbol doesn't work on the keyboard at present attached > > Then put the output of ps in a file and search that. The small part of the problem I am trying to solve at this precise minute is that I am working almost blind. I would read a file how!! I can't ssh in, the display is not legible . I've realised the answer. Create the file, then reboot into the GUI, then read the file. It's easier to attach another keyboard before I next boot up. I'll attach another keyboard later today or tomorrow and take it from there. Lisi
Re: ssh-ing in inside private network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/06/16 12:20, John Hasler wrote: > Lisi writes: >> The pipe symbol doesn't work on the keyboard at present attached > > Then put the output of ps in a file and search that. > Or for a general solution to a faulty key, since this is on the console, hold down alt while typing 124 (decimal ascii value of |) on the numeric keypad - seems to work here, anyway. If it's worth the hassle :-) Actually it seems to work for more than ascii - it might work for all of unicode, if an appropriate font is available? Richard -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJXTpOHAAoJELSi8I/scBaNj/gH/RhTyItQJa4B7dCGCQ9J9Htj 2BkoQTFVbaai3D5hLQZrFneqrzmTv+neejKl6FupUTdL3xuKe09HiiHSdkIpjeoA L8lvbpdO/C3WXdWNzSWq8U3Iz5URc+j1w1ZPUhPq6m7kjuOl+z+DyHkEoye0PNmV kKlb1ioKZyMahiYcSUe6X7vKA3AKdr9d4MFJvtmaZ3BKzfG27WEB7dhLQc+UFNed 1mAvT1J12fX61CU7P88GVVMEAqAWTxes9nogh709GvaUc1vydTeZe9xd+7Cgn7fV 0jj2+2jm8YuL7XFCKgiB79Rt59QReYrJbDzVpB5BL2HlKfSfda+kF8qMPP2m6pc= =+C6R -END PGP SIGNATURE-
Re: ssh-ing in inside private network
On Tue, 31 May 2016 23:27:36 +0100 Lisi Reisz wrote: > > Starting Nmap 6.00 ( http://nmap.org ) at 2016-05-31 23:14 BST > Nmap done: 1 IP address (0 hosts up) scanned in 0.52 seconds > root@Tux-II:/home/lisi# nmap 192.168.0.5 -Pn 22 For future reference, this should have been nmap 192.168.0.5 -Pn -p 22 Normally nmap will ping a host before trying ports, and if pings are not being answered, this will slow things down. With -Pn, nmap will try the ports you want without the initial ping. But if you're expecting a ping reply, this immediately tells you there is a problem... -- Joe
Re: ssh-ing in inside private network
On Wednesday 01 June 2016 00:42:47 Stephen Powell wrote: > On Tue, May 31, 2016, at 19:25, Lisi Reisz wrote: > > ... > > Assuming that sshd is actually running at that stage, which it looks as > > though it isn't > > ... > > Looks as though I've given you mostly information that you don't need. > Sorry about that. At the risk of doing so again, here's how you can tell > if the ssh daemon is running. Issue > >ps aux|grep ssh > > You should see something like the following in the output: > >root 709 0.0 0.0 10200 3632 ?Ss May24 0:00 > /usr/sbin/sshd > > The thing to look for is "/usr/sbin/sshd". If you don't see it, it's not > running. The pipe symbol doesn't work on the keyboard at present attached - I have just trid. I have shutdown for now. I'll attach another keyboard and test and then put this thread to bed - at least, my part of it. But probably not for a couple of days. But I'll write a summary then. I am most grateful for all the help you lot have given me. Lisi
Re: ssh-ing in inside private network
On Tue, May 31, 2016, at 19:25, Lisi Reisz wrote: > ... > Assuming that sshd is actually running at that stage, which it looks as > though > it isn't > ... Looks as though I've given you mostly information that you don't need. Sorry about that. At the risk of doing so again, here's how you can tell if the ssh daemon is running. Issue ps aux|grep ssh You should see something like the following in the output: root 709 0.0 0.0 10200 3632 ?Ss May24 0:00 /usr/sbin/sshd The thing to look for is "/usr/sbin/sshd". If you don't see it, it's not running. -- .''`. Stephen Powell : :' : `. `'` `-
Re: ssh-ing in inside private network
On Tuesday 31 May 2016 23:56:39 Stephen Powell wrote: > On Tue, May 31, 2016, at 15:31, Lisi Reisz wrote: > > ... > > So I need static IPs fast! > > ... > > (The above was actually quoted from an earlier post). > If you want to convert your computers to use static IP addresses, you might > want to take a look at the following web page: > >http://www.stevesdebianstuff.org/hercules.htm > > The main subject of the web page is running Debian under Hercules under > Debian, which of course you are not interested in. But in the process of > documenting that there is a discussion about converting the host system for > Hercules to use a static IP address. Using static IP addresses has some > little known "gotchas", which are covered above. See the section titled > "Networking changes". It also covers switching from network-manager to > ifupdown, but if I recall correctly, you've already made that conversion. > > You might also want to take a look at the section titled "Router > reconfiguration". In your case, you probably don't need or want to > reconfigure the router, but you might want to get into the reconfiguration > screens so that you can find out for sure which addresses are in the > router's DHCP pool, so that you can chose a static IP address which is > *inside* the router's network but *outside* the DHCP pool. That way, you > can be sure that your static IP address will never interfere with what DHCP > wants to do. > > > Help!! This was the point of the whole exercise. I want CLI only (no X > > running) access to the Ubuntu installation on Hermes. > > Ubuntu systems usually do not have a password assigned to root. Therefore, > you have to use sudo for all administrative work. If you want to *be* > root, so that all commands issued run with root privileges, you have to > assign a password to root with > >sudo passwd root > > I recommend that you ssh into the machine as a non-root user first, then > elevate privileges by running a nested root shell via > >su > > After you supply the root password, which you just set earlier, your > privileges will be escalated to root privileges until you enter the > >exit > > command, which will return you to your former non-root self. It is > possible to login remotely as root, if the configuration of the host > system's ssh server allows it, but "best practices" recommends against it > for security reasons. It makes your home network easier to hack. But if > you really want to do it, edit the file /etc/ssh/sshd_config. In the > ># Authentication > > section, look for > >Permitrootlogin no > > and change it to > >Permitrootlogin yes > > then bounce the ssh daemon with > >/etc/init.d/ssh restart > > As I said, it's not recommended; > but it's your gun, your bullet, and your foot! :-) Thanks for this Stephen. Static IPs have been set up in my router ever since I said that I obviously needed static IPs. I used to do it via e,n,i , but nowadays I reserve IPs by MAC number in the router, and this is what I have done here. I have also already set up a root password, and that is what the screen actually attached to the computer was asking for - which was why I was trying to log in as root. In the normal way I would indeed want to log in as $USER and su into root if I needed root access. Assuming that sshd is actually running at that stage, which it looks as though it isn't, then I could always edit the authentication section temporarily and put it back when I have finished. But if I can log in as $USER, I don't need to log in as root. Once in, I can su. But the screen attached to the computer was asking for root, so I thought the computer wouldn't accept anything else at that stage. I only need to do one thing remotely at this level, and if I can't do it, I shall yet again give up any attempt to run Ubuntu, even as a dual boot. And I have now basically got ssh working over my private network \o/, and have used it for updating my husband's computer while he was sitting at it!! (Note update not upgrade!) Lisi
Re: ssh-ing in inside private network
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
Re: ssh-ing in inside private network
On Tue, May 31, 2016, at 15:31, Lisi Reisz wrote: > ... > So I need static IPs fast! > ... (The above was actually quoted from an earlier post). If you want to convert your computers to use static IP addresses, you might want to take a look at the following web page: http://www.stevesdebianstuff.org/hercules.htm The main subject of the web page is running Debian under Hercules under Debian, which of course you are not interested in. But in the process of documenting that there is a discussion about converting the host system for Hercules to use a static IP address. Using static IP addresses has some little known "gotchas", which are covered above. See the section titled "Networking changes". It also covers switching from network-manager to ifupdown, but if I recall correctly, you've already made that conversion. You might also want to take a look at the section titled "Router reconfiguration". In your case, you probably don't need or want to reconfigure the router, but you might want to get into the reconfiguration screens so that you can find out for sure which addresses are in the router's DHCP pool, so that you can chose a static IP address which is *inside* the router's network but *outside* the DHCP pool. That way, you can be sure that your static IP address will never interfere with what DHCP wants to do. > > Help!! This was the point of the whole exercise. I want CLI only (no X > running) access to the Ubuntu installation on Hermes. > Ubuntu systems usually do not have a password assigned to root. Therefore, you have to use sudo for all administrative work. If you want to *be* root, so that all commands issued run with root privileges, you have to assign a password to root with sudo passwd root I recommend that you ssh into the machine as a non-root user first, then elevate privileges by running a nested root shell via su After you supply the root password, which you just set earlier, your privileges will be escalated to root privileges until you enter the exit command, which will return you to your former non-root self. It is possible to login remotely as root, if the configuration of the host system's ssh server allows it, but "best practices" recommends against it for security reasons. It makes your home network easier to hack. But if you really want to do it, edit the file /etc/ssh/sshd_config. In the # Authentication section, look for Permitrootlogin no and change it to Permitrootlogin yes then bounce the ssh daemon with /etc/init.d/ssh restart As I said, it's not recommended; but it's your gun, your bullet, and your foot! -- .''`. Stephen Powell : :' : `. `'` `-
Re: ssh-ing in inside private network
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
Re: ssh-ing in inside private network
On Tuesday 31 May 2016 21:51:30 Joe wrote: > On Tue, 31 May 2016 20:31:32 +0100 > > 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 > > --- > > > > Help!! This was the point of the whole exercise. I want CLI only > > (no X running) access to the Ubuntu installation on Hermes. > > > > Where next? > > Sorry, I delete blocks of messages now and then and I don't have any of > this thread. > > The 'No route to host' for root only looks odd. This is of course a > routing message. If I try to login as root on a server where root isn't > permitted to login, I get a straightforward 'Permission denied' message. > > Can you try nmap 192.168.0.5 -p 22 both as lisi and as root? This will > test both routing and firewall rules of client and server, and the > correct answer should be approximately: > > > $ nmap 192.168.101.3 -p 22 > > Starting Nmap 7.12 ( https://nmap.org ) at 2016-05-31 21:09 BST > Nmap scan report for server.jretrading.com (192.168.101.3) > Host is up (0.00045s latency). > PORT STATE SERVICE > 22/tcp open ssh > > Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds > > and really ought to be pretty much the same for root and non-root > users, except that root is also given the MAC address of the machine. If > there is another difference, and there must be, then we can go from > there. With out-of-the-box Debian machines, this should all Just Work, > but it may be that Ubuntu is being 'helpful'. > > nmap is not of course attempting to login, so the only part of the > server sshd_config which is being tested is the interface and port > specification. There are other configurations of both client and server > which can interfere, and we hope to identify any such problems arising. > > But can you really not use a non-root user for ssh? I don't have root > ssh access to my (no X) server, but it doesn't stop me doing things to > it. In answer to John and Joe (thank you, John and Joe) lisi@Tux-II:~$ ssh lisi@192.168.0.5 ssh: connect to host 192.168.0.5 port 22: No route to host lisi@Tux-II:~$ nmap 192.168.0.5 -p 22 Starting Nmap 6.00 ( http://nmap.org ) at 2016-05-31 23:11 BST Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 3.02 seconds lisi@Tux-II:~$ nmap 192.168.0.5 -Pn 22 Starting Nmap 6.00 ( http://nmap.org ) at 2016-05-31 23:11 BST Invalid target host specification: 22 Nmap scan report for 192.168.0.5 Host is up (0.097s latency). All 1000 scanned ports on 192.168.0.5 are filtered Nmap done: 1 IP address (1 host up) scanned in 14.30 seconds lisi@Tux-II:~$ su Password: root@Tux-II:/home/lisi# nmap 192.168.0.5 -p 22 Starting Nmap 6.00 ( http://nmap.org ) at 2016-05-31 23:13 BST Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 0.50 seconds root@Tux-II:/home/lisi# nmap 192.168.0.5 -Pn Starting Nmap 6.00 ( http://nmap.org ) at 2016-05-31 23:14 BST Nmap done: 1 IP address (0 hosts up) scanned in 0.52 seconds root@Tux-II:/home/lisi# nmap 192.168.0.5 -Pn 22 Starting Nmap 6.00 ( http://nmap.org ) at 2016-05-31 23:14 BST Invalid target host specification: 22 Nmap done: 1 IP address (0 hosts up) scanned in 0.50 seconds root@Tux-II:/home/lisi# su lisi lisi@Tux-II:~$ ssh lisi@192.168.0.5 ssh: connect to host 192.168.0.5 port 22: No route to host lisi@Tux-II:~$ So I tried again as me, with the 22 correctly omitted. There was a slight delay, and I got: lisi@Tux-II:~$ nmap 192.168.0.5 -Pn Starting Nmap 6.00 ( http://nmap.org ) at 2016-05-31 23:20 BST Nmap scan report for 192.168.0.5 Host is up (0.093s latency). All 1000 scanned ports on 192.168.0.5 are filtered Nmap done: 1 IP address (1 host up) scanned in 14.18 seconds lisi@Tux-II:~$ So, even when correctly entered, it agrees with me that one host is up. So, in spite of the error messages, the host is up. And it would appear that it is correctly recognising the network. Have the ssh server and client perhaps not been started? Are they not started at level one? Now to do man nmap as I should have done before copying and pasting!! Incidentally, John, "face to face" as it were, it will only let me log in as root in that level, which is why I was trying to do so. "Enter root password for maintenance." Lisi Lisi
Re: ssh-ing in inside private network
On Tue, 31 May 2016 20:31:32 +0100 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 > --- > > Help!! This was the point of the whole exercise. I want CLI only > (no X running) access to the Ubuntu installation on Hermes. > > Where next? > Sorry, I delete blocks of messages now and then and I don't have any of this thread. The 'No route to host' for root only looks odd. This is of course a routing message. If I try to login as root on a server where root isn't permitted to login, I get a straightforward 'Permission denied' message. Can you try nmap 192.168.0.5 -p 22 both as lisi and as root? This will test both routing and firewall rules of client and server, and the correct answer should be approximately: $ nmap 192.168.101.3 -p 22 Starting Nmap 7.12 ( https://nmap.org ) at 2016-05-31 21:09 BST Nmap scan report for server.jretrading.com (192.168.101.3) Host is up (0.00045s latency). PORT STATE SERVICE 22/tcp open ssh Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds and really ought to be pretty much the same for root and non-root users, except that root is also given the MAC address of the machine. If there is another difference, and there must be, then we can go from there. With out-of-the-box Debian machines, this should all Just Work, but it may be that Ubuntu is being 'helpful'. nmap is not of course attempting to login, so the only part of the server sshd_config which is being tested is the interface and port specification. There are other configurations of both client and server which can interfere, and we hope to identify any such problems arising. But can you really not use a non-root user for ssh? I don't have root ssh access to my (no X) server, but it doesn't stop me doing things to it. -- Joe
Re: ssh-ing in inside private network
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 to...@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: - lisi@Tux-II:~/.ssh$ ls known_hosts lisi@Tux-II:~/.ssh$ mv known_hosts known_hosts.old lisi@Tux-II:~/.ssh$ ls known_hosts.old lisi@Tux-II:~/.ssh$ ssh peter@192.168.0.3 The authenticity of host '192.168.0.3 (192.168.0.3)' can't be established. ECDSA key fingerprint is 08:3b:5d:cd:fd:cf:1c:c2:22:e2:09:85:51:cb:7e:01. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.3' (ECDSA) to the list of known hosts. peter@192.168.0.3's password: [snip] peter@Nyx-II:~$ su Password: [snip successful update/upgrade via ssh] root@Nyx-II:/home/peter# exit exit peter@Nyx-II:~$ ~ -bash: /home/peter: Is a directory peter@Nyx-II:~$ logout Connection to 192.168.0.3 closed. lisi@Tux-II:~/.ssh$ ssh peter@Nyx-II ssh: Could not resolve hostname Nyx-II: Name or service not known lisi@Tux-II:~/.ssh$ cat known_hosts 192.168.0.3 ecdsa-sha2-nistp256 E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBPtZCRJi2qUfVbHC2xSJbDbnLDnxNIAc9gIQkhmT1MDtsWKqfKeAAp9zWhXP+ZN7E57tCqERtJM4UktWMnxnpY4= lisi@Tux-II:~/.ssh$ ssh peter@192.168.0.4 The authenticity of host '192.168.0.4 (192.168.0.4)' can't be established. ECDSA key fingerprint is d9:2e:38:29:07:f8:8a:6d:4b:dd:28:60:ad:c9:e5:a3. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.4' (ECDSA) to the list of known hosts. peter@192.168.0.4's password: The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed May 25 00:04:29 2016 peter@Eros:~$ logout Connection to 192.168.0.4 closed. lisi@Tux-II:~/.ssh$ ssh lisi@192.168.0.5 The authenticity of host '192.168.0.5 (192.168.0.5)' can't be established. ECDSA key fingerprint is bd:35:63:80:a8:e8:37:c5:0a:f6:05:03:3c:00:a8:f7. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.5' (ECDSA) to the list of known hosts. lisi@192.168.0.5's password: Permission denied, please try again. lisi@192.168.0.5's password: Connection closed by 192.168.0.5 lisi@Tux-II:~/.ssh$ ssh lisi@192.168.0.5 lisi@192.168.0.5's password: The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. You have new mail. Last login: Tue May 24 14:27:14 2016 lisi@Hermes:~$ logout Connection to 192.168.0.5 closed. -- lisi@Tux-II:~/.ssh$ ssh root@192.168.0.5 ssh: connect to host 192.168.0.5 port 22: No route to host lisi@Tux-II:~/.ssh$ 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. Delete relevant line from known_hosts (now unencoded), and then: lisi@Tux-II:~$ ssh lisi@192.168.0.5 The authenticity of host '192.168.0.5 (192.168.0.5)' can't be established. ECDSA key fingerprint is 06:8b:1e:77:8d:7f:56:50:6f:13:30:d7:13:92:36:20. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.5' (ECDSA) to the list of known hosts. lisi@192.168.0.5's password: Welcome to Ubuntu 16.04 LTS (GNU/Linux 4.4
Re: ssh-ing in inside private network
On Thu 31 Mar 2016 at 14:34:47 (+0200), to...@tuxteam.de wrote:
> On Thu, Mar 31, 2016 at 01:27:35PM +0100, Lisi Reisz wrote:
> > It is installed and running. I can ssh from Eros, but not into it. If I
> > just
> > try to ssh from Tux-II to Eros, I get the error "Could not connect to host
> > 192.168.0.4.". I'm actually "fish"ing, but same difference.
> >
> > I get a more helpful message form ssh:
> > lisi@Tux-II:~$ ssh peter@192.168.0.4
> > @@@
> > @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
> > @@@
> > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> > Someone could be eavesdropping on you right now (man-in-the-middle attack)!
> > It is also possible that a host key has just been changed.
> > The fingerprint for the ECDSA key sent by the remote host is
> > d9:2e:38:29:07:f8:8a:6d:4b:dd:28:60:ad:c9:e5:a3.
> > Please contact your system administrator.
> > Add correct host key in /home/lisi/.ssh/known_hosts to get rid of this
> > message.
> > Offending ECDSA key in /home/lisi/.ssh/known_hosts:3
> > ECDSA host key for 192.168.0.4 has changed and you have requested strict
> > checking.
> > Host key verification failed.
> > lisi@Tux-II:~$
>
> Ah, yes. That means that Eros's (that is 192.168.0.4, right?) "ssh host key"
> has changed. Every host gets a "host key" the first time its ssh server is
> set up (usually assigned by random), which it presents to the client as
> an identification [1]. The client itself registers it the first time it sees
> it and yells bloody murder if that ever changes: that's what you are seeing
> above. Someone nasty is impersonating your good old Eros.
>
> If you know Eros has just "changed personality", you just have to delete
> the record your ssh client has on Tux-II of that old host key. The text
> above tells you where: it's in /home/lisi/.ssh/known_hosts, line 3.
>
> The next time you ssh into Eros you'll get a notice that Eros isn't known
> and whether to trust it -- from then on it's as before.
man ssh-keygen is a formidable page, but buried in there are commands
for doing this (as known_hosts is encrypted):
If foo is the remote host:
$ ssh-keygen -l -v -f ~/.ssh/known_hosts -t ecdsa -F foo
will display if foo is present in your file and
$ ssh-keygen -f ~/.ssh/known_hosts -t ecdsa -R foo
will remove it. (Hostname and IP address have to be handled individually.)
Related to this, if you're in the habit of installing systems through
the ssh facility (which makes it easy to screen-capture the process),
I find it useful to have a bash function defined as:
ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null
${2:-installer}@"$1"
This avoids polluting my local host with the ephemeral keys that the
debian-installer just generated on the host being installed to.
Using this command still generates Lisi's message (which you OK),
but the exchanged keys are used, but also thrown away.
> > 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
> > need to do it. It clearly needs to move up my priority list. (New router.
> >
> > reserved MAC numbers not yet set up in teh DHCP section.)
>
> Basically it hasn't much to do with that -- only that your SSH clients (be
> it fish, be it ssh) associate the host name/IP address they see with the
> host keys. Of course, if the IPs keep changing, then they have a moving
> target, and you'll have a difficult life :-)
Having read Brian's post here (thanks), I'm going to try decimating my
hosts file and using foo.local to see how it works out (even though my
router assigns all the IP numbers statically).
Cheers,
David.
Re: ssh-ing in inside private network
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
Re: ssh-ing in inside private network
-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, to...@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-
Re: ssh-ing in inside private network
On Thu 31 Mar 2016 at 13:27:35 +0100, Lisi Reisz wrote: > On Thursday 31 March 2016 12:28:57 to...@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.
Re: ssh-ing in inside private network
On Thu 31 Mar 2016 at 14:38:05 +0200, to...@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.
Re: ssh-ing in inside private network
-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-
Re: ssh-ing in inside private network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Mar 31, 2016 at 01:27:35PM +0100, Lisi Reisz wrote: > Great! Thankl you! I now have a starting point for my questions. > > On Thursday 31 March 2016 12:28:57 to...@tuxteam.de wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > 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?? > > > 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. > > Great! Thankl you! I now have a starting point for my questions. > > > > 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) > > How do I check this? I suspect that it may be the problem, so the problem > may > in fact be on the computer I want to ssh from, if the Jessie computer cannot > see it? Oh! Let us use their names. the computer running Wheezy is called > Tux-II. The computer running Jessie is called Eros. > > > 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? By default it will be running when installed. To double-check that there are several ways to do it: tomas@rasputin:~$ ps wwwaux | grep sshd root 3224 0.0 0.0 55336 3364 ?Ss 12:53 0:00 /usr/sbin/sshd tomas 8721 0.0 0.0 7960 736 pts/4S+ 14:48 0:00 grep sshd ...there you see the sshd process on my box running and willing to serve. Or this: tomas@rasputin:~$ sudo netstat -antp | grep sshd tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3224/sshd tcp6 0 0 :::22 :::*LISTEN 3224/sshd ...here you see sshd on my box listening on port 22 and willing to play. But I think you're already past that point, see below. > > 3. To connect, you need also an openssh-client (since this has priority > >"standard" n Debian, chances are that it's there already) > > It is installed and running. I can ssh from Eros, but not into it. If I > just > try to ssh from Tux-II to Eros, I get the error "Could not connect to host > 192.168.0.4.". I'm actually "fish"ing, but same difference. > > I get a more helpful message form ssh: > lisi@Tux-II:~$ ssh peter@192.168.0.4 > @@@ > @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle attack)! > It is also possible that a host key has just been changed. > The fingerprint for the ECDSA key sent by the remote host is > d9:2e:38:29:07:f8:8a:6d:4b:dd:28:60:ad:c9:e5:a3. > Please contact your system administrator. > Add correct host key in /home/lisi/.ssh/known_hosts to get rid of this > message. > Offending ECDSA key in /home/lisi/.ssh/known_hosts:3 > ECDSA host key for 192.168.0.4 has changed and you have requested strict > checking. > Host key verification failed. > lisi@Tux-II:~$ Ah, yes. That means that Eros's (that is 192.168.0.4, right?) "ssh host key" has changed. Every host gets a "host key" the first time its ssh server is set up (usually assigned by random), which it presents to the client as an identification [1]. The client itself registers it the first time it sees it and yells bloody murder if that ever changes: that's what you are seeing above. Someone nasty is impersonating your good old Eros. If you know Eros has just "changed personality", you just have to delete the record your ssh client has on Tux-II of that old host key. The text above tells you where: it's in /home/lisi/.ssh/known_hosts, line 3. The next time you ssh into Eros you'll get a notice that Eros isn't known and whether to trust it -- from then on it's as before. > 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 > need to do it. It clearly needs to move up my priority list. (New router. > reserved MAC numbers not yet set up in teh DHCP section.) Basically it hasn't much to do with that -- only that your SSH clients (be it fish, be it ssh) associate the host name/IP address they see with the host keys. Of course, if the IP
Re: ssh-ing in inside private network
On Thu 31 Mar 2016 at 13:28:57 +0200, to...@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.
Re: ssh-ing in inside private network
Great! Thankl you! I now have a starting point for my questions. On Thursday 31 March 2016 12:28:57 to...@tuxteam.de wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > 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?? > 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. Great! Thankl you! I now have a starting point for my questions. > > 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) How do I check this? I suspect that it may be the problem, so the problem may in fact be on the computer I want to ssh from, if the Jessie computer cannot see it? Oh! Let us use their names. the computer running Wheezy is called Tux-II. The computer running Jessie is called Eros. > 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? > 3. To connect, you need also an openssh-client (since this has priority >"standard" n Debian, chances are that it's there already) It is installed and running. I can ssh from Eros, but not into it. If I just try to ssh from Tux-II to Eros, I get the error "Could not connect to host 192.168.0.4.". I'm actually "fish"ing, but same difference. I get a more helpful message form ssh: lisi@Tux-II:~$ ssh peter@192.168.0.4 @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is d9:2e:38:29:07:f8:8a:6d:4b:dd:28:60:ad:c9:e5:a3. Please contact your system administrator. Add correct host key in /home/lisi/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/lisi/.ssh/known_hosts:3 ECDSA host key for 192.168.0.4 has changed and you have requested strict checking. Host key verification failed. lisi@Tux-II:~$ 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 need to do it. It clearly needs to move up my priority list. (New router. reserved MAC numbers not yet set up in teh DHCP section.) I have to go now, but I think you have solved it!! (I hadn't researched how to use ssh itself. :-( I was scared of it. :-( ) Thank you. I'll continue later! I'm most grateful, Tomas. Lisi >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.
Re: ssh-ing in inside private network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. Regards & good luck - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlb9CfkACgkQBcgs9XrR2kbWXwCfdMrvMU2o8qDihX+uG55/E7zu 108AnitmEOWZuGUijGj5XiIMb7vyFey6 =3LpP -END PGP SIGNATURE-
