similar to: key rotation on ssh servers

There is no hash algorithm associated with SSH keys. The key format for RSA keys is always ?ssh-rsa?, and it is capable of being used with any of the available signature algorithms (ssh-rsa for SHA-1 and rsa-sha2-256 or rsa-sha2-512 for SHA-2). See section 3 in https://www.rfc-editor.org/rfc/rfc8332: rsa-sha2-256 RECOMMENDED sign Raw RSA key rsa-sha2-512 OPTIONAL

Hi, You will be aware of https://weakdh.org/ by now, I presume; the take-home seems to be that 1024-bit DH primes might well be too weak. I'm wondering what (if anything!) you propose to do about this issue, and what Debian might do for our users? openssh already prefers ECDH, which must reduce the impact somewhat, although the main Windows client (PuTTY) doesn't support ECDH yet. But

https://bugzilla.mindrot.org/show_bug.cgi?id=3219 Bug ID: 3219 Summary: Can't connect to a server that is using several host keys of the same type Product: Portable OpenSSH Version: 8.4p1 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5

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

Hi, I discovered when using my fuse fs for connecting to a remote host using sftp that the new server version 7.4 sends a greeter which is not according the format desribed in https://tools.ietf.org/html/rfc4253#section-4 There is written that the greeter "MUST be terminated by a single Carriage Return (CR) and a single Line Feed (LF) character (ASCII 13 and 10, respectively)." Now

Am I correct in assuming that the user and host public/private keys used in openSSH are only used for authentication (is the remote server known to be X, is this Harry trying to login), and have no role in the encryption? I was under the assumption that each connection used a newly generated key (using DH for key exchange) so each session was unique. (I believe this because the transport layer

Hi all, I have recently only discovered that openssh prints lines to stderr separated by CLRF pairs, and am trying to understand where this behavior comes from. This behavior can be seen here: --snip-- $ ssh u at u 2>&1 | sed -n l ssh: Could not resolve hostname u: Name or service not known\r$ --snip-- I have seen section 11.3 from rfc4253, but am unsure whether that is the origin of

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

Hi, I created new host keys on serverA, updated sshd_config accordingly (adding the line below) and restarted ssh: cd /etc/ssh sudo ssh-keygen -f 2024_ssh_host_ed25519_key -t ed25519 -N '' sudo vi /etc/ssh/sshd_config # added line: HostKey /etc/ssh/2024_ssh_host_ed25519_key sudo service ssh restart When I connect to serverA (`ssh -v -o UpdateHostKeys=yes serverA`) afterwards,

Hi, I sent this patch back inn april and I still have a need for this. Would it be possible to get any pointers how we can have `hashalg` selectable by `ssh-keygen -Y`? -- Morten Linderud PGP: 9C02FF419FECBE16 On Thu, Apr 11, 2024 at 09:16:39PM +0200, Morten Linderud wrote: > `ssh-keygen -Y sign` only selects the signing algorithm `rsa-sha2-512` > and this prevents ssh-agent

This message is a few years old so I cannot reply to the original, but it is still of current research interest. > So one of my coworkers is doing a little research on SSH usage in the > wild using netflow data. One of the things he's trying to do is > determine a way to differentiate between data transfers and interactive > sessions. We thought of a couple of ways but we wanted

On Mon, Oct 14, 2024 at 5:33?AM Jan Eden via openssh-unix-dev <openssh-unix-dev at mindrot.org> wrote: redacted hostname and port ? sorry, should have mentioned that. > > > Anyway, in answer to your question. The "host key found matching a different > > name/address" is triggered when a key received from the server in an update > > already exists under a

The full SSH_MSG_CHANNEL_DATA packet looks like this: uint32 packet length byte SSH_MSG_CHANNEL_DATA uint32 recipient channel uint32 nr data bytes byte[] data OpenSSH_6.1p1 considers that the 'maximum packet size' from SSH_MSG_CHANNEL_OPEN or SSH_MSG_CHANNEL_OPEN_CONFIRMATION impacts only the 'byte[] data' field and not the entire message (headers included).

Hi, according to RFC 4253 https://www.rfc-editor.org/rfc/rfc4253#section-7.1 for the selection of algorithms (ciphers, KEX, MAC etc.), the leftmost matching client algorithm is picked. While this is fine in most cases, there are cases where it is not desirable, for example: 1) for compatibility with a single old client you enable an old cipher, say aes128-cbc, server side. A modern client

From: Maxime Rey <maximejeanrey at gmail.com> Hello, I've discovered an issue with sshd when it's configured to use the SSH agent alongside multiple host keys. Specifically, this problem happens during the hostkeys-prove-00 at openssh.com request, when the server attempts to demonstrate ownership of the host keys by calling the agent. The issue occurs because, while processing the

Compiled OK, and operating nicely on CentOS 6.6, both 32/64 bit. Really appreciate the UpdateHostkeys feature! One issue I noticed, the screen output gets garbled if the user has been "asked" to "Accept" the new hostkeys. Looks like the screen output is missing the CR's, and only LF's get presented. [root at be2 .ssh]# ssh be1 ls -l Warning: Permanently added

While compiling openssl with option `no-des', it caused the openssh build failure ... cipher.c:85:41: error: 'EVP_des_ede3_cbc' undeclared here (not in a function); ... Signed-off-by: Hongxu Jia <hongxu.jia at windriver.com> --- cipher.c | 2 ++ configure.ac | 20 ++++++++++++++++++++ 2 files changed, 22 insertions(+) diff --git a/cipher.c b/cipher.c index

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]

On 2024-10-17 19:26, Nico Kadel-Garcia wrote: > > Thank you! Increasing the verbosity revealed a known_hosts entry linked > > to serverA's IP address (I had forgotten that I had connected to it by > > IP address at some point). Deleting this entry solved the problem; the > > new host key was stored in known_hosts when I connected to serverA > > again. > >

Hi, OpenSSH plans to remove support for DSA keys in the near future. This message describes our rationale, process and proposed timeline. Rationale --------- DSA, as specified in the SSHv2 protocol, is inherently weak - being limited to a 160 bit private key and use of the SHA1 digest. Its estimated security level is <=80 bits symmetric equivalent[1][2]. OpenSSH has disabled DSA keys by