bug#18967: Tramp disables important SSH security features

bug#18967: Tramp disables important SSH security features

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

Tramp disables SSH host key checks by setting
GlobalKnownHostsFile=/dev/null, UserKnownHostsFile=/dev/null, and
StrictHostKeyChecking=no in its default method configuration. These
settings allow attackers to intercept connections to remote hosts, sniff
passwords, and cause other mischief. I don't think we should ship an
insecure configuration.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#18967: Tramp disables important SSH security features

[Ted Zlatanov]

On Thu, 06 Nov 2014 00:47:40 +0000 Daniel Colascione <dancol@dancol.org> wrote: 

DC> Tramp disables SSH host key checks by setting
DC> GlobalKnownHostsFile=/dev/null, UserKnownHostsFile=/dev/null, and
DC> StrictHostKeyChecking=no in its default method configuration. These
DC> settings allow attackers to intercept connections to remote hosts, sniff
DC> passwords, and cause other mischief. I don't think we should ship an
DC> insecure configuration.

I think the alternatives are something like what Ansible does:
http://www.ansible.com/blog/2014/01/15/ssh-connection-upgrades-coming-in-ansible-1-5
or a SSH client library as a FFI. SSH, when called externally, has many
failure modes without those options.

Ted

bug#18967: Tramp disables important SSH security features

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

On 11/06/2014 12:05 PM, Ted Zlatanov wrote:
> On Thu, 06 Nov 2014 00:47:40 +0000 Daniel Colascione <dancol@dancol.org> wrote: 
> 
> DC> Tramp disables SSH host key checks by setting
> DC> GlobalKnownHostsFile=/dev/null, UserKnownHostsFile=/dev/null, and
> DC> StrictHostKeyChecking=no in its default method configuration. These
> DC> settings allow attackers to intercept connections to remote hosts, sniff
> DC> passwords, and cause other mischief. I don't think we should ship an
> DC> insecure configuration.
> 
> I think the alternatives are something like what Ansible does:
> http://www.ansible.com/blog/2014/01/15/ssh-connection-upgrades-coming-in-ansible-1-5
> or a SSH client library as a FFI. 

> SSH, when called externally, has many
> failure modes without those options.

So let it fail. Since when is it okay to trade diminished security for
improved reliability?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#18967: Tramp disables important SSH security features

[Ted Zlatanov]

On Thu, 06 Nov 2014 16:58:24 +0000 Daniel Colascione <dancol@dancol.org> wrote: 

DC> On 11/06/2014 12:05 PM, Ted Zlatanov wrote:
>> On Thu, 06 Nov 2014 00:47:40 +0000 Daniel Colascione <dancol@dancol.org> wrote: 
>> 
DC> Tramp disables SSH host key checks by setting
DC> GlobalKnownHostsFile=/dev/null, UserKnownHostsFile=/dev/null, and
DC> StrictHostKeyChecking=no in its default method configuration. These
DC> settings allow attackers to intercept connections to remote hosts, sniff
DC> passwords, and cause other mischief. I don't think we should ship an
DC> insecure configuration.
>> 
>> I think the alternatives are something like what Ansible does:
>> http://www.ansible.com/blog/2014/01/15/ssh-connection-upgrades-coming-in-ansible-1-5
>> or a SSH client library as a FFI. 

>> SSH, when called externally, has many failure modes without those
>> options.

DC> So let it fail.

You can discuss that with the users and the maintainers and Michael
Albinus.  I was certainly not recommending a course of action.

DC> Since when is it okay to trade diminished security for improved
DC> reliability?

Happiness comes from within?

Ted

bug#18967: Tramp disables important SSH security features

[Stefan Monnier]

> So let it fail.

Agreed.  But I think the difficulty is in making Tramp fail cleanly
(as opposed to hang, for example).


        Stefan "who has similar issues with the connection-sharing defaults"

