Closed joaohf closed 2 years ago
Hmm, there is an issue, but I do not yet see how it could overwrite stuff: kas-container mounts ssh-dir read-only?!
But one thing that could be broken is non-container execution: SetupSSHAgent() is added to setup_commands BEFORE SetupHome. So, SetupSSHAgent will indeed touch the real .ssh/config instead of the temporary one after creating the kas build home. There we may need some reordering.
In fact one might also need UserKnownHostsFile /dev/null
in addition to StrictHostKeyChecking no
but that is another story
@jan-kiszka I see your point and order that you said make sense to me. I just want to share some debug that I've ran.
I use to run the following command:
~/opensource/kas/kas-container -d --ssh-dir ssh --runtime-args "-v ${SSH_AUTH_SOCK}:${SSH_AUTH_SOCK}:ro -e SSH_AUTH_SOCK -e SSH_PRIVATE_KEY_FILE=/builder/.ssh/id_rsa" shell my.yml
So, my local ssh folder has these files: config, id_rsa and known_hosts. They are mapped correctly into /home/joao.freitas/m/yocto/ssh:/etc/skel/.ssh:ro
as read-only. That is fine.
Just a snipet when running kas-container with -d flag:
docker run -v /home/joao.freitas/m/yocto:/repo:rw -v /home/joao.freitas/m/yocto:/work:rw -e KAS_WORK_DIR=/work -v /home/joao.freitas/m/yocto/build:/build:rw --workdir=/repo -e KAS_BUILD_DIR=/build -e USER_ID=1000 -e GROUP_ID=1000 --rm -v /home/joao.freitas/m/yocto/ssh:/etc/skel/.ssh:ro -t -i -e TERM=screen-256color -e SHELL=/bin/bash -v /home/joao.freitas/.byobu/.ssh-agent:/home/joao.freitas/.byobu/.ssh-agent:ro -e SSH_AUTH_SOCK -e SSH_PRIVATE_KEY_FILE=/builder/.ssh/id_rsa kas-local -d shell /repo/my.yml
Inside kas-container and checking /builder/.ssh/config, is like that:
builder@e0e7adc582d5:/build$ cat /builder/.ssh/config
Host *
StrictHostKeyChecking no
However, the files /builder/.ssh/id_rsa and /builder/.ssh/known_hosts are what I'm expecting. Just the config one is not.
Also, files inside the /etc/skel/.ssh/ looks what I mapped.
And checking the temporary HOME (mapped to /tmp/tmpmn0dh2l9) does not have any .ssh file. Is suppose to have any .ssh folder there ?
I think, when running kas-container, the container-entrypoint
creates a user with useradd
command. Because of that
the skel content is copied to /builder/.ssh. After that kas
overwrite the /builder/.ssh/config (not the /etc/skel/.ssh, which is read-only).
I also tried to add SetupHome() call before SetupSSHAgent() like that
diff --git a/kas/libcmds.py b/kas/libcmds.py
index 35668fc..8d33e5f 100644
--- a/kas/libcmds.py
+++ b/kas/libcmds.py
@@ -48,6 +48,7 @@ class Macro:
self.setup_commands = [
SetupDir(),
+ SetupHome(),
]
if ('SSH_PRIVATE_KEY' in os.environ
@@ -55,7 +56,6 @@ class Macro:
self.setup_commands.append(SetupSSHAgent())
self.setup_commands += [
- SetupHome(),
InitSetupRepos(),
repo_loop,
FinishSetupRepos(),
But I got the same results.
You are mixing up --ssh-dir
and ad-hoc ssh configuration, triggered by setting SSH_PRIVATE_KEY_FILE
. That is no reasonable combination. Just using --ssh-dir
should work fine, and just passing SSH_PRIVATE_KEY_FILE
should do so as well. Could you verify that first?
Alright. Now it works as expected.
~/opensource/kas/kas-container -d --ssh-dir ssh shell ky.yml
And the ssh-dir has the config file mapped correctly:
Host host.com
Hostname host.com
User joao.freitas
IdentityFile /builder/.ssh/id_rsa
Host *
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
Thanks and sorry for the confusion.
No need to be sorry! Revealed a sleeping issue, if not more.
Did the pure SSH_PRIVATE_KEY_FILE
path work for you as well?
Well, with SSH_PRIVATE_KEY_FILE, I got unexpected results:
~/opensource/kas/kas-container --ssh-dir ssh --runtime-args "-e SSH_PRIVATE_KEY_FILE=/builder/.ssh/id_rsa" shell my.yml
Inside the container:
cat /builder/.ssh/config
Host *
StrictHostKeyChecking no
However, the /builder/.ssh/id_rsa
is ok.
Yeah, a lot of assumption of kas in this code path seem broken. E.g., I just found out that ssh is not reading from $HOME/.ssh but picks up the home directory from /etc/passwd. So the attempt to build a temporary home, also for .ssh, fails.
With e3af001f53252e05cbaf7e6057ba13d96a4b6385, I think we can close this. For the next major release, we need to look into isolating ssh by passing a custom config file.
Without this change the user configuration is overide by ssh_no_host_key_check() function.
The main use case is for kas-container and --ssh-dir parameter.