Skip to content
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

Question about the ssh parameters #104

Open
thomas-mc-work opened this issue Dec 14, 2017 · 5 comments · May be fixed by #128
Open

Question about the ssh parameters #104

thomas-mc-work opened this issue Dec 14, 2017 · 5 comments · May be fixed by #128

Comments

@thomas-mc-work
Copy link
Contributor

Why is this part of the ssh command:

… -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null'

Wouldn't it be better to let the user configure this in it's ssh_config instead of generally using it and thus weaken the security?

From the man page man ssh_config:

CheckHostIP
If this flag is set to “yes”, ssh(1) will additionally check the
host IP address in the known_hosts file.

and

UserKnownHostsFile
Specifies one or more files to use for the user host key data‐
base, separated by whitespace.

@thomas-mc-work thomas-mc-work changed the title Question to the ssh parameters Question about the ssh parameters Dec 14, 2017
@laurent22
Copy link
Owner

I guess that could indeed be optional although I'm not really familiar with these parameters. @fustundag, do you remember why it was implemented this way?

@fustundag
Copy link
Collaborator

fustundag commented Dec 14, 2017

@laurent22 If host key changed ( not public/private key, ssh access is stili valid) backup cloud be failed. I choose this option to prevent this fail.

We can change to decide user this ssh config.

@Loki3000
Copy link
Contributor

Loki3000 commented Apr 6, 2018

Also it's becomes permanent warning:

Warning: Permanently added 'domain' (ECDSA) to the list of known hosts.

that falls to stdout.

@thomas-mc-work
Copy link
Contributor Author

thomas-mc-work commented Apr 6, 2018

The scenario is: Every host has a pubplic/private key pair which allows you to identify it distinctly. The keys are stored in your ~/.ssh/known_hosts file once confirmed. From this time every connection attempts is being compared to the stored key and thus checked whether the remote keys has changed. This shall indicate that something unwanted has happened to your remote machine – aiming to detect a sever breach.

Having this option included by default prevents the host validation check done by the SSH client and thus undermines an important security feature. I think it would be better to remove it and let each user decide to opt in if required (by using --rsync-set-flags).

@Loki3000

Also it's becomes permanent warning:

This should only happen if you only have the second part enabled (-o UserKnownHostsFile=/dev/null). This leads to discarding all discovered keys and thus trying to add it again on every new connection.

@Loki3000
Copy link
Contributor

Loki3000 commented Apr 6, 2018

This should only happen if you only have the second part enabled

I know. But it's enabled by default. And there is no way to disable it without code modification.

thomas-mc-work added a commit to thomas-mc-work/rsync-time-backup that referenced this issue Jul 24, 2018
… by removing the hard coded SSH option to bypass `StrictHostKeyChecking` and the `UserKnownHostsFile`.

Closes laurent22#104
@thomas-mc-work thomas-mc-work linked a pull request Jul 24, 2018 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants