similar to: kex guess methods incorrect?

Is this really caused by a buggy server, or is this an interoperability problem? It seems to work ok when I specify -o "protocol 1" on the command line. Thanks, Greg [gleblanc at grego1 gleblanc]$ ssh -v login.metalab.unc.edu SSH Version OpenSSH_2.2.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data /etc/ssh/ssh_config debug: Applying

Hi all, I'm setting up a system where users will only be able to use "sftp" but not "ssh" to connect to the server (http://www.snailbook.com/faq/restricted-scp.auto.html). Here's the setup... Server: OpenSSH 2.5.2p2-1 on RH Linux Client: Commercial SSH 2.4 on Solaris The vendor on the client system creates a key pair and sends it to me. I then add the vendor's

Yo All! I have been playing with SSH 2.2.0 from www.ssh.com. I can not connect to openssh 2.2.1p1 using Ver 2 protocol from ssh Ver 2.2.0. Ver 1 works fine. See below for the debug output from both ends If I force hmac-md5 (-m hmac-md5) from the sender it works! The other 3 choices fail: hmac-sha1; hmac-md5-96; and none. I have no problem connecting to this openssh host (hobbes) from

I must be missing the point here somehow. From my simple mind I think that two things would be needed - first a mod, e.g., mod_sshd, or better an addition to mod_auth and mod_proxy so that a URL could be used to initiate contact to an sshd server elsewhere. The mod_auth part could/should be used to verity the credentials to used - basically setting up the VPN between ssh and httpd as ssh; the

I have a couple of keys generated using the F-Secure SSH2 client. I have converted those keys using "ssh-keygen -i -f samplekey.txt >> ~/.ssh/authorized_keys". When I try and log into the OpenSSH server using those keys, OpenSSH rejects using those keys. I am under the assumption that this is supposed to work. If I connect using a password, there is no problem. It just does not

https://bugzilla.mindrot.org/show_bug.cgi?id=3663 Bug ID: 3663 Summary: KEX host signature length wrong since strict kex introduced Product: Portable OpenSSH Version: 9.6p1 Hardware: Other OS: Linux Status: NEW Severity: major Priority: P5 Component: sshd

Hi, I was using F-Secure SSH V2.0 client to connect openssh server. Here the relevant part of the client log. ----------------------------------------------------- local ip = 172.168.29.8, local port = 4870 remote ip = 172.168.29.7, remote port = 22 remote hostname is "172.168.29.7". Wrapping... Remote version: SSH-2.0-OpenSSH_3.2.2p1 CBVersionCheck: remote version

I'm in the process of updating my GSSAPI patches to the 2.9 release. However, I've run into a slight problem with managing to get user options to play nicely with the way that the kex code is now organised. With the GSS kex its possible for the user to specify whether they want to delegate their credentials to the server or not. This option is used only on the client side (and so is

Dear all, I am currently implementing an experimental key exchange (KEX) algorithm. Unlike current algorithms like DH, mine needs to be able to fail gracefully, and in case of failure, continue with whatever algorithm would have been negotiated if mine was not selected. My strategy for graceful failure is to remove my KEX algorithm from myproposal[KEX_DEFAULT_KEX] and to initiate a new key

https://bugzilla.mindrot.org/show_bug.cgi?id=1486 Summary: Improperly used buffer during KEX Classification: Unclassified Product: Portable OpenSSH Version: 5.0p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Miscellaneous AssignedTo: unassigned-bugs at

Hi, I'm currently trying to troubleshoot what appears to be a very subtle bug (most likely a race condition) in SPTPS that causes state to become corrupted during SPTPS key regeneration. The tinc version currently deployed to my production nodes is git 7ac5263, which is somewhat old (2014-09-06), but I think this is still relevant because the affected code paths haven't really changed

Hi, mancha and me debugged a problem with OpenSSH 7.3p1 that was reported on the #openssh freenode channel. Symptoms were that this message was popping on the console during a busy X11 session: kex protocol error: type 7 seq 1234 I managed to reproduce the problem, it is related to the SSH_EXT_INFO packet that is send by the server every time it is sending an SSH_NEWKEYS packet, hence after

Hello, in addition to my last thread about a new config option to make strict-kex mandatory, I also wonder if a new mechanism for ciphers/macs can be introduced and is reliable by simple both sides using it. So there could be a Chacha20-Poly1305v2 at openssh.com which uses AD data to chain the messages together, so it will be resistant against terrapin even without the strict-kex. Consequently

Hi there, > So there could be a Chacha20-Poly1305v2 at openssh.com which uses AD data to chain the > messages together, so it will be resistant against terrapin even without the strict-kex. > > Consequently the hmac-etmv2 at openssh.com mode could be deviced in a similar manner, to > also include the transcript hash or similar things. This would still require both, client and

I have a Putty variant that works well with openSSH up until 7.4. After git bisecting I found that after the application of c38ea634893a1975dbbec798fb968c9488013f4a the client fails with host key mismatch. The commit in question appears to remove vestiges of ssh-1 support but my client is using 2.0. I am trying to work out what in that commit would lead to the symptoms. I have been through the

http://bugzilla.mindrot.org/show_bug.cgi?id=148 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|markus at openbsd.org |openssh-unix-dev at mindrot.org ------- You are receiving this mail because: ------- You are the assignee for the bug, or are

https://bugzilla.mindrot.org/show_bug.cgi?id=2302 Bug ID: 2302 Summary: ssh (and sshd) should not fall back to deselected KEX algos Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: security Priority: P5 Component: ssh

https://bugzilla.mindrot.org/show_bug.cgi?id=2302 Bug ID: 2302 Summary: ssh (and sshd) should not fall back to deselected KEX algos Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: security Priority: P5 Component: ssh

Hi, I have a strange problem with a freshly installed Centos7 desktop (most8pc25). I can't ssh to 2 CentOS6 servers, even with firewall disabled on the client and on the server. But I can connect from the server to the client, all in the same VLAN. I can also ssh from this desktop to centos7 servers in the same VLAN or in another VLAN. No idea about this problem. On the server kareline

https://bugzilla.mindrot.org/show_bug.cgi?id=2198 Bug ID: 2198 Summary: GSSAPIKeyExchange gssapi-keyex bug in kex.c choose_kex() Product: Portable OpenSSH Version: 6.4p1 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: Kerberos support