[K12OSN] Users can't login
Gideon Romm
ltsp at symbio-technologies.com
Thu Dec 2 15:38:48 UTC 2010
You should get yourself a shell on the thin client (either by setting
SCREEN_02=shell, SCREEN_07=ldm OR by setting a root password in the
chroot and switching to the console after boot)
Then, try: ssh user at server
from the shell.
If you get prompted with an "Are you sure?" or an "invalid key"
message, then your ssh keys are not in fact making it over - perhaps
you inadvertantly have a /root/.ssh/known_hosts file in your chroot
which you should not have?
Otherwise, if it is not a key issue, it could also be a compiz issue.
Disable or remove compiz from the server and try logging in again.
These are probably the top two causes of failed logins.
-Gadi
PS: If you care little about man-in-the-middle attacks, you can always
set "StrictHostKeyChecking no" in the chroot's /etc/ssh/ssh_config,
and avoid ssh key issues.
Barry Cisna wrote:
>Brian,
>
>A few more things to consider.
>
>1. You are using an unmanaged switch in your setup?
>In other words a cheapo plug n play 10/100/(1000) switch.
>I am trying to picture your setup? You have a dsl into your home with a
>provided router. Your server is plugged into one of the lan ports, the
>TC is plugged into another lan port ,correct.
To clarify: my cable service provides a modem that the TV coax
connects to, and that has an Ethernet port. I have a
wireless router connected to the modem, so the router gets
its IP address by DHCP and DNS services from the provider.
All machines at home plug into this router. So the server has
a static IP address, and the client, and various laptops, get
their IP addresses from the LTSP DHCP server. (The router does
NOT have DHCP turned on, and the regular DHCP service is not
running on the server. The only DHCP service is from LTSP.)
>
>Nope ,I just thought, this can not work. You are *only* seeing a class C
>ip address? hhhmmm
I don't know what a class C IP address is, but that may not be relevant.
However - LTSP did work until I upgraded to Fedora13 and
installed LTSP5.2.4.5.
I should revise that. I am not certain that LTSP, per se, isn't working.
As I say, the client clearly finds the image, so I would think that
means that the networking end of things is good, and the image boots
properly, and we get the login screen, but after userid and password
are entered, it returns to the login screen. Maybe it's something
to do with ldm, although that doesn't seem well documented, so it's
hard to make guesses.
>1a. do 'ifconfig' and copy/paste back the response.
eth0 Link encap:Ethernet HWaddr 00:1E:8C:68:38:D7
inet addr:192.168.1.103 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::21e:8cff:fe68:38d7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:543342 errors:0 dropped:0 overruns:0 frame:0
TX packets:602301 errors:0 dropped:0 overruns:0 carrier:11
collisions:0 txqueuelen:1000
RX bytes:305945407 (291.7 MiB) TX bytes:639198479 (609.5 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:105465 errors:0 dropped:0 overruns:0 frame:0
TX packets:105465 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:105169058 (100.2 MiB) TX bytes:105169058 (100.2 MiB)
ltspbr0 Link encap:Ethernet HWaddr 62:4C:94:CF:5C:15
inet addr:172.31.100.254 Bcast:172.31.100.255 Mask:255.255.255.0
inet6 addr: fe80::604c:94ff:fecf:5c15/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:2588 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:793267 (774.6 KiB)
>
>2. I wasn't clear enough. Can root log into the server * from a thin
>client*. Not ssh.
No. Root can't login at the GUI login prompt on the client. But
in any case, I think root is prohibited by default from running
a GNOME session.
>
>3. I see that tcp 7100 is not listening. This is usually the case
>although I am not familiar with ltsp5 so this may not be necessary now.
>
>4. It appears your ISP is setting the correct setting into your resolve
>file for 127.0.0.1 as it is listed now.
>
>5. Run the command 'hostname' and report back what the response is.
{orpheus:/home/brian/orpheus/ltsp/5.2.4.5_CantLogin}hostname
orpheus
>
>6. Open a terminal (as root) and do a ' tail -f /var/log/messages' .
>After you have the terminal open,try logging into the server from a thin
>client.
>Copy/Paste about the last 100 lines into a message here. Maybe something
>will pop out of what is happening here.
>
NOTE: there are a number of 'dhcpd' messages below. On my system,
dhcpd, dhcpd6 and dhcrelay are all disabled. ltsp-dhcpd is shown
as enabled. I would expect the messages to say 'ltsp-dhcpd', but
that's what I got.
So in these messages, we see the requests from the thin client
as it gets an IP address, and downloads the image.
I am also appending to the end some lines from /var/log/secure that
show the user authenticating.
---------------------------------------------------------------------
from /var/log/messages
Dec 2 08:09:47 orpheus dhcpd: DHCPDISCOVER from 00:13:90:02:9a:ee via eth0
Dec 2 08:09:48 orpheus dhcpd: DHCPOFFER on 192.168.1.116 to
00:13:90:02:9a:ee via eth0
Dec 2 08:09:50 orpheus dhcpd: DHCPREQUEST for 192.168.1.116
(192.168.1.103) from 00:13:90:02:9a:ee via eth0
Dec 2 08:09:50 orpheus dhcpd: DHCPACK on 192.168.1.116 to
00:13:90:02:9a:ee via eth0
Dec 2 08:09:50 orpheus xinetd[2467]: START: tftp pid=28928 from=192.168.1.116
Dec 2 08:09:50 orpheus in.tftpd[28929]: tftp: client does not accept options
Dec 2 08:10:03 orpheus dhcpd: DHCPDISCOVER from 00:13:90:02:9a:ee via eth0
Dec 2 08:10:03 orpheus dhcpd: DHCPOFFER on 192.168.1.116 to
00:13:90:02:9a:ee via eth0
Dec 2 08:10:03 orpheus dhcpd: DHCPREQUEST for 192.168.1.116
(192.168.1.103) from 00:13:90:02:9a:ee via eth0
Dec 2 08:10:03 orpheus dhcpd: DHCPACK on 192.168.1.116 to
00:13:90:02:9a:ee via eth0
Dec 2 08:10:05 orpheus xinetd[2467]: START: nbdrootd pid=28953
from=::ffff:192.168.1.116
Dec 2 08:10:05 orpheus nbd-server: connect from 192.168.1.116,
assigned file is /opt/ltsp/images/i386.img
Dec 2 08:10:05 orpheus nbd-server: Size of exported file/device is 314269696
Dec 2 08:10:20 orpheus xinetd[2467]: START: ldminfod pid=28955
from=::ffff:192.168.1.116
Dec 2 08:10:20 orpheus xinetd[2467]: EXIT: ldminfod status=0
pid=28955 duration=0(sec)
Dec 2 08:10:20 orpheus xinetd[2467]: START: ldminfod pid=28958
from=::ffff:192.168.1.116
Dec 2 08:10:20 orpheus xinetd[2467]: EXIT: ldminfod status=0
pid=28958 duration=0(sec)
Dec 2 08:10:25 orpheus xinetd[2467]: START: nbdrootd pid=28961
from=::ffff:192.168.1.116
Dec 2 08:10:25 orpheus nbd-server: connect from 192.168.1.116,
assigned file is /opt/ltsp/images/i386.img
Dec 2 08:10:25 orpheus nbd-server: Size of exported file/device is 314269696
Dec 2 08:10:25 orpheus nbd-server: Disconnect request received.
Dec 2 08:10:25 orpheus xinetd[2467]: EXIT: nbdrootd status=0
pid=28961 duration=0(sec)
Dec 2 08:15:36 orpheus xinetd[2467]: START: ldminfod pid=29029
from=::ffff:192.168.1.116
Dec 2 08:15:36 orpheus xinetd[2467]: EXIT: ldminfod status=0
pid=29029 duration=0(sec)
Dec 2 08:15:36 orpheus xinetd[2467]: START: ldminfod pid=29032
from=::ffff:192.168.1.116
Dec 2 08:15:36 orpheus xinetd[2467]: EXIT: ldminfod status=0
pid=29032 duration=0(sec)
Dec 2 08:15:38 orpheus xinetd[2467]: START: nbdrootd pid=29035
from=::ffff:192.168.1.116
Dec 2 08:15:38 orpheus nbd-server: connect from 192.168.1.116,
assigned file is /opt/ltsp/images/i386.img
Dec 2 08:15:38 orpheus nbd-server: Size of exported file/device is 314269696
Dec 2 08:15:38 orpheus nbd-server: Disconnect request received.
Dec 2 08:15:38 orpheus xinetd[2467]: EXIT: nbdrootd status=0
pid=29035 duration=0(sec)
Dec 2 08:15:59 orpheus xinetd[2467]: START: ldminfod pid=29048
from=::ffff:192.168.1.116
Dec 2 08:15:59 orpheus xinetd[2467]: EXIT: ldminfod status=0
pid=29048 duration=0(sec)
Dec 2 08:15:59 orpheus xinetd[2467]: START: ldminfod pid=29051
from=::ffff:192.168.1.116
Dec 2 08:15:59 orpheus xinetd[2467]: EXIT: ldminfod status=0
pid=29051 duration=0(sec)
Dec 2 08:16:01 orpheus xinetd[2467]: START: nbdrootd pid=29054
from=::ffff:192.168.1.116
Dec 2 08:16:01 orpheus nbd-server: connect from 192.168.1.116,
assigned file is /opt/ltsp/images/i386.img
Dec 2 08:16:01 orpheus nbd-server: Size of exported file/device is 314269696
Dec 2 08:16:01 orpheus nbd-server: Disconnect request received.
Dec 2 08:16:01 orpheus xinetd[2467]: EXIT: nbdrootd status=0
pid=29054 duration=0(sec)
Dec 2 08:16:14 orpheus xinetd[2467]: START: ldminfod pid=29075
from=::ffff:192.168.1.116
Dec 2 08:16:14 orpheus xinetd[2467]: EXIT: ldminfod status=0
pid=29075 duration=0(sec)
Dec 2 08:16:14 orpheus xinetd[2467]: START: ldminfod pid=29078
from=::ffff:192.168.1.116
Dec 2 08:16:14 orpheus xinetd[2467]: EXIT: ldminfod status=0
pid=29078 duration=0(sec)
Dec 2 08:16:15 orpheus xinetd[2467]: START: nbdrootd pid=29081
from=::ffff:192.168.1.116
Dec 2 08:16:15 orpheus nbd-server: connect from 192.168.1.116,
assigned file is /opt/ltsp/images/i386.img
Dec 2 08:16:15 orpheus nbd-server: Size of exported file/device is 314269696
Dec 2 08:16:15 orpheus nbd-server: Disconnect request received.
Dec 2 08:16:15 orpheus xinetd[2467]: EXIT: nbdrootd status=0
pid=29081 duration=0(sec)
Dec 2 08:24:51 orpheus xinetd[2467]: EXIT: tftp status=0 pid=28928
duration=901(sec)
---------------------------------------------------------------------------------
Now here's what we see in /var/log/secure when user 'birch' tries to login at
the thin client:
Dec 2 09:01:31 orpheus sshd[30963]: Accepted password for birch from
192.168.1.116 port 38445 ssh2
Dec 2 09:01:31 orpheus sshd[30963]: pam_unix(sshd:session): session
opened for user birch by (uid=0)
Dec 2 09:01:32 orpheus sshd[30965]: Received disconnect from
192.168.1.116: 11: disconnected by user
Dec 2 09:01:32 orpheus sshd[30963]: pam_unix(sshd:session): session
closed for user birch
I had posted similar messages some time ago, and was advised to run
ltsp-update-sshkeys before I run sudo ltsp-update-image, which is now
part of my standard procedure. So it seems likely that the image is getting
the correct ssh keys.
More information about the K12OSN
mailing list