Are there tutorials for setting up dropbear on boot?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Ok just to clarify. You can use dropbear on the machine only for use with the initrd. Once the machine boots, you can ignore the fact that dropbear is there. (I use different keys for dropbear and openssh, configuring a different port for the dropbear started from the initrd so I don't have conflicts in ~/.ssh/known_hosts on the client side)
Regarding:
Quote:
to try and connect but I get
Code:
Connection to root@192.168.1.30:22 exited: Connect failed: No route to host
I would start by checking your /etc/early-ssh/early-ssh.conf and making sure everything is correct. Also note the port number you configure there. My example above used a non-standard port. Does your network adapter need a kernel module? Make sure it's included in your initrd then.
If you need DHCP or something, you are unfortunately on your own. You'd have to change /usr/share/mkinitrd/scripts/early_ssh do the stuff you need. The setup I have described is for a static IP.
You said you went to the machine and typed in the password. I don't think this should be the case. It should be waiting in a loop for the server to be killed and then the init script will continue. So it seems either the early_ssh script is not included or if it is, something in it is failing.
If you look in your /tmp/initrd-whatever file tree, do you see early_ssh in the top-level directory, dropbear in sbin and etc/early-ssh/early-ssh.conf? Is /early_ssh line in your init file?
I guess as a final test, you could type in the password incorrectly until it drops you into a shell, then try to run /early_ssh yourself. Maybe then you can see an error message.
Ok just to clarify. You can use dropbear on the machine only for use with the initrd. Once the machine boots, you can ignore the fact that dropbear is there. (I use different keys for dropbear and openssh, configuring a different port for the dropbear started from the initrd so I don't have conflicts in ~/.ssh/known_hosts on the client side)
Regarding:
I would start by checking your /etc/early-ssh/early-ssh.conf and making sure everything is correct. Also note the port number you configure there. My example above used a non-standard port. Does your network adapter need a kernel module? Make sure it's included in your initrd then.
If you need DHCP or something, you are unfortunately on your own. You'd have to change /usr/share/mkinitrd/scripts/early_ssh do the stuff you need. The setup I have described is for a static IP.
You said you went to the machine and typed in the password. I don't think this should be the case. It should be waiting in a loop for the server to be killed and then the init script will continue. So it seems either the early_ssh script is not included or if it is, something in it is failing.
If you look in your /tmp/initrd-whatever file tree, do you see early_ssh in the top-level directory, dropbear in sbin and etc/early-ssh/early-ssh.conf? Is /early_ssh line in your init file?
I guess as a final test, you could type in the password incorrectly until it drops you into a shell, then try to run /early_ssh yourself. Maybe then you can see an error message.
Let us know if you come right.
For the kernel modules, I have all of the required kernel modules as I used that command Slackware has in the beginners_guide to figure out what modules are needed (my keyboard would not work previously) and added those into your commands.
and reboot my machine I would end up getting an error where Slackware not finding cryptroot I had to change /dev/mapper/cryptroot to just cryptroot and it worked.
I also discovered I had placed the DESTDIR= into luksdev instead of just running the command. So I fixed re-did everything and made sure to run that comamnd instead of placing it in luksdev.
Code:
DISABLED=1
INTERFACE="eth0"
IP="192.168.1.30"
PORT="22"
NETMASK="255.255.255.0"
GATEWAY="192.168.1.1"
TIMEOUT="300" # in seconds (empty means disabled, will wait forever)
Should DISABLED=1 be set to 0 instead? I think it should be 0, I will try it with disabled=0. I have also changed OpenSSH's port to another port so that there is no conflict. I am using the same static ip that the computer is set to use when the Slackware network interfaces start (should they be different?).
EDIT: I have tried with DISABLED=0 and DISABLED=1 (I re-made the entire /tmp/initrd thing with the mkinitrd command each time) and I still can not connect on boot using dropbear. If I check the monitor it is asking for my password and there is no loop that you mention. I am missing something but can't figure out what.
If I look in /tmp/initrd-tree-4.4.132 I see a green early-ssh file and in sbin I see a green dropbear file and there is /tmp/initrd-tree-4.4.132/etc/early-ssh/early-ssh.conf as well. My init file has a /early_ssh text right above "if [ -x /sbin/cryptsetup ]; then" like so
Decided to make a separate post. I am trying your final test, basically turning on the machine and when I get promtped for a password I just hit enter until I got an error that basically said
Code:
Device /dev/mapper/cryptroot not found
mount: mounting /dev/mapper/cryptroot on /mnt failed: No such file or directory
ERROR: No /sbin/init found on rootdev (or not mounted). Trouble ahead.
You can try to fix it. Type ´exit´ when things are done.
and then I got dropped to a shell. Is that normal behavior from entering the password wrong too many times?
Anyway, the OS basically has this on the screen now after the previous code I pasted
Code:
/bin/sh: can't access tty: job control turned off
/#
and then I can enter things into the shell. I try looking for early-ssh but can't find anything, I tried typing /early-ssh it said not found and I ran a "find -name "early-ssh" and alternatively early_ssh and it could not find anything either. So this means early-ssh is not being included for some reason?
So, I forgot to edit LILO and set it to use /boot/initrd-4.4.132.gz instead of just the default /boot/initrd.gz . Upon doing so, I rebooted the machine and I see how it is sort of waiting in a loop for a connection so it seems to be going okay. The issue however is that I can not connect.
Basically what comes up,
Code:
*** early-ssh 0.3.7-testing ***
Network interface : eth0
IP address: 192.168.1.30
Subnet mask: 255.255.255.0
Default gateway: 192.168.1.1
SSH port: 22
ifconfig: SIOCSIFADDR: No such device
route: SIOCADDRT: Network is unreachable
*** Now you can log in over SSH. You can press enter or wait 300 seconds to continue booting
So the issue now seems to be related to my network setup (which seems fine) or that I am missing network drivers? I ran that special command "/usr/share/mkinitrd/mkinitrd_command_generator.sh" to figure out what type of modules I needed and incorporated that into the mkinitrd command you instructed to execute and I know it is working because previously my wireless keyboard would not work but it does which means the modules are loaded. Any ideas?
EDIT: Okay so for some reason, mkinitrd did not include my network chipset/driver so I had to manually run
Code:
ls -l /sys/class/net/eth0/device/driver
in which my driver was posted on the output as r8169 or something. I had to manually add r8169 to the modules section of the mkinitrd and I was able to connect to the machine during boot and unlock the drive with
Code:
cryptsetup luksOpen /dev/sda1 cryptroot
entered my password and typed finish, however the system was not able to boot and I got this error message
Code:
Device /dev/mapper/cryptroot not found
mount: mounting cryptroot on /mnt failed: No such file or directory
ERROR: No /sbin/init found on rootdev (or not mounted). Trouble ahead.
You can try to fix it. Type ´exit´ when things are done.
Going to try a few things but I think I may need some help, what is the proper way to "unlock" the partition?
Ok just to clarify. You can use dropbear on the machine only for use with the initrd. Once the machine boots, you can ignore the fact that dropbear is there. (I use different keys for dropbear and openssh, configuring a different port for the dropbear started from the initrd so I don't have conflicts in ~/.ssh/known_hosts on the client side)
Regarding:
I would start by checking your /etc/early-ssh/early-ssh.conf and making sure everything is correct. Also note the port number you configure there. My example above used a non-standard port. Does your network adapter need a kernel module? Make sure it's included in your initrd then.
If you need DHCP or something, you are unfortunately on your own. You'd have to change /usr/share/mkinitrd/scripts/early_ssh do the stuff you need. The setup I have described is for a static IP.
You said you went to the machine and typed in the password. I don't think this should be the case. It should be waiting in a loop for the server to be killed and then the init script will continue. So it seems either the early_ssh script is not included or if it is, something in it is failing.
If you look in your /tmp/initrd-whatever file tree, do you see early_ssh in the top-level directory, dropbear in sbin and etc/early-ssh/early-ssh.conf? Is /early_ssh line in your init file?
I guess as a final test, you could type in the password incorrectly until it drops you into a shell, then try to run /early_ssh yourself. Maybe then you can see an error message.
Let us know if you come right.
Okay, I successfully figured out how to be able to boot slackware from the dropbear ssh instance but I have a few questions.
When connecting into the dropbear ssh server I had to first unlock the partition,
Code:
cryptsetup luksOpen /dev/sda1 cryptroot
then I also had to mount /dev/mapper/cryptroot on /mnt (if I try to mount it on / I get an error, and I read through the init file and it mounts it on /mnt for some reason).
Code:
mount /dev/mapper/cryptroot /mnt
The slackware system successfully boots however I see there is a message saying
Code:
ERROR: Root partition has already been mounted read-write. Cannot check!
For filesystem checking to work properly , your system must initially mount the root partition as read only. If you're booting with LILO add a line read-only
That line is already added on my LILO.
I fixed this issue by mounting as read only instead of the first way I did it
Code:
mount -o ro /dev/mapper/cryptroot /mnt
That seemed to fix the issue above. My question now is, why do I have to manually mount the partition? When I had the system set up from following README_CRYPT (before we started making the other initrd's with dropbear/early-ssh support) Slackware would prompt me to enter a password to unlock the partition upon boot and then mount it for me. Is there a way to grab that code and copy it into this init so that when I connect to dropbear I can just run a command or something?
Is there a way to grab that code and copy it into this init so that when I connect to dropbear I can just run a command or something?
/usr/share/mkinitrd/initrd-tree.tar.gz contains the normal initrd tree. There's a file in there called ./init. It's a script which contains the init code normally run by an initrd.
/usr/share/mkinitrd/initrd-tree.tar.gz contains the normal initrd tree. There's a file in there called ./init. It's a script which contains the init code normally run by an initrd.
Ohh, yes it is there. Okay so that means (and I confirmed) the init scripts are identical, except in the instructions by caffe I have a ./ealry_ssh above an if statement line. Maybe early_ssh interrupts this procedure and this is the only/best way to do it? I was hoping to just have to type a single command do the unlock and mounting for me but alas.
Well, that script contains a lot of other stuff as well.
(As you probably know, running mkinitrd will also dump a copy of everything that will end up in your initrd in /boot/initrd-tree. That's where I normally go to look at the script.)
There's a level of complexity since the standard init script attempts to support people who want to just encrypt a subset of their partitions which may or may not be on raid devices and/or LVM logical volumes.
Ideally, you'd hook into the bit where the system does...
Ohh, yes it is there. Okay so that means (and I confirmed) the init scripts are identical, except in the instructions by caffe I have a ./ealry_ssh above an if statement line. Maybe early_ssh interrupts this procedure and this is the only/best way to do it? I was hoping to just have to type a single command do the unlock and mounting for me but alas.
You should not have to mount the device. init will do it for you if you give mkinitrd the correct parameter. (reading init as Richard Cranium says should be informative. It's quite easy to understand). Anyway, the root device you pass to mkinitrd is written into a file rootdev which is included in the initrd. init looks in this file for the device to mount (yes, it will mount it readonly to /mnt). You should therefore pass in the correct device and it will do the mounting for you. Now you wrote above that you used
Quote:
-r /dev/mapper/cryptroot
and that it fails. But you wrote that when you manually mounted, you used this device. This doesn't seem correct. To be absolutely sure, you could use the uuid of the unlocked partition (you can print them with blkid) in your initrd command:
Quote:
-r /dev/disk/by-uuid/<uuid>
As for using a script to unlock, you should now understand you can add whatever you want to the initrd. So we've proven we don't need to manually mount, but you could script the other.
So in the stage after you've added dropbear to the init but before you've zipped everything back up, just add a script to do the unlocking.
You should not have to mount the device. init will do it for you if you give mkinitrd the correct parameter. (reading init as Richard Cranium says should be informative. It's quite easy to understand). Anyway, the root device you pass to mkinitrd is written into a file rootdev which is included in the initrd. init looks in this file for the device to mount (yes, it will mount it readonly to /mnt). You should therefore pass in the correct device and it will do the mounting for you. Now you wrote above that you used
and that it fails. But you wrote that when you manually mounted, you used this device. This doesn't seem correct. To be absolutely sure, you could use the uuid of the unlocked partition (you can print them with blkid) in your initrd command:
As for using a script to unlock, you should now understand you can add whatever you want to the initrd. So we've proven we don't need to manually mount, but you could script the other.
So in the stage after you've added dropbear to the init but before you've zipped everything back up, just add a script to do the unlocking.
then the command previously used to build the initrd.
Then after you ssh in, just type
Code:
unlock
and it will prompt for the password and disconnect you. You could add any additional commands to this you need.
Quote:
Now you wrote above that you used
Quote:
-r /dev/mapper/cryptroot
and that it fails. But you wrote that when you manually mounted, you used this device. This doesn't seem correct.
=================================================================================
I figured out why this failed. As I initially was following README_CRYPT.TXT from Slackware repo the mkinitrd command it uses is like so
notice how it does not have /dev/mapper/cryptroot. So I basically adapted your first mkinitrd to the one I already had (my mistake) and that is why when I ran the second/final mkinitrd I got an error.
I started from scratch using /dev/mapper/cryptroot in both mkinitrd commands you listed ( I still manually added in the -L option to the first mkinitrd as I am almost certain I will get a boot error if I don't) and the system booted up successfully with no error and launched the early-ssh/dropbear instance. I was able to connect to the dropbear instance, write the command
Code:
cryptsetup luksOpen /dev/sda1 cryptroot
and then hit
Code:
finished
and the slackware system started to boot on its own.
I did not get to try out the custom script but that looks like a very nice addition if I encrypt swap or other drives. I will definitely be trying that out looks very neat!
EDIT: To further add to the discussion, I went back and tried to modify the mkinitrd command from Slackware README_CRYPT.txt to replace cryptroot with /dev/mapper/cryptroot
So, this means that when following standard Slackware procedure I HAVE to use 'cryptroot' and can not use '/dev/mapper/cryptroot' AND I also have to add -L . However, for your instructions I don't necessarily have to use '/dev/mapper/cryptroot' but if I do not I have to manually mount the drive when connecting to dropbear.I am writing this mostly for myself but also for others as they may get confused why it differs so much.
Haaha just tried this out its amazing! Furthermore, using /dev/disk/by-uuid/<uuid> will future proof it if I remove drives (especially if I enable encrypted swap as that gets formatted every boot and shutdown) or for people who have a hotswap setup. Amazing stuff here, thanks for sharing.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.