similar to: Disabling host key checking on LAN

Perfect, thanks. This winds up working for me (as far as I've tested so far.) Match exec "ping -q -c 1 -t 1 %n | grep '192\.168\.'" StrictHostKeyChecking no UserKnownHostsFile none On Wed, Aug 26, 2015 at 11:47 PM, Bostjan Skufca <bostjan at a2o.si> wrote: > (+cc list) > > You could use something in the following manner: > > Match originalhost *

On Fri, Aug 28, 2015 at 11:51 PM, Walter Carlson <wlcrls47 at gmail.com> wrote: > On Thu, Aug 27, 2015 at 12:26 AM, Walter Carlson <wlcrls47 at gmail.com> wrote: > >> Perfect, thanks. This winds up working for me (as far as I've tested so >> far.) >> >> Match exec "ping -q -c 1 -t 1 %n | grep '192\.168\.'" >>

On Sun, Aug 30, 2015 at 6:57 AM, Bostjan Skufca <bostjan at a2o.si> wrote: > Nico, > > those were my thoughts, exacly, except that I was thinking about using "dig > +short HOST | ..." which has the cleanest output of all. Excellent point. I like it! It can get a bit confusing with round-robin DNS, which can give multiple responses. > But there is that initial

On Fri, Aug 28, 2015 at 8:48 AM, Bostjan Skufca <bostjan at a2o.si> wrote: > On 27 August 2015 at 05:01, Damien Miller <djm at mindrot.org> wrote: >> Yeah, it's unfortunately quite difficult to implement address matching >> in ~/.ssh/config because of the interplay of Host matching, Hostname >> directives, hostname canonicalisation*, proxy commands, hosts

Hi there, (context: I was optimizing Roundcube mailbox list server response, and in that 300-400ms response time, around 170ms is spent on single fgets() call which is waiting IMAP repsonse to "SELECT MyMailbox" command) I straced dovecot and of the whole request/response process, around 30ms is spent for everything else, and overwhelming majority of time (150-170ms) is spent for

On Thu, 27 Aug 2015, Bostjan Skufca wrote: > Are you connecting by specifying "ssh HOSTNAME" instead of "ssh IP.IP.IP.IP"? > > If this is the case, then "Host 192.168.*.*" line never matches when > you think it should. > > From ssh_config manpage: > "The host is the hostname argument given on the command line (i.e. the > name is not

Thanks for clarification. One question though: As far as I have tested openssh, it logs every unsuccessful authentication attempt on the very moment it becomes unsuccessful, not after the connection is closed (after timeout or when reaching max auth attempts). Is this true or not even for this attack or not? Because if it is true, if there is a IDS system that bans IP after X failed logins,

I read an article today about keyboard interactive auth allowing bruteforcing. I'm afraid I have minimal understanding of what keyboard-interactive really does. What does it do, and should I have my clients set it to off in sshd_config? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |

Hi all, authentication forwarding depends much on the environment it is used in, but generally on shared hosts it is considered insecure, as this documentation and common sense tell us: http://unixwiz.net/techtips/ssh-agent-forwarding.html Anyway, I have an auth forwarding security enhancement proposal. I hope I am not duplicating someone else's words/thoughts, please notify me if this is

https://bugzilla.mindrot.org/show_bug.cgi?id=1993 alex at testcore.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alex at testcore.net Version|5.9p1 |6.2p1 --- Comment #1 from alex at testcore.net --- Also

Brian Candler wrote: > Chris Green wrote: > > ... redundant ones are because I have a mixed population of > > Raspberry Pis and such on my LAN and they get rebuilt fairly > > frequently and thus, each time, get a new entry in known_hosts. > ...many useful tips... > To disable host key checking altogether for certain domains and/or networks, > you can put this in

On Sun, 4 Oct 2020, Christoph Anton Mitterer wrote: > On Sun, 2020-10-04 at 14:02 +1100, Damien Miller wrote: > > This is strictly no worse than continuing to use the old key, so I > > don't consider it a problem. > > Well but in reality it will lead to people never again replace their > key by proper means. Well, first I disagree that this method is improper. The

Hello & thanks for reading. I'm having a problem configuring known_hosts from scripts so an accept key yes/no prompt doesn't appear. I'm using this command to detect if the server is known and add it to known_hosts: if ! ssh-keygen -F ${IP_ADDR} -f ~/.ssh/known_hosts > /dev/null 2>&1; t hen ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi This works

Hello there, I'm a little afraid of writing here, hope I don't make any mistake doing so. I'm trying for days and searching the web too, but no obvious solution, no reply from the specialized forum I wrote in. Here is the situation: I would like to have a lighter security inside our domain, without changing when going outside. By "lighter security" I mean at least, no

Hi! Is it somehow possible to disable the known_hosts checking for some hosts? The StrictHostKeyChecking affects only the asking about new computers, but doesn't affect the changed ones. I need it for the test computers, which are reinstalled twice/hour and I really don't like editing .ssh/known_hosts each time :-( Thanks Michal

Hi, is there a particular reason why this feature is "user" based and not "user-pubkey" based? What I mean is that it works for installation with small number of pubkeys per user. But imagine i.e. a GitHub scale - all users logging in as user "git". On each auth request all the keys from database would be fetched and feeded to OpenSSH. Now I am only asking this out

On 03/15/2019 12:49 AM, Jeremy Lin wrote: > [...] connecting to hosts where the host key > changes frequently. I realize this is a fairly niche use case [...] Doesn't StrictHostKeyChecking=no do what is wanted?

As far as I can tell, there currently isn't a straightforward way to use password authentication for connecting to hosts where the host key changes frequently. I realize this is a fairly niche use case, but when developing software for devices that often get reimaged (resulting in a host key change), it can get pretty tedious to attempt to connect, get a warning, remove the old host key via

Greetings CentOS community! I connect to a very large number of new machines with a handful of my CentOS boxen. Whenever I connect to a new host, I *REALLY* would like to *NOT* see the error message such as this: The authenticity of host 'w.x.y.z (w.x.y.z)' can't be established. RSA key fingerprint is 62:7a:6c:e5:03:f5:47:be:23:a5:c5:e5:c3:60:9b:8d. Are you sure you want to continue

Trying to get SSH agent forwarding working for a popular open source configuration management system called Ansible. I?ve had some unexpected behaviour, the only cause of which I can find is how I express the command line arguments. http://stackoverflow.com/questions/20952689/vagrant-ssh-agent-forwarding-how-is-it-working?noredirect=1#comment31511341_20952689 In summarise: In the first