-
Notifications
You must be signed in to change notification settings - Fork 28
Allow root ssh login #168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow root ssh login #168
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry but I see 2 important issues with this:
- I suspect this completely overwrites the existing config file. It should at least append to it
- I just checked and port 10022 is currently NOT bound to "localhost", it's open to the entire network instead. This should be fixed anyway but combining it with this change would really bring the insecurity too far.
By default, run_qemu.sh
tries hard to install all the ssh keys it can find. Can you please try to get ssh keys working instead? Once it's working it's much faster and more convenient than a password.
If your build system and QEMU host is different from your workstation, simply copy your public key from your workstation to your build system, then create an empty file on your build system with the same name as your private key. This is enough to install the public key in the QEMU guest.
ssh's ProxyJump
can also be useful.
@marc-hb I'll drop this PR. |
@marc-hb I just cofirmed that I could login as root (via ssh rq) on to the VM backed by the root.img created by run_qemu.sh. I am wondering though, I don't see the prompt on the console
Is this an intended behaivour by the current shell implementation of run_qemu.sh? This is how I invoke the script:
I'm on origin/main branch and run_qemu.sh is not modified.
|
In the window where you run run_qemu.sh, the prompt is frequently overwritten by kernel logs. Press "enter" multiple times and it should re-appear (unless kernel logs are verbose and overwrite it again) I think most people use Is that what you were referring to? |
didn't help for me.
Yes. I am fine with it. |
You seem to have problems with the
Please try this (from ssh) tty
ps faux | grep -C 5 'tty|login'
systemctl --failed
systemctl | grep tty
systemctl status <services you found in the previous command> |
|
|
Thanks! and now these:
|
|
|
|
I think you have a "hardware" problem with /dev/ttyAMA0; simple as that. Maybe Maybe @jic23 can help? EDIT: great context https://0pointer.de/blog/projects/serial-console.html |
@marc-hb I wasn't setting correctly console=ttyAMA0 (via the run_qemu.sh's |
mkosi versions v15 and above need a lot more explicit Packages= like "?priority(important)" and "task ssh-server". mkosi v15 changed everything, see systemd/mkosi#1971 Missing packages caused a lot of issues like pmem#168, pmem#171, pmem#199 and maybe others. Signed-off-by: Marc Herbert <[email protected]>
mkosi versions v15 and above need a lot more explicit Packages= like "?priority(important)" and "task ssh-server". mkosi v15 changed everything, see systemd/mkosi#1971 Missing packages caused a lot of issues like #168, #171, #199 and maybe others. Signed-off-by: Marc Herbert <[email protected]>
Awesome!
The file Did you have local changes to
Do you mean changing the run_qemu.sh script itself? This does not look configurable yet. The main purpose of |
Possible, I will check after pulling
At the start of the run_qemu.sh script, I did:
but ...
You were correct.
I will compare my local mkosi.debian file against |
Thank you!
Please submit changes to the debian config files; these are very quick to review and merge. |
No description provided.