search for: host_keys

Hi list, I use ssh a lot and I often need to connect to hosts whose host key has changed. If a host key of the remote host changes ssh terminates and the user has to manually delete the offending host key from known_hosts. I had to do this so many times that I no longer like the idea ;-) I would really like ssh to ask me if the new host key is OK and if I want to add it to known_hosts. I talked

Hi, Is there any way to store HostKey in hardware (and delegate the related processing)? I have been using Roumen Petrov's x509 patch for clients, which works via an OpenSSL engine, but it does not seem to support server HostKey: http://roumenpetrov.info/pipermail/ssh_x509_roumenpetrov.info/2012q4/000019.html For PKCS#11, I have found an email on this list from a year back suggesting this

...ing worked fine that means I can connect with "a" and "b" and the client doesn't tell me something from "man in the middle..." With the lines ssh -2 -p 22136 root at firewall as well as ssh -2 -p 22137 root at firewall the client doesn't recognise that the host_keys are identical and says everytime that there can be a "man in the middle..." Does have anybody a solution? Regards Stephan -- LDS Brandenburg Dr. Stephan Hendl fon: +49-(0)331-39 471 fax: +49-(0)331-27548 1187 EMail: stephan.hendl at lds.brandenburg.de

Have you seen this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513 --mancha

...unsupported key type (%s)", __func__, + key_type(key)); + } + + return key; +} diff --git a/sshd.c b/sshd.c index c8d71f8..f458860 100644 --- a/sshd.c +++ b/sshd.c @@ -175,6 +175,7 @@ int rexeced_flag = 0; int rexec_flag = 1; int rexec_argc = 0; char **rexec_argv; +int num_rexec_recvd_host_keys = 0; /* * The sockets that the server is listening; this is used in the SIGHUP @@ -898,6 +899,7 @@ usage(void) static void send_rexec_state(int fd, Buffer *conf) { + int i, num_host_keys; Buffer m; debug3("%s: entering fd = %d config len %d", __func__, fd, @@ -914,6 +916,8 @...

There's currently no way to express trust for an SSH certificate CA other than by manually adding it to known_hosts. This patch modifies the automatic key write-out behaviour on user verification to associate the hostname with the CA rather than the host key, allowing environments making use of certificates to update (potentially compromised) host keys without needing to modify client

In the current implementation, ssh always uses the hostname supplied by the user directly for the SSHFP DNS record lookup. This causes problems when using the domain search path, e.g. I have "search example.com" in my resolv.conf and then do a "ssh host", I will connect to host.example.com, but ssh will query the DNS for an SSHFP record of "host.", not

