search for: rfc4253

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 the greeter send by openssh 7.4 looks like: 00000000 53 53 48 2d 32 2e 30 2d 4f 70 65 6e 53 53 48 5f |SSH-2.0-...

2017-02-05 23:12 GMT+01:00 Michael Stone <mstone at mathom.us>: > > It was probably because of this commit: > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd.c.diff?r1=1.472&r2=1.473 > Yes here the combination cr and lf is removed. > Which removed support for protocols older than 2 but perhaps failed to > account for the fact that newline had been

...but i'm interested in figuring out how something like this might happen in the future. Reading the spec i don't see an explicit prohibition against multiple keys of the same key type, but i don't see how it would be handled exactly in the protocol either: https://tools.ietf.org/html/rfc4253#page-18 Looking at sshd.c, it seems to me that get_hostkey_by_type() only permits sshd to offer a single key of each type. Would it be possible for some sshd to offer more than one key of any given type? If so, this would permit such a key transition from clients that could support it? Or is th...

...H, which must reduce the impact somewhat, although the main Windows client (PuTTY) doesn't support ECDH yet. But openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which must be considered a bit suspect? Of course RFC4253 says implementations MUST offer these... The moduli file you provide has this distribution of sizes: size count 1023 36 1535 50 2047 36 3071 31 4095 41 6143 27 8191 39 Would it be sensible to remove the <2047 moduli? Generating the larger ones is quite time-consuming on non-specialist...

...t 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 this behavior. Is a "Debug Message"(SSH_MSG_DEBUG) considered anything that is logged on stderr? Any insights welcome! Cheers, Josh

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

...n individual data packet that can be sent to the sender" without pointing out if specific headers are included or not. This is equivalent to a 32768+13 byte packet for the lower layer, the binary packet protocol. There's another section which somewhat clears things out - section 6.1 from RFC4253. Each SSH Connection Protocol packet (RFC 4254) is encapsulated entirely (headers included) in the binary packet protocol (bpp) payload from the SSH Transport Layer (RFC4253). And the above mentioned section stipulates all implementations must support an uncompressed payload length of 32768 for a b...

...s 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 needs to be set up before user keys are even presented, and rfc4253 #6.3 doesn't mention the host key). I'm being asked to provide private keys to allow network sniffing (problem analysis) but I'm not sure this is the right thing to do because I'm not convinced these keys are used as part of the encryption! Thanks... -- rgds Stephen

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

...as removed. For example, Debian maintains a "openssh-client-ssh1" package built from OpenSSH 7.5 for the purpose of connecting to SSHv1 endpoints. This package or something similar is likely to be sufficient for DSA-only endpoints too. * Doesn't this make OpenSSH non-compliant with RFC4253? Practically, no more than we've been since 2015 when we stopped offering DSA by default. * Why make this change now? Why not earlier/later? We feel like enough time has passed since DSA was disabled by default for the overwhelming majority of users to have abandoned use of the algorithm. W...

...as removed. For example, Debian maintains a "openssh-client-ssh1" package built from OpenSSH 7.5 for the purpose of connecting to SSHv1 endpoints. This package or something similar is likely to be sufficient for DSA-only endpoints too. * Doesn't this make OpenSSH non-compliant with RFC4253? Practically, no more than we've been since 2015 when we stopped offering DSA by default. * Why make this change now? Why not earlier/later? We feel like enough time has passed since DSA was disabled by default for the overwhelming majority of users to have abandoned use of the algorithm. W...

...d my coworker > needs the data for a presentation to a center director here. A real problem is that the type of traffic analysis developed for multi-hop stream encryption protocols (e.g. Tor) becomes trivial and very efficient when applied to OpenSSH streams. [1] <http://tools.ietf.org/html/rfc4253#page-7>

...ity: normal Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org Reporter: jatjasjem at gmail.com According to RFC 4253, "There MAY be multiple host keys for a host, possibly with different algorithms." (https://tools.ietf.org/html/rfc4253#section-7.1) It is possible to connect using all keys that are using different algorithms (e.g. you can use ecdsa-sha2-nistp256 and ecdsa-sha2-nistp521 at the same time). It also seems to be possible to *specify* multiple keys of the same type (e.g. two ecdsa-sha2-nistp256 keys). But in the lat...

...rder given for cipher key word has an impact please? >> I mean is there a difference for the server if I do the config like : >> e.g >> Ciphers aes128-ctr,aes256-ctr >> vs >> Ciphers aes256-ctr,aes128-ctr > > It matters on the client but not on the server (see RFC4253 section 7.1) > The selected method will be the first on the client's list that appears on > the server's list. I noticed some time ago that OpenSSH still prefers aes128 over aes192/aes256 ciphers in multiple cases (CTR, GCM, and CBC). Is this due to concerns about CPU usage? These da...

...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 this behavior. Is a "Debug Message"(SSH_MSG_DEBUG) > considered anything that is logged on stderr? > > Any insights welcome! > > Cheers, > Josh > _______________________________________________ > openssh-unix-dev ma...

https://bugzilla.mindrot.org/show_bug.cgi?id=1647 Summary: Implement FIPS 186-3 for DSA keys Product: Portable OpenSSH Version: 5.2p1 Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh-keygen AssignedTo: unassigned-bugs at mindrot.org ReportedBy:

...ient and server continue the connection (proxied via the MITM) oblivious to the fact that the MITM has injected data. In SSH, the first key exchange generates a "session identifier" in addition to a key. This session identifier is used in the derivation of all future cipher and MAC keys (RFC4253 section 7.2). If an attacker tried the proxy and renegotiate SSL attack on SSH, the real client's session ID would not match that generated by the server, causing the derived keys to be different. The connection would terminate with a MAC error as soon as the first data was exchanged. (http://...

Hi, Forgive what might be a basic question. In channel open processing the server has a hardcoded maximum of 35000 bytes which corresponds to the recommended value in RFC4253. It appears that this is open to negotiation, and the RFC implies it might be desirable to support larger sizes in some channels. What determines what the absolute maximum is in openssh sshd? Presumably no client can negotiate a maximum that is larger than that advertised by the server? Tha...

Hi! Is it possible to override in OpenSSH so that the shell specified in the /etc/passwd (or what comes from the LDAP server) is not executed at login? We have na?vely tried to specify this with subsystem but found out that by default the ssh client does not specify any subsystem. So how to override something that is unset from the client? /John -- John Olsson Ericsson AB BSC/BSS System

...h] dh_gen_key: group too small: 1024 (2*need 1024) [preauth] debug1: do_cleanup [preauth] This behavior, I believe, is in error as the shared secret produced by the diffie-hellman key exchange is essentially extended to the appropriate length by successive hashes that are concatenated together per RFC4253#section-7.2 Also, it works fine in Ubuntu 14.04 / OpenSSH_6.6p1 Ubuntu-2ubuntu1. My question is... for what versions of OpenSSH an issue? I'd like to hide hmac-sha2-512 from the list of supported MAC's the client sends over for all the affected SSH servers (ie. similar to how PuTTY handle...