On 2018-03-21 11:19, David Haller wrote:

Hello,

On Wed, 21 Mar 2018, Carlos E. R. wrote:

...

...

How can I avoid the address being stored "permanently"? Or perhaps I have to purge the addresses manually?

Or perhaps, store the key for the _NAME_ and not the IP, eh?

See 'man 8 sshd' and 'man 1 ssh-keygen' (search for 'known').

I suspect the keys currently are stored as such:

==== Isengard.dyndns.example.com,192.0.2.11 ssh-rsa AAA..... Isengard.dyndns.example.com,192.0.2.23 ssh-rsa AAA..... Isengard.dyndns.example.com,192.0.2.42 ssh-rsa AAA..... ... ==== [note: 192.0.2.0/24 is for documentation[1]] ====

How about adding a line of

==== Isengard.dyndns.example.com ssh-rsa AAA..... ====

and deleting those with an IP afterwards (manually, just prune those lines, or with ssh-keygen?)... Afterall, "localhost" does not get an IP when added to known_hosts...

Interesting idea. However, the lines for this host are like this: [79.*.*.*]:portnumber ecdsa-sha2-nistp256 AAAAE2VjZH..... long encoded string. I replaced the IP with the DNS name, and logged in again, and a new line was written to the known_hosts file. It couldn't be so easy... :-( Some entries on the file are worse, totally encrypted: |1|za.../zae...=|wx9...= ecdsa-sha2-nistp256 AAAAE2.../Gr...= -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" (Minas Tirith))

On 2018-03-21 12:44, David Haller wrote:

Hello,

On Wed, 21 Mar 2018, Carlos E. R. wrote:

...

On 2018-03-21 11:19, David Haller wrote:

...

Hello,

...

...

Interesting idea.

However, the lines for this host are like this:

[79.*.*.*]:portnumber ecdsa-sha2-nistp256 AAAAE2VjZH..... long encoded string.

I replaced the IP with the DNS name, and logged in again, and a new line was written to the known_hosts file.

Have you deleted all other entries but the one with the hostname?

Yes, of course.

...

It couldn't be so easy... :-(

*meh*

...

Some entries on the file are worse, totally encrypted:

|1|za.../zae...=|wx9...= ecdsa-sha2-nistp256 AAAAE2.../Gr...=

Probably idn-hostnames... as base64 or so.

Actually: if in doubt, I'd nuke (aka rename) the file. Log into Isengard.dyndns.example.com once, delete any IP but keep the hostname from the known_hosts entry and cross fingers ;)

It created: [isengard.dyndns...]:port,[79.*.*.*]:port ecdsa-sha2-nistp256 AAAAE2... I again edited to: [isengard.dyndns...]:port ecdsa-sha2-nistp256 AAAAE2... and it created another line for the IP: [isengard.dyndns...]:port ecdsa-sha2-nistp256 AAAAE2... [79.*.*.*]:port ecdsa-sha2-nistp256 AAAAE2... but this time without asking me if I'm sure to add the key. Sigh... -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" (Minas Tirith))

On 2018-03-21 13:06, Andrei Borzenkov wrote:

On Wed, Mar 21, 2018 at 1:35 PM, Carlos E. R. wrote: ...

...

However, the lines for this host are like this:

[79.*.*.*]:portnumber ecdsa-sha2-nistp256 AAAAE2VjZH..... long encoded string.

What is the value of CanonicalizeHostname option on client?

I don't have that option in any file, either home or /etc/ssh/*

...

Some entries on the file are worse, totally encrypted:

|1|za.../zae...=|wx9...= ecdsa-sha2-nistp256 AAAAE2.../Gr...=

This is called "hashed hostnames". Did you try to read ssh manual pages?

Tried, yes, but I did not read it entirely and I don't know what to search for in there. I now looked at "CanonicalizeHostname" and failed to understand it at all. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" (Minas Tirith))

On 2018-03-21 13:22, jdd@dodin.org wrote:

Le 21/03/2018 à 13:16, Carlos E. R. a écrit :

...

I now looked at "CanonicalizeHostname" and failed to understand it at all.

may be

http://blog.djm.net.au/2014/01/hostname-canonicalisation-in-openssh.html

Thanks. It says: «OpenSSH 6.5 will introduce some new options to allow the client to canonicalise unqualified domain names, allowing it (for example) to understand that I actually meant "bigserver.mydomain.com" when I typed "ssh bigserver". This turns out to be important because, even though your host's DNS resolver will connect you to the host that you intended, ssh doesn't know the full name for it. » Well, this may be another problem, because both "Isengard.valinor" and "Isengard.dyndns" are the same machine. The problem is not the name, but that the IP changes. Storing it in the "known hosts" file is absurd. It should ask every time whether it is the right server. One day I may get that stored IP for another host... one chance in a million tries, but still possible. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" (Minas Tirith))