...*auth_conn = NULL; + /* * Any really sensitive data in the application is contained in this * structure. The idea is that this structure could be locked into memory so @@ -206,6 +210,7 @@ struct { Key *server_key; /* ephemeral server key */ Key *ssh1_host_key; /* ssh1 host key */ Key **host_keys; /* all private host keys */ + Key **host_pubkeys; /* all public host keys */ Key **host_certificates; /* all public host certificates */ int have_ssh1_key; int have_ssh2_key; @@ -652,11 +657,18 @@ privsep_preauth(Authctxt *authctxt) } else if (pid != 0) { debug2("Network child is...

...ified in the sshd_config that does not exist (I used "./sshd -d -d -d -f sshd_config" with the shipped sshd_config file, to work around incompatibilities with the installed sshd.com's sshd_config, and I do not have ssh2 host keys on this machine), sshd will leave sensitive_data.host_keys[<i>] uninitialized - the memory area is malloc()ed, so never initialized, and later on destroy_sensitive_data reads a pointer from it and tries to overwrite *that* memory location. A quick fix is appended below: if a host key file can't be read, host_keys[i] is set to NULL. This does...

The attached patch implements a feature that would make my interaction with ssh somewhat more secure. When connecting to a host whose key is not in the known_hosts file, this patch makes ssh tell the user about any other hosts in the known_hosts file that have the same key. For example, if I have host A in my known_hosts file, and try to connect to host B which is an alias for A, ssh will tell

Hello, Due to patent concerns, I compiled a version of openssl with the no-rsa, no-idea, no-rc5 options. I was able to then take this compile of openssl, with the standard openssh-2.1.0 rpms and run it on another machine. Most things seemed to work fine, except I was unable to ssh into the machine. After applying the following patch to the sshd code, a quick test with an ssh session worked:

Scenario: I have access to a semi-public (about 30 users) server where I keep my webpage. Occasionally, especially if I'm on the road. I use this as a bounce point to get to "secured" systems which only allow ssh from certian IP's. (Ignoring the discussion on spoofing, since we have host keys) But host keys are the problem. If anyone gets root on this hypothetical

...f --git a/sshd.c b/sshd.c index dda8d9b77..cbdced5db 100644 --- a/sshd.c +++ b/sshd.c @@ -1533,6 +1533,8 @@ main(int ac, char **av) } else { do_log2(ll, "Unable to load host key: %s", options.host_key_files[i]); + sshkey_free(pubkey); + pubkey = NULL; sensitive_data.host_keys[i] = NULL; sensitive_data.host_pubkeys[i] = NULL; continue; -- 2.45.2

Howdy -- I have a number of servers with host keys validated by certificates. These systems are behind a load-balanced frontend, and the certificates are signed as valid for the DNS name used by that common frontend address. This works well for the primary use case of the systems; however, when wishing to address only a single unit within the pool, the certificate cannot be used to validate that

I'm trying to replace some sshv1 clients and servers in a modular way, and the "Server Lies" warning (when the server says the key has one more bit than it really has) is causing heartache. Per the FAQ, this is relatively benign. Here's a patch that allows an admin or user to disable the warning. - Morty diff -Nur openssh-3.7.1p2/readconf.c

I am on Solaris 2.8 with openssh 2.3.0p1 and openssl 0.9.6. The remote machine is running ssh.com 1.2.20 and Solaris 2.6. I think the problem has to do with the 1.2.20 KeyRegeneration, because in the next hour I will beable to get into the machine ok with openssh and then later in the day I will not beable to ssh in again for another hour. ssh -v -v sa at myhost.com SSH Version OpenSSH_2.3.0p1,

Hi, I am happy to (re)send a set of patches for compiling OpenSSH 4.7p1 with FIPS 140-2 OpenSSL. These are based on previously reported patches by Steve Marquess <marquess at ieee.org> and Ben Laurie <ben at algroup.co.uk>, for ver. OpenSSH 3.8. Note that these patches are NOT OFFICIAL, and MAY be used freely by anyone. Issues [partially] handled: SSL FIPS Self test. RC4,

When connecting to a host for which there's no known hostkey, check if the relevant key has been accepted for other hostnames. This is useful when connecting to a host with a dymamic IP address or multiple names. --- auth.c | 4 ++-- hostfile.c | 42 ++++++++++++++++++++++++++++-------------- hostfile.h | 8 ++++++-- sshconnect.c | 39 +++++++++++++++++++++++++++++++++------

Hi, I've reported this problem a month ago on this list, and probably no-one is interested? Binaries were configured with krb4 and afs enabled. However, only the second crash seems to be related to krb4. Any thoughts? I had to add one line to includes.h: #include <sys/types.h> #include <sys/socket.h> #include <sys/ioctl.h> +#include <sys/ioccom.h> #include

Below is a patch against the current OpenBSD OpenSSH CVS to workaround a behavior I have observed when converting from SSH 1.2.27 to OpenSSH while using the same old RSA1 host key for protocol 1. In several cases I saw that old SSH sshd reported a host key size of 1024 bits when OpenSSH saw it as 1023 bits. Without the patch, when OpenSSH's ssh client connects to an old SSH sshd it warns