bug#18967: Tramp disables important SSH security features

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> So let it fail.
>
> Agreed.  But I think the difficulty is in making Tramp fail cleanly
> (as opposed to hang, for example).

Indeed, and this was the reason for the current settings. I will recheck
whether we could do it differently; but do not expect results in a day
or two. There are several bug reports about Tramp I'm faced with, and
due to local restrictions my progress is slow.

>         Stefan "who has similar issues with the connection-sharing defaults"

Yes, that might be revisited as well.

Best regards, Michael.

bug#18967: Tramp disables important SSH security features

[Glenn Morris]

Hi Michael - is there any update on this issue?

bug#18967: Tramp disables important SSH security features

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> Hi Michael - is there any update on this issue?

Hi Glenn,

no update, I've stalled this issue. And I'm still undecided how to
change it w/o damaging Tramp functionality.

Best regards, Michael.

bug#18967: Tramp disables important SSH security features

[Glenn Morris]

How about

ssh -o BatchMode=yes 

?

IIUC, this causes ssh to fail with an error, instead of eg asking "Are
you sure you want to continue connecting" and waiting forever.

(But it also seems to me that it is not Tramp's job to work around
difficulties a user might be having with SSH, and that eg an occasional
hang is preferable to changing things to be less secure that SSH's
default).

bug#18967: Tramp disables important SSH security features

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> How about
>
> ssh -o BatchMode=yes 

No, Batchmode suppresses the password dialogue. Not applicable.

And looking at the code I really don't see what can be done.

Note, that GlobalKnownHostsFile, UserKnownHostsFile and
StrictHostKeyChecking are not disabled by default. They are disabled
only in case a so-called gateway is used, like
"/tunnel:proxyhost#3128|ssh:remotehost:/path/to/file". Tramp will
created a temporary httpd tunnel then, with a random port number on the
localhost, like localhost#12345.

If you connect to remotehost as above, there will be a an internal ssh
connection to localhost#12345, which is the tunnel through proxyhost. If
you connect to another.remotehost afterwards, the same internal ssh
target will be used. But remotehost and another.remotehost are
different, and so are their host keys. That's why Tramp must be
instructed to ignore the host keys in this very special case.

See also (info "(tramp) Gateway methods")

Best regards, Michael.

bug#18967: Tramp disables important SSH security features

[Glenn Morris]

Thanks for explaining the issue. It sounds to me like closing this as
wontfix would be appropriate.

bug#18967: Tramp disables important SSH security features

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

Hi Glenn,

> Thanks for explaining the issue. It sounds to me like closing this as
> wontfix would be appropriate.

Perhaps.

I have some plans for a while to obsolete tramp-gw.el. When I wrote it
back in 2007, it was the only possibility to have an own implementation
of HTTP CONNECT tunneling.

Meanwhile, putty supports HTTP CONNECT natively. And with ssh, one could
use a ProxyCommand based on "nc -X connect ...". No need for Tramp to
implement it itself anymore.

This would perform much better than my implementation in
tramp-gw.el. And this bug would disappear automatically.

So let's keep this bug as reminder. And I will see, whether I could
document these settings in the Tramp manual. There are some free days
next two weeks, isn't it the Xmas break?

Best regards, Michael.

bug#18967: Tramp disables important SSH security features

[Michael Albinus]

Version: 26.1

> I have some plans for a while to obsolete tramp-gw.el. When I wrote it
> back in 2007, it was the only possibility to have an own implementation
> of HTTP CONNECT tunneling.
>
> Meanwhile, putty supports HTTP CONNECT natively. And with ssh, one could
> use a ProxyCommand based on "nc -X connect ...". No need for Tramp to
> implement it itself anymore.
>
> This would perform much better than my implementation in
> tramp-gw.el. And this bug would disappear automatically.
>
> So let's keep this bug as reminder. And I will see, whether I could
> document these settings in the Tramp manual. There are some free days
> next two weeks, isn't it the Xmas break?

Done, closing the bug.

Best regards, Michael.