Push to repo fails due to unknown remote ssh hostkey
Error is:
Hook push_to_remote (#<GithubRepo:0x00000000022ebad8>) failed (#<Rugged::SshError: invalid or unknown remote ssh hostkey>) for event :post_store
ssh git@host works as key was added to repo
Rugged was installed with ssh then oxidized reinstalled.
3.0.0 :002 > Rugged.features => [:threads, :https, :ssh]
No idea what to pursue
Local gems:
*** LOCAL GEMS ***
abbrev (default: 0.1.0) asetus (0.4.0) backports (3.25.0) base64 (default: 0.1.0) bcrypt_pbkdf (1.1.0) benchmark (default: 0.1.1) bigdecimal (default: 3.0.0) bundler (default: 2.2.3) bundler-unload (1.0.2) cgi (default: 0.2.0) charlock_holmes (0.7.7) csv (default: 3.1.9) date (default: 3.1.0) dbm (default: 1.1.0) debug (default: 0.1.0) delegate (default: 0.2.0) did_you_mean (default: 1.5.0) digest (default: 3.0.0) drb (default: 2.0.4) ed25519 (1.3.0) emk-sinatra-url-for (0.2.1) english (default: 0.7.1) erb (default: 2.2.0) etc (default: 1.2.0) executable-hooks (1.7.1) fcntl (default: 1.0.0) ffi (1.16.3) fiddle (default: 1.0.6) fileutils (default: 1.5.0) find (default: 0.1.0) forwardable (default: 1.3.2) gdbm (default: 2.1.0) gem-wrappers (1.4.0) getoptlong (default: 0.1.1) haml (5.2.2) htmlentities (4.3.4) io-console (default: 0.5.6) io-nonblock (default: 0.1.0) io-wait (default: 0.1.0) ipaddr (default: 1.2.2) irb (default: 1.3.0) json (default: 2.5.1) logger (default: 1.4.3) matrix (default: 0.3.1) minitest (5.14.2) multi_json (1.15.0) mutex_m (default: 0.1.1) net-ftp (0.3.4, default: 0.1.1) net-http (default: 0.1.1) net-imap (default: 0.1.1) net-pop (default: 0.1.1) net-protocol (default: 0.1.0) net-scp (4.0.0) net-smtp (default: 0.2.1) net-ssh (7.2.3) net-telnet (0.2.0) nkf (default: 0.1.0) observer (default: 0.1.1) open-uri (default: 0.1.0) open3 (default: 0.1.1) openssl (default: 2.2.0) optparse (default: 0.1.0) ostruct (default: 0.3.1) oxidized (0.30.1) oxidized-web (0.13.1) pathname (default: 0.1.0) power_assert (1.2.0) pp (default: 0.1.0) prettyprint (default: 0.1.0) prime (default: 0.1.2) pstore (default: 0.1.1) psych (3.3.4, default: 3.3.0) puma (3.11.4) racc (default: 1.5.1) rack (1.6.13) rack-protection (1.5.5) rack-test (0.7.0) rake (13.0.3) rb-fsevent (0.11.2) rb-inotify (0.10.1) rbs (1.0.0) rdoc (default: 6.3.0) readline (default: 0.0.2) readline-ext (default: 0.1.1) reline (default: 0.2.0) resolv (default: 0.2.0) resolv-replace (default: 0.1.0) rexml (3.2.4) rinda (default: 0.1.0) rss (0.2.9) rubygems-bundler (1.4.5) rugged (1.7.2) rvm (1.11.3.9) sass (3.7.4) sass-listen (4.0.0) securerandom (default: 0.1.0) set (default: 1.0.1) shellwords (default: 0.1.0) sinatra (1.4.8) sinatra-contrib (1.4.7) singleton (default: 0.1.1) slop (4.10.1) stringio (default: 3.0.0) strscan (default: 3.0.0) syslog (default: 0.1.0) tempfile (default: 0.1.1) temple (0.10.3) test-unit (3.3.7) tilt (2.4.0, 2.3.0) time (default: 0.1.0) timeout (default: 0.1.1) tmpdir (default: 0.1.1) tracer (default: 0.1.1) tsort (default: 0.1.0) typeprof (0.11.0) un (default: 0.1.0) uri (default: 0.10.1) weakref (default: 0.1.1) yaml (default: 0.1.1) zlib (default: 1.1.0)
Did you try https://github.com/ytti/oxidized/blob/master/docs/Troubleshooting.md#oxidized-does-not-push-to-a-remote-git-repository-hook-githubrepo ?
Did you try https://github.com/ytti/oxidized/blob/master/docs/Troubleshooting.md#oxidized-does-not-push-to-a-remote-git-repository-hook-githubrepo ?
I did try the ssh-keyscan though the key was already added. No effect seen
It could help me to identify if i had some sample code i could run that pushes the repo. Unfortunately i dont have the skill to generate one by seeing the oxidized hook code.
I have exactly the same issue
This issue is stale because it has been open 90 days with no activity.
same issue here. I've added the ssh public host keys to the known_hosts file and mapped it into docker container. I still get following error?
Hook push_to_remote (#<GithubRepo:0x00007f17a1aac458>) failed (#<Rugged::SshError: invalid or unknown remote ssh hostkey>) for event :post_store
Any news about this issue?
I've changed the push_to_remote in oxidized config to https and changed the default branch in git config. Default Branch is set to master by default. Created an Repository Access Token and used the name as username and the token as password value in oxidized config.
Sorry for updating an old issue but I faced this problem today and managed to solve it.
In my setup Oxidized was not able to connect to git, because of file permissions and ownership of content in ~/.ssh -folder.
I run Kubernetes.. if anyone faces this problem, the init-container in my config fixed my problem.
Hope it helps someone.
apiVersion: apps/v1
kind: Deployment
metadata:
name: oxidized
namespace: monitoring
spec:
replicas: 1
selector:
matchLabels:
app: oxidized
template:
metadata:
labels:
app: oxidized
spec:
initContainers:
- name: init-known-hosts
image: alpine
command: ["/bin/sh", "-c"]
args:
- |
apk add --no-cache openssh && \
mkdir -p /ssh && \
ssh-keyscan gitlab.sparklet.com > /ssh/known_hosts && \
chmod 600 /ssh/known_hosts
chown -R 30000:30000 /ssh
volumeMounts:
- name: ssh-dir
mountPath: /ssh
- name: init-copy-ssh-key
image: alpine
command: ["/bin/sh", "-c"]
args:
- |
mkdir -p /ssh && cp /key/* /ssh/ && chmod 600 /ssh/*
chown -R 30000:30000 /ssh
volumeMounts:
- name: ssh-secret
mountPath: /key
- name: ssh-dir
mountPath: /ssh
containers:
- name: oxidized
image: oxidized/oxidized:latest
ports:
- containerPort: 8888
env:
- name: CONFIG_RELOAD_INTERVAL
value: "86400"
- name: OXIDIZED_SSH_PASSPHRASE
valueFrom:
secretKeyRef:
name: oxidized-secret
key: ssh_passphrase
volumeMounts:
- name: oxidized-config-volume
mountPath: /home/oxidized/.config/oxidized/config
subPath: config
- name: ssh-dir
mountPath: /home/oxidized/.ssh
volumes:
- name: oxidized-config-volume
configMap:
name: oxidized-config
- name: ssh-secret
secret:
secretName: oxidized-ssh
- name: ssh-dir
emptyDir: {}
So far following has been done to mitigate problems with githubrepo an ssh:
- Oxidized 0.34.0 introduced an explicit warning when rugged is installed without an ssh support. (which is not the problem here)
- The documentation explicit states one must set the permission (owner) of the files for the user oxidized inside the container
Is the original problem of the issue part of an container environment or in a native linux host?
This issue is stale because it has been open 90 days with no activity.