openssh bugs - Jan 2016 - [Bug 2525] New: Please add an alias such as -o Insecure for -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

https://bugzilla.mindrot.org/show_bug.cgi?id=2525

            Bug ID: 2525
           Summary: Please add an alias such as -o Insecure for -o
                    UserKnownHostsFile=/dev/null -o
                    StrictHostKeyChecking=no
           Product: Portable OpenSSH
           Version: 6.7p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: trivial
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: mjevans1983 at gmail.com

Please add an alias such as -o Insecure for -o
UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

I would like to be able to easily, when typing out an SCP/SSH command
for use on a trusted local network, connect to a non-permanent system
(E.G. a rescue system running from ram or a new VM which is going to be
re-configured) without impacting the known hosts file or even asking me
what it's key is.

There are three advantages of -o Insecure over the existing option:

* It's more clear what you're telling ssh / scp / sftp to do.
* It's easy to remember and type.
* The special file /dev/null might, on some crazy system, be different,
or unavailable.  It's actually just a way of subverting the request for
a file to store the data in.  -o Insecure could avoid even opening a
file.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2525

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> ---
Why not just add an entry in ~/.ssh/config for the specific
system/domain containing those options?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2525

--- Comment #2 from Michael J Evans <mjevans1983 at gmail.com> ---
The intended use is /precisely for/ //non-permanent// systems.

I've already included example use cases:

* Systems running a rescue shell (which might normally host an SSH
server or which might even normally be of an entirely different
nature).
* VMs which are in the process of being setup or that are too temporary
to warrant any kind of central repository efforts.

I also want a discussion, or at least un-official approval, of the name
I selected for the feature.  I believe it to be fitting, descriptive,
and easy to remember; unlike the existing options which, while better
left at their default values are clearly designed for use in
configuration files, rather than by humans.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2525

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #3 from Darren Tucker <dtucker at zip.com.au> ---
Sorry, I don't think it's worth adding yet another option to do
something that you can already do multiple ways.
> The intended use is /precisely for/ //non-permanent// systems.
The systems might be transient but you can still keep the config entry:

$ cat <<EOD >>~/.ssh/config
Host rescue
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking=no
EOD
$ ssh -o hostname=10.1.1.1 rescue

or a shell alias:
$ alias insecuresh=" -o UserKnownHostsFile=/dev/null -o
StrictHostKeyChecking=no"
> I also want a discussion, or at least un-official approval of the name
> I selected for the feature
You missed a step: agreement that it's worth doing.  I don't think it
is.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2525

Michael J Evans <mjevans1983 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |---
             Status|RESOLVED                    |REOPENED

--- Comment #4 from Michael J Evans <mjevans1983 at gmail.com> ---
I disagree with /your/ opinion.  As a user who frequently has temporary
systems up for service I already effectively use -o Insecure, but via
shell scripts which provide an incomplete solution and a clunkier
interface.  I know I am not the only one who makes such connections. 
Just because /your/ use cases are satisfied by providing longer harder
to remember configurations on the command line or by coding in to more
persistent configuration files one time exceptions does not mean that
the use cases of others is satisfied.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2525

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|REOPENED                    |RESOLVED

--- Comment #5 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to Michael J Evans from comment #4)
> I disagree with /your/ opinion.  As a user who frequently has
> temporary systems up for service
As one of the maintainers of the software, I feel that my opinion on
what does and does not go into the software is somewhat relevant.
> I already effectively use -o
> Insecure, but via shell scripts which provide an incomplete solution
> and a clunkier interface.
Both of them do exactly what you want so are by definition complete. 
You are of course welcome to dislike the interface.
> Just because /your/ use cases are satisfied by
> providing longer harder to remember configurations on the command
> line or by coding in to more persistent configuration files one time
> exceptions does not mean that the use cases of others is satisfied.
Different people's needs are different, that's why there's a config
file. As shown in comment #3, you can already do what you want via the
config file, and assuming you use "insecure" as the Host entry,
it's
only 5 keystrokes more than your proposal (less if you use a shorter
name) and infinity percent less code.

So, sorry but no I don't think this is worth doing.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2525

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
Close all resolved bugs after release of OpenSSH 7.7.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.