On 2018-03-21 13:36, Peter Suetterlin wrote:

Carlos E. R. wrote:

...

Well, this may be another problem, because both "Isengard.valinor" and "Isengard.dyndns" are the same machine.

The problem is not the name, but that the IP changes. Storing it in the "known hosts" file is absurd. It should ask every time whether it is the right server.

One day I may get that stored IP for another host... one chance in a million tries, but still possible.

I circumvent this issue by running tinc on my most-used machines, and use the (fixed) VPN IP to connect ;^>

But I use ssh in order to not use an VPN. I use poor man vpn services. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" (Minas Tirith))

Carlos E. R. wrote:

On 2018-03-21 13:36, Peter Suetterlin wrote:

...

I circumvent this issue by running tinc on my most-used machines, and use the (fixed) VPN IP to connect ;^>

But I use ssh in order to not use an VPN. I use poor man vpn services.

I use both. One reason is that using tinc I can easily connect to hosts behind masquerading routers, and I have quite some of those.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2018-03-21 14:36, Peter Suetterlin wrote:

...

Carlos E. R. wrote:

...

On 2018-03-21 13:36, Peter Suetterlin wrote:

...

...

I circumvent this issue by running tinc on my most-used machines, and use the (fixed) VPN IP to connect ;^>

But I use ssh in order to not use an VPN. I use poor man vpn services.

I use both. One reason is that using tinc I can easily connect to hosts behind masquerading routers, and I have quite some of those....

But then the remote machine has to initiate the connection. If not, it is the same problem with ssh, it has to traverse the NAT router

Yes, that's what tinc does. You need *one* machine with an 'open' IP address (i.e., with a dns entry, but that can be dynamical), machines connect to it and form a network. tinc is the broker that will determine how to actually connect to the other machine. E.g., for my home tinc network 'pitnet' the open machine is standing in Stockholm. Part of the machines in that network are standing in the Canary Islands, in my second home. If two of those machines communicate via the tinc network the connection does *not* go via Stockholm, but takes the direct route. It is *extremely* convenient. Have a look at it: http://www.tinc-vpn.org/ (disclaimer: The current maintainer is a good friend....) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, 2018-03-21 at 18:41 +0100, Carlos E. R. wrote:

On 2018-03-21 16:20, Peter Suetterlin wrote: <blockquote type="cite"> Carlos E. R. wrote: <blockquote type="cite"> On 2018-03-21 14:36, Peter Suetterlin wrote: <blockquote type="cite"> Carlos E. R. wrote: <blockquote type="cite"> On 2018-03-21 13:36, Peter Suetterlin wrote: </blockquote>

<blockquote type="cite"> <blockquote type="cite"> I circumvent this issue by running tinc on my most-used machines, and use the (fixed) VPN IP to connect ;^> </blockquote>

But I use ssh in order to not use an VPN. I use poor man vpn services. </blockquote>

I use both. One reason is that using tinc I can easily connect to hosts behind masquerading routers, and I have quite some of those.... </blockquote>

But then the remote machine has to initiate the connection. If not, it is the same problem with ssh, it has to traverse the NAT router </blockquote>

Yes, that's what tinc does. You need *one* machine with an 'open' IP address (i.e., with a dns entry, but that can be dynamical), machines connect to it and form a network. tinc is the broker that will determine how to actually connect to the other machine.

E.g., for my home tinc network 'pitnet' the open machine is standing in Stockholm. Part of the machines in that network are standing in the Canary Islands, in my second home. If two of those machines communicate via the tinc network the connection does *not* go via Stockholm, but takes the direct route.

It is *extremely* convenient. Have a look at it: <a href="http://www.tinc-vpn.org/">http://www.tinc-vpn.org/</a>

(disclaimer: The current maintainer is a good friend....) </blockquote>

I'll have a look.

In my case, I only reach a single machine, the rest are powered off. Now that I think, there is another one, the TV set, but I can't install anything there. I think I use telnet with that one, I don't remember this instant.

And that single machine is not directly accessible from Internet. I need to punch a hole in the router doing NAT, by redirecting a port.

Personally, I use the free version of ZeroTier. All of the connected machines can be behind NAT, and don't need to have exposed ports. There's even Android and iOS clients too.

