Feature request: Integrate SSH keys on Windows

[nielsengelen]

Hello all,

It would be a very nice feature if we could use SSH keys as authentication when we add Linux servers as backup repository. At the moment Linux servers use plain password authentication. It would be nice if we could just generate SSH keys and add these to the specific Linux server.

Are there any plans about this within a feature release?

[Gostev]

Hello, no plans at this time (too few requests in the past years). Why password authentication does not work for you? Thanks!

[tsightler]

In many corporate environments password based authentication is frowned on, and in many cases it is disabled by default due to corporate security policy. I've had to get several clients to get exceptions to their corporate security policy to be able to use Linux repositories. Using keys for automated logins via SSH is pretty much the universally accepted method, most CLI based interfaces support it, including things like the Cisco CLI and DataDomain CLI. I'm not saying I agree with this, as I'm not sure having passwordless keys laying around is actually safer, but it's what has evolved as the standard in most corporate environments.

[nielsengelen]

As tsightler says it's basicly about security. Password authentication works fine but it is against certain policies on certain companies therefor the request .

[dellock6]

I have too some customers with wide linux deployments and they have choosen to go for the ssh keys. From a security standpoint however, they have only moved the problem somewhere else: who manage the keystore? which admins have those keys? Do they have a filecheck on the keyfile on every server to control when it is changed?
I'm noy saying it not useful, but it's mainly done for ease of management, so you do not have to create many users on every single server. Another way I'm seeing recently is kerberos authentication against Active Directory even for linux machines, so the server is still accessible via user/password. Keys are still in place only for automated scripts and jobs, so you do not need to store credentials in the script file.

Luca.

[seiniku]

For what it's worth, this would be an awesome feature that I would welcome in my environment.

[rawtaz]

Without known keys, how can you be sure that the server Veeam is contacting is really the one that you think it is? I know the repository should be physically secured, but that might not always be the case, let's assume it isn't "100%" physically secure in this case. By the way, let's also assume that the repository's disks are encrypted, so the attacker shouldn't be able to get to the original data.

What if an attacker manages to get to the remote repository, disconnects it and instead puts his own Linux machine there, with SSH offering logins with the same account as Veeam is configured to use; Can we have a situation where Veeam happily sends the backups to this rogue repository (and the attacker thereby getting copies of the virtual machines)?

I think it depends on a few things, for example whether Veeam refuses to proceed with the backup if the remote repository isn't in the same state that it expects (e.g. has the same backup files on it already, as opposed to being empty).

Regardless, this is one type of scenario where keys would most likely be of great help to mitigate such an attack.

EDIT: On a related note, this touches on the feature request of encrypted backups..

[rawtaz]

Anyone?

To put the question another way (since we know Veeam doesn't support keys), will Veeam do any of the following?

- Refuse to continue backing up to the respository if the SSH identity of it has changed since last time it was communicated with, and instead issue a warning (because the repository might be a rogue one) (similar to how you can get a warning if you connect to a host that doesn't have the same identity as the one stored for it in your ~/.ssh/known_hosts).

- Refuse to continue backing up to the resository if the contents of it is not what Veeam expects/has on record since the last backup to it (because it is unexpected and suspicious that the contents on the repository is not the same, it could be rogue).

[foggy]

- Refuse to continue backing up to the resository if the contents of it is not what Veeam expects/has on record since the last backup to it (because it is unexpected and suspicious that the contents on the repository is not the same, it could be rogue).

If the repository is empty, in case of incremental run the job will fail due to missing VBK file, unless you have the ForceCreateMissingVBK key set to 1. This is not so in case of active full though.

[dan.weisseg]

I had another request today for SSH Keys for Linux Restores. I am at a client in Tennessee and their servers are a majority of Linux 65% Linux or more, ext3 and ext4. Their passwords change quickly and would like to use Keys for authentication.

[RMullis]

I would also welcome SSH key authentication.

Rick

[SFalk]

Same here.

[drakecooper]

For what it's worth, the lack of this feature forced me to find an alternative to Veeam for a rather large project. Passwordless SSH certificates, for better or worse, are the standard for for this kind of thing now. It's been how you do rsync over ssh for a decade or better.

[Gostev]

The good news is that you will be able to stick with Veeam for future projects, because we did add SSH key based authentication in v8. Thanks!