similar to: [PATCH] Specify signature algorithm during server hostkeys prove

Hi, About a year and a half ago I brought up the topic of encrypted hostkeys and posted a patch (http://marc.info/?l=openssh-unix-dev&m=132774431906364&w=2), and while the general reaction seemed receptive to the idea, a few problems were pointed out with the implementation (UI issues, ssh-keysign breakage). I've finally had some spare time in which to get back to this, and I've

Hello, OpenSSH-wizards. In our company, we have looked into SSH-HostKey-signing in order to realize automated access without the need to accept the server's hostkey, manually. I got it to work with the HostCertificate-directive inside the sshd_config. Now, I was wondering whether it is possible to have multiple signatures, so I can, for example, sign the hostkey once with a

On Thu, Sep 21, 2017 at 02:22:10AM -0500, Zev Weiss wrote: > test_kex: regress/unittests/kex/test_kex.c:91 test #1 "sshkey_generate" > ASSERT_INT_EQ(sshkey_generate(keytype, bits, &private), 0) failed: > sshkey_generate(keytype, bits, &private) = -56 That error code is: $ grep -- -56 ssherr.h #define SSH_ERR_KEY_LENGTH -56 Unfortunately there's lots of

Hello, OpenSSH supports PKCS#11 on the client side, but that does not extend to the server side. I would like to bring PKCS#11 support to sshd. I am working on embedded Linux systems with integrated HSM. The sshd host key is stored on the HSM. To have sshd using that key, we rely on the following chain: sshd -> OpenSSL -> OpenSSL Engine -> HSM Having PKCS#11 support in sshd, would

My apologies if this has been covered already. My search of the archives was unfruitful. OpenSSH seems to be lacking a certain capability present in ssh.com's client; namely, the ability to store remote hostkeys on a per-port basis. I have various machines that, due to iptables port-forwarding, appear to be running copies of (open)sshd on multiple ports. "Commercial" ssh stores

Hello, This hostkeys extension is great, reading[1]: """ OpenSSH supports a protocol extension allowing a server to inform a client of all its protocol v.2 host keys after user-authentication has completed. """ I wonder, why should user authentication be completed before this functionality is available? This means that ssh-keyscan tool (for example) cannot take

http://bugzilla.mindrot.org/show_bug.cgi?id=1279 Summary: Address- and/or port-specific HostKeys support Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: sshd AssignedTo: bitbucket at mindrot.org ReportedBy:

https://bugzilla.mindrot.org/show_bug.cgi?id=2131 Bug ID: 2131 Summary: ssh: list known names (if any) for new hostkeys Product: Portable OpenSSH Version: 6.2p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at

http://bugzilla.mindrot.org/show_bug.cgi?id=416 Summary: problems with sshd starting up and hostkeys Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy:

Hi, I often change the machines (and thus the hostkeys) that are on a IP (a service environment with a IP assinged for the machine to test). So every time I want to connect to a new machine I have to delete the previous key from the known_hosts file. Since I got tired of running a remove script manually, I made this small patch which adds the possibility to replace the real key with the

http://bugzilla.mindrot.org/show_bug.cgi?id=216 Summary: ssh-keygen vs. SSH Version 2.0.13 hostkeys Product: Portable OpenSSH Version: 3.1p1 Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: ssh-keygen AssignedTo: openssh-unix-dev at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=2357 Bug ID: 2357 Summary: please add "vhosting" features respectively per-LocalAdress HostKeys/etc. Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5

Hey folks, I've asked this on the security focus mailing list, but no one seems to know... I'm in the process of moving my company from old crufty ssh.com ssh1 to openssh. On most of our hosts, we've created rsa and dsa keys but managed to KEEP the old rsa1 key... However, on a few hosts, openssh has been unable to read the old rsa1 key and has claimed: debug1: Unsupported

http://bugzilla.mindrot.org/show_bug.cgi?id=216 ------- Additional Comments From markus at openbsd.org 2002-04-16 02:34 ------- please test against latest snapshot. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=416 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From markus at openbsd.org 2002-10-18

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 +++++++++++++++++++++++++++++++++------

Hello, maybe someone could please help and shed some light on a problem that i don't understand, and that even in multiple ways. The problem occurred three or four times over the past months (maybe half a year?) and manifests as ++ Pushing to "gitlab" (at least "master" differs)! Warning: Permanently added the RSA host key for IP address '104.46.105.89' to the

Hello! Like many organizations, we have "disaster-recovery" location, where separate servers are running ready to take up important services should the primary location fail. Some of the services provided involve accepting files over scp (and sftp), and here is the problem... The primary and the secondary hosts use different host-keys... If the hosts were accessed as

In sshconnect.c there are two global variables for server_version_string client_version_string. These are used just in a few functions and can easily be passed as parameters. Also, there is a strange construct, where their memory is allocated to the global pointers, then copies of these pointers are assigned to the kex structure. The kex_free finally frees them via cleanup of the kex

This (very quick) patch allows you to connect with the commercial ssh.com windows client and use x509 certs for hostkeys. You have to import your CA cert (ca.crt) in the windows client and certify your hostkey: $ cat << 'EOF' > x509v3.cnf CERTPATHLEN = 1 CERTUSAGE = digitalSignature,keyCertSign CERTIP = 0.0.0.0 [x509v3_CA]