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.
Why not just add an entry in ~/.ssh/config for the specific system/domain containing those options?
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.
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.
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.
(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.
Close all resolved bugs after release of OpenSSH 7.7.