Hi,
next problem on my way to a working environment for my PC/104 system... When I try to start lshd it claims that I should run lsh-make-seed. I've tried that, but even with --sloppy the call simply doesn't return and the system waits forever (or ctrl-c). -v and --trace didn't give much more info:
/ # /sbin/lshd -v No seed file. Please create one by running lsh-make-seed -o "/var/spool/lsh/yarrow-seed-file". lshd: No randomness generator available. / # lsh-make-seed -o /var/spool/lsh/yarrow-seed-file --sloppy -v --trace lsh-make-seed: Reading /dev/random... <waiting forever>
I know that the system will probably not have enough entropy, at least not at the moment (might change a bit when the application is actually running), but even a bad key would be better than telnet...
Robert
Robert Schwebel robert@schwebel.de writes:
next problem on my way to a working environment for my PC/104 system... When I try to start lshd it claims that I should run lsh-make-seed. I've tried that, but even with --sloppy the call simply doesn't return and the system waits forever (or ctrl-c). -v and --trace didn't give much more info:
...
lsh-make-seed: Reading /dev/random...
<waiting forever>
I'm not sure what is the best way to solve the problem. Some workarounds:
* Wait even longer, and type like crazy (preferably on a different vt) at the same time.
* Remove the /dev/random node, or link it to /dev/urandom, while running lsh-make-seed.
* Hack lsh-make-seed.c, to not try reading /dev/random,
*** /home/nisse/hack/lsh/src/lsh-make-seed.c~ Sun Aug 25 22:16:27 2002 --- /home/nisse/hack/lsh/src/lsh-make-seed.c Thu Oct 3 22:32:55 2002 *************** *** 271,277 **** get_dev_random(struct yarrow256_ctx *ctx, enum source_type source) { static const char *names[] = ! { "/dev/random", "/dev/urandom", NULL };
int fd = -1; --- 271,277 ---- get_dev_random(struct yarrow256_ctx *ctx, enum source_type source) { static const char *names[] = ! { "/dev/urandom", NULL };
int fd = -1;
should do.
* Run lsh-make-seed on a different (trusted) machine with more entropy, and transfer it by floppy or something.
I know that the system will probably not have enough entropy, at least not at the moment (might change a bit when the application is actually running), but even a bad key would be better than telnet...
It would make sense to have --sloppy use a timeout, but that's not entirely trivial to implement. Perhaps --sloppy should imply reading /dev/urandom rather than /dev/random, that should be easier to implement?
Regards, /Niels
Hi Niels,
On Thu, Oct 03, 2002 at 10:37:07PM +0200, Niels Möller wrote:
It would make sense to have --sloppy use a timeout, but that's not entirely trivial to implement. Perhaps --sloppy should imply reading /dev/urandom rather than /dev/random, that should be easier to implement?
I have now generated the seed file on my development machine and copied it over - lsh-keygen worked afterwards.
However, I cannot login to the box:
----------8<----------client----------8<----------8<---------- robert@ganymed:~> ssh root@192.168.1.54 root@192.168.1.54's password: Permission denied, please try again. ----------8<----------client----------8<----------8<----------
----------8<----------server----------8<----------8<---------- ~ # lshd --debug [...] hd: DEBUG: Received USERAUTH_REQUEST ***** lshd: handle_connection: Received packet of type 50 (USERAUTH_REQUEST) lshd: DEBUG: Sent USERAUTH_FAILURE lshd: (size 24 = 0x18) 00000000: 330000001270617373776f72642c7075 3....password,pu 00000010: 626c69636b657900 blickey.
lshd: write_buffer: do_write length = 56 lshd: write_buffer: do_write closure->length = 56 lshd: DEBUG: Received IGNORE lshd: (size 53 = 0x35) 00000000: 020000003034e737d9af0e8a2900c2e8 ....04.7....)... 00000010: 8a94d208c5253f112f5aa38bd0bd73c3 .....%?./Z....s. 00000020: 95d7bc7e31e3753a7b3aab7dcaf6f9e3 ...~1.u:{:.}.... 00000030: 52afbf0d1a R....
lshd: handle_connection: Received packet of type 2 (IGNORE) ----------8<----------server----------8<----------8<----------
Any idea what the problem could be?
Cheers, Robert
Robert Schwebel robert@schwebel.de writes:
However, I cannot login to the box:
----------8<----------client----------8<----------8<---------- robert@ganymed:~> ssh root@192.168.1.54 root@192.168.1.54's password: Permission denied, please try again. ----------8<----------client----------8<----------8<----------
Be default, lshd doesn't allow root login. Try a different user name, or run lshd --root-login.
/Niels
On Sun, Oct 06, 2002 at 08:20:57PM +0200, Niels Möller wrote:
Be default, lshd doesn't allow root login. Try a different user name, or run lshd --root-login.
I tried that but it doesn't work. I have a second user on the machine which has no password (login via telnet does work), and I also cannot login via lsh to his account.
It also doesn't matter if I use the openssh or the lsh client. With the lsh client I get this on the server side when I try to login to the account without a password:
lshd: Disconnect for reason 14: No more auth methods available
Even changing to a "real" password does not help... coud this be caused due to wrongly set permissions of some of the configuration files?
Robert
Robert Schwebel robert@schwebel.de writes:
I tried that but it doesn't work. I have a second user on the machine which has no password (login via telnet does work), and I also cannot login via lsh to his account.
lshd is a little paranoid, and it doesn't allow logins to accounts with no passwd-field in the paswd database (an empty password, as generated by crypt("salt", ""), should work, though). See the comment before the do_lookup_user function in unix_user.c for the rules lshd use when reading the user database.
It also doesn't matter if I use the openssh or the lsh client.
That makes sense, as it's a server configuration/policy issue.
Even changing to a "real" password does not help... coud this be caused due to wrongly set permissions of some of the configuration files?
An ordinary user with a real password is the normal case, and that should certainly work. How is your system set up? Do you have a plain /etc/passwd file with encrypted passwords in, or do you use shadow passwords? Is PAM involved in any way?
/Niels
On Sun, Oct 06, 2002 at 10:30:50PM +0200, Niels Möller wrote:
lshd is a little paranoid, and it doesn't allow logins to accounts with no passwd-field in the paswd database (an empty password, as generated by crypt("salt", ""), should work, though). See the comment before the do_lookup_user function in unix_user.c for the rules lshd use when reading the user database.
Ok, empty passwords was just for testing, long term I would be satisfied if it worked at all :^)
An ordinary user with a real password is the normal case, and that should certainly work. How is your system set up? Do you have a plain /etc/passwd file with encrypted passwords in, or do you use shadow passwords? Is PAM involved in any way?
It's a self made system, so it could easily be that I forgot something. Shadow is used, PAM not. Here are the relevant files:
/etc/passwd: root:x:0:0:root:/:/bin/sh custom:x:500:100:Rayonic Custom User:/home:/bin/sh
/etc/shadow: root:SPoFKYqe5xgJc:0:0:99999:7::: custom:zu.hbJ3nhIfqk:0:0:99999:7:::
/etc # ls -l passwd shadow -rw-r--r-- 1 root root 77 Oct 5 2002 passwd -rw-r----- 1 root root 70 Jan 1 00:01 shadow
Shouldn't that be correct? What else do I need?
Robert
Robert Schwebel robert@schwebel.de writes:
It's a self made system, so it could easily be that I forgot something. Shadow is used, PAM not. Here are the relevant files:
They look reasonable to me.
/etc # ls -l passwd shadow -rw-r--r-- 1 root root 77 Oct 5 2002 passwd -rw-r----- 1 root root 70 Jan 1 00:01 shadow
Shouldn't that be correct? What else do I need?
Then you *must* run lshd as root, or it won't be able to read the shadow information.
If it isn't that particular (but common) mistake, I think you need to bring out the debugger. Attach gdb to the running lshd process (preferably when logged in on the console, or in some other manner that doesn't depend on lshd running ;-). Put a break point on unix_user.c:do_lookup_user, step through a login attempt, and watch what happens.
/Niels
Hi Niels,
I just had some time to investigate the problem a little bit further. It seems that lshd tries to open a pty, an strace contains this:
----------8<---------- [...] select(7, [5 6], [6], [], {5368, 119868}) = 2 (in [6], out [6], left {5368, 120000}) read(6, "S\225\360\t/V\v\0325\362hd\351\2\324\223\343\214p>\230"..., 16384) = 368 open("/dev/ptya0", O_RDWR|O_NOCTTY) = -1 ENOENT (No such file or directory) open("/dev/ptya1", O_RDWR|O_NOCTTY) = -1 ENOENT (No such file or directory) open("/dev/ptya2", O_RDWR|O_NOCTTY) = -1 ENOENT (No such file or directory) open("/dev/ptya3", O_RDWR|O_NOCTTY) = -1 ENOENT (No such file or directory) open("/dev/ptya4", O_RDWR|O_NOCTTY) = -1 ENOENT (No such file or directory) open("/dev/ptya5", O_RDWR|O_NOCTTY) = -1 ENOENT (No such file or directory) [...] ----------8<----------
The system is based on devfs which has the ptys in /dev/pty/; The device nodes itself are called m0..m99.
I also see this:
----------8<---------- fork() = 83 close(7lshd: unix_user: exec failed (errno = 2): No such file or directory ) = 0 --- SIGCHLD (Child exited) --- ----------8<----------
Which device nodes does lsh expect? Can I simply link the existing ones to the correct paths, and if yes, which ones are the equivalents to the /dev/ptyxx and /dev/ttyxx entries?
Robert
Robert Schwebel robert@schwebel.de writes:
I just had some time to investigate the problem a little bit further. It seems that lshd tries to open a pty, an strace contains this:
...
open("/dev/ptya0", O_RDWR|O_NOCTTY) = -1 ENOENT (No such file or directory) open("/dev/ptya1", O_RDWR|O_NOCTTY) = -1 ENOENT (No such file or directory) open("/dev/ptya2", O_RDWR|O_NOCTTY) = -1 ENOENT (No such file or directory)
The system is based on devfs which has the ptys in /dev/pty/; The device nodes itself are called m0..m99.
Do you have a /dev/ptmx, or is there anyway you can configure your system to support UNIX98-style ptys? Then HAVE_UNIX98_PTYS should be defined in your config.h, and the code looping over pty names should never run.
Which device nodes does lsh expect? Can I simply link the existing ones to the correct paths, and if yes, which ones are the equivalents to the /dev/ptyxx and /dev/ttyxx entries?
lshd only looks for pty:s with two characters after the "/dev/pty" or "/dev/tty". Which characters are used is determined by PTY_BSD_SCHEME_FIRST_CHARS and PTY_BSD_SCHEME_SECOND_CHARS. Look what values you have in config.h, and see if there's any way the corresponding configure tests can be improved. It uses things like
ls /dev/pty* | cut -c 10-10 | sort | uniq | tr -d '\n'
to figure out what to use.
----------8<---------- fork() = 83 close(7lshd: unix_user: exec failed (errno = 2): No such file or directory ) = 0 --- SIGCHLD (Child exited) --- ----------8<----------
lshd execs user processes via the helper program $prefix/sbin/lsh-execuv. Do you have that installed?
Regards, /Niels