similar to: OpenSSH_6.1p1 sends a SSH packet bigger than 32K

The patch below implements a couple of features which are useful in an environment where users do not have a regular shell login. It allows you to selectively disable certain features on a system-wide level for users with a certain shell; it also allows you to control and audit TCP forwarding in more detail. Our system is an email server with a menu for the login shell; we selectively allow port

this (uncomplete) patch makes various features compile time options and saves up to 24K in the resulting ssh/sshd binaries. i don't know whether this should be added to the CVS since it makes the code less readable. perhaps WITH_COMPRESSION should be added, since it removes the dependency on libz -m Index: Makefile.inc =================================================================== RCS

I recently ran across a problem with remote port forwarding in OpenSSH when trying to use dynamic ports. While it is possible to use OpenSSH to request a dynamic port and the OpenSSH sshd handles it just fine, the OpenSSH client gets confused when multiple ports are opened this way, due to the information passed in the "forwarded-tcpip" SSH_MSG_CHANNEL_OPEN message which is sent back to

https://bugzilla.mindrot.org/show_bug.cgi?id=2147 Bug ID: 2147 Summary: OpenSSH remote forwarding of dynamic ports doesn't work when you create more than one Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: normal Priority: P5

Hi ! Here's a patch to add remote port forwarding support (protocol 2) for openssh. I have tried to test that it works like it should but a more thorough testing is needed. This patch adds both client/server support. The patch should be applied to openssh-2.1.1p4 source tree. Also included is a PortForwarding sshd_config option, new ./configure option --disable-forwarding that should make it

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

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

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

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

hi OpenSSH folks-- I have several OpenSSH sshd servers that i've maintained for a long time. Some of them have keys that are considered short by today's standards (e.g. 1024-bit RSA keys). On these servers, I would like to be able to do a key rotation such that multiple keys are valid during a time window so that users can learn the new key before i remove the old one. I don't

https://bugzilla.mindrot.org/show_bug.cgi?id=2529 Bug ID: 2529 Summary: direct-streamlocal channel open doesn't match PROTOCOL documentation Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: ssh

I don't see a problem, my MTU is at the default value = 1500, but when I look at the trace from libssh2, packet type 4 received, => SSH_MSG_DEBUG packet type 91 received, => SSH_MSG_CHANNEL_OPEN_CONFIRMATION packet type 93 received, => SSH_MSG_CHANNEL_WINDOW_ADJUST packet type 99 received, => SSH_MSG_CHANNEL_SUCCESS packet type 98 received, => SSH_MSG_CHANNEL_REQUEST packet

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

Today I modified OpenSSH so that it allows me to configure in a generic way, restrictions on what server functions can be used by system users after they authenticate. The partial implementation of my plans only works for SSH2, but allows me to write entries like the following in sshd_config: ChannelReqDeny shell g restricted ChannelReqDeny exec g restricted ChannelReqDeny x11-req u

The version of sshd in FreeBSD 8.4 is not backward compatible with older version from 8.3. OpenSSH_5.4p1 (on FreeBSD 8.3) OpenSSH_6.1p1 (on FreeBSD 8.4) # sshd -t /etc/ssh/sshd_config line 19: Missing argument. On line 19, there is: VersionAddendum It was OK in older versions. It will remove any default text appended to SSH protocol banner (for example 'FreeBSD-20120901'). On

I am trying to make sense of the way in which OpenSSH computes window size, so far without much success :-( My understanding is that when a client specifies a window size N at the beginning of a session, it is letting the server know that it (the server) can send, on a given channel, up to N bytes worth of data that consumes window space (essentially the payload of SSH_MSG_CHANNEL_DATA and one

Hi, This is just a quick note to state that the recently reported SSL/TLS MITM attack[1] *does not* affect SSH. Like SSL/TLS, SSH supports key and parameter renegotiation, but it is not vulnerable because a session identifier is carried over from the first key exchange into all subsequent key exchanges. Technical details: In SSL, key exchanges and subsequent renegotiations are completely

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

On Ubuntu 12.04 / OpenSSH_5.9p1 Debian-5ubuntu1 trying to initiate a connection with hmac-sha2-512 and diffie-hellman-group1-sha1 results in OpenSSH killing the connection after the SSH_MSG_KEXINIT packet is sent. The OpenSSH error logs state the following: debug2: mac_setup: found hmac-sha2-512 [preauth] debug1: kex: server->client arcfour256 hmac-sha2-512 none [preauth] dh_gen_key: group too