-----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAlqypU8ACgkQQ1nEo4DF CIXblQf/b2+YhXI3fZB2zNuPJ2Qzo9SlGlCSLVqrl79DTGtTOZxOUnwiN4YzcvUh JZ9y/Mk7N6l05NY+2Eq50AHRQBGd2kHRJ8Fu5VXt8PrGQHLFpsxlOBpMhVN4XbG7 AQ0BH7n7i3hemcps7RQDSV50qWeVH6eiO+AInfMHeCGZw5hB+w6c+Zxfz95x1u3H 1oY7ylCvKG32dBNhC9/8ySdsbP78d3Jb6MBzGzBUGulZr6GmqvIQL9ukUpU6SZH/ owTMPw/byWxRObLlsoGkqSMSxYSsAoe0BRcXx+ip8J5e3NFkL98YA6HmlVB4W61C PbUizHBel7dWUrYougeJwJz3CLuL/g== =u8ZE -----END PGP SIGNATURE----- N�����r��y隊Z)z{.�ﮞ˛���m�)z{.��+�:�{Zr�az�'z��j)h���Ǿ� ޮ�^�ˬz��

On 2018-03-22 03:12, L A Walsh wrote:

Carlos...when I 1st sign into a host, I seem to remember it asking me if I wanted to store it permanently before it stored it in the "known_hosts".

In your case, I would think you wouldn't want it to store your IP in your known hosts, as the IP *isn't* really a known host.  It's only temporary.

Is it not asking you? Or ... maybe you need to turn "CheckHostIP"  off in your global ssh_config? Additionally , you will likely want to ensure "StrictHostKeyChecking" is set to "off" -- this is where the default is "ask" if you want it to ask everytime, but since all of your usage is dynamic, that doesn't seem to make sense.

In your case, checking hostIP is pointless since it changes, no?

Am I cluelessly missing something obvious here?

You hit the nail straight on :-) You are correct, but you did not notice my last reply to Andrei Borzenkov, which I forgot to label with "[SOLVED]": This is the solution. I modified the ~/.ssh/config with one more line: Host Isengard.dyndns... Port ... ServerAliveInterval 60 CheckHostIP no -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2018-03-21 14:06, Andrei Borzenkov wrote:

On Wed, Mar 21, 2018 at 3:16 PM, Carlos E. R. <> wrote:

...

On 2018-03-21 13:06, Andrei Borzenkov wrote:

...

On Wed, Mar 21, 2018 at 1:35 PM, Carlos E. R. wrote: ...

...

However, the lines for this host are like this:

[79.*.*.*]:portnumber ecdsa-sha2-nistp256 AAAAE2VjZH..... long encoded string.

What is the value of CanonicalizeHostname option on client?

I don't have that option in any file, either home or /etc/ssh/*

Yes, it is CheckHostIP option which is on by default. Disable it if you do not want IP addresses check. This makes it more vulnerable to spoofing. May be it is possible to say 79.*.*.* (known_hosts support pattern matching) which at least limits possible damage.

I'll have a look, thanks :-) Checking the IP is moot in this case, anyway: it is a dynamic IP and I don't control it. I access via key pair, not password, anyway. [...] Yes, it works. I have done like this: .ssh/config: Host Isengard.dyndns... Port ... ServerAliveInterval 60 CheckHostIP no so that it only applies to this host. Perfect! Wonderful! :-))) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" (Minas Tirith))

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, 2018-03-21 at 09:02 -0400, James Knott wrote:

On 03/21/2018 06:19 AM, David Haller wrote: <blockquote type="cite"> I suspect the keys currently are stored as such:

==== Isengard.dyndns.example.com,192.0.2.11 ssh-rsa AAA..... Isengard.dyndns.example.com,192.0.2.23 ssh-rsa AAA..... Isengard.dyndns.example.com,192.0.2.42 ssh-rsa AAA..... </blockquote> Take a look at ~/.ssh/known_hosts where you'll see only IP addresses. Also, with many ISPs, there is no consistent host name.

We do this in our ssh_config file for a couple of service providers that have similar things going on: Host isengard.dyndns.example.com UserKnownHostsFile=/dev/null StrictHostKeyChecking=no -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAlqyWKgACgkQQ1nEo4DF CIXDmwgAmr8YcwQw3elMTuYKvBIgsGeq2Ho9S6hSFY8W694pUbhzL4UJ0A5uoepi r4THdxyrYHecWeS2vEtEALDcsOD1rv/8li4dApe7CKK9kN+dk7jT69NSv1sJFP6B ckqmkmsqs+ed3XcmtjGmSYlTtrAvh9wakrCaEdrwIy6+7arJGlb6l3fht/Rxqce8 UcuANq5CRiTzwReNgtjmUNDeiviyjE7Rdg3+URDOtHg7DZzuH+7GKrX+7tO3E0Th tZololVN3vrCyQIo762bArWIxXr75OMyKr0mJ7LRkVdSLB6yhG2w8yiExUSWisO7 2afp0fadjhZqDbiyt7XAhpazNgx+JA== =9vVL -----END PGP SIGNATURE-----