similar to: sshd: DES in SSH1 ?

I see that: SSH uses the following ciphers for encryption: Cipher SSH1 SSH2 DES yes no 3DES yes yes IDEA yes no Blowfish yes yes Twofish no yes Arcfour no yes Cast128-cbc no yes Two ques re: sshd: 1) Using openssh, how do I configure which

I think I've found a bug with sshd handling audit events for commands (like scp) over ssh1 connections. Specifically, after updating to a recent FreeBSD 6.x with audit support, I'm getting log messages like these when using scp over ssh1: Sep 12 14:13:16 <auth.info> bm55 sshd[12335]: Accepted rsa for xxx from A.B.C.D port 2981 Sep 12 14:13:16 <auth.crit> bm55 sshd[12335]:

Hello, I was searching for this information virtually everywhere, but as I couldn't find it - I'm asking here. I was wondering, why setting the Compression Level was removed in SSH2, and if on, is always set to 6. In SSH1 it was possible to set the Compression Level from 1 to 9. I have made some tests with Compression Levels using scp: SSH1, compression 9 (highest available for

On Solaris 8, I have ssh 3.1.0 and on other box Sol 7 I have 1.2.26 (min version for comtable with ssh 3), I checked also /etc/ssh2/sshd2_config file ## SSH1 compatibility # Ssh1Compatibility <set by configure by default> # Sshd1Path <set by configure by default 2) generate key for ssh3 # ssh-keygen2 -P /etc/ssh2/hostkey

Hi, I am trying to decide if it is worth the time to test the Kerberos support in a port I am working on of Openssh 3.5p1. Does using Kerb5 with SSH1 solve the security problems inherent in protocol 1 and bring it up to par with the security level of SSH2 or are there other issues that Kerb5 authentication won't help for SSH1? Thanks, Greg Lambert --------------------------------- Do

To allow easier targeting of users of old protocols I would find it useful for the syslog "Accepted" messages to be more uniform. 1. Include the string "ssh1" for ssh1 connections as is done for ssh2 connections. 2. Change the "publickey" message for ssh2 connections to specify which publickey, "dsa" or "rsa". This is already the case for

On Thu, Mar 26, 2015 at 11:55:18 -0700, Dan Kaminsky wrote: > You're right. My argument the is the next build of OpenSSH should be > OpenSSH 7, and the one after that 8, then 9, then 10. No minor releases? > Sure, go ahead. Deprecate the point, > > Do you manage any machines running SSHv1? > If by "running" you mean accepting SSH1, of course not. From a

Mr. Lindstrom, I am trying to upgrade from ssh1 to ssh2. I am getting the following error when I start sshd: Disabling protocol version 2. Could not load host key SSHD does start, however, ssh1 is functional, but ssh2 is not. Please advise, William 770-671-1888, ext-240 -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello. I've recently installed OpenSSH 2.5.1p1 over a working installation of 2.3.0p1 (both SSH1 and SSH2) and oddly enough I lost SSH2 support. The banner string states SSH-1.5-OpenSSH_2.5.1p1, which needless to say limits me to SSH1... I haven't yet bothered to check any conf files, but since I haven't really made any changes this behavior seems strange to me... Anyway, hope I'm

I have some Solaris 7 boxes (Ultra 3 and Ultra Enterprise 250 hardware) that I have compiled both 3.7p1 and 3.7.1p1 on and am having some problems. I am using the same "configure" options that I have in the past (without problems). I have tried both new and existing (previously working) ssh_config and sshd_config files. The new versions seem to have broken SSH 1 support (and

Hi All, When ss-keygen creates a private key, I guess it stores it in the private key file after encrypting it with the passphrase. What kind of encryption does ssh-keygen use for OpenSSH, SSH1 and SSH2? Another question: OpenSSH doesn't support all the ciphers of either SSh-1 or SSH-2? So I assume it doesn't work exhaustively with the SSH1 or SSH2 clients? Can we consider OpenSH as a

Hello, I have: SSH-1.5-OpenSSH_2.3.1p1 I find that this client displays error when I specify (from command line), '-c' [cipher] for SSH1. {for SSH2 looks okay}. Thus, if I specify: ./ssh -v -l user -c des -1 host or ./ssh -v -l user -c 3des -1 host I get error: bad cipher des [des] or error: bad cipher 3des [3des] respectively.... and client immediately exits ! But, this is okay:

I've recently upgraded some of my machines from an ssh1 environment to an openssh one, and consequently, I'm now using the ssh2 protocol. I can't seem to get it to allow remote logins without prompting for a passphrase or password. Is this possible? I've created id_dsa and id_rsa files etc., using ssh-keygen and have copied the public information to the remote authorized_keys

Hi, OpenSSH git master now disabled SSH protocol 1 at compile time by default. If you want it back, then you'll need to pass --with-ssh1 to configure before you build. We expect to ship this configuration for openssh-6.9 in a few months. -d

This is small patch for scp. It allows to force SSH1 or SSH2. P.S.: give me Cc: - I'm not subscribed... -- --------------------------------- pozdr. Pawe? Go?aszewski --------------------------------- R.I.P. - rest in pieces ... -------------- next part -------------- --- ./scp.c.org Sat Sep 8 23:37:22 2001 +++ ./scp.c Sun Sep 9 00:07:36 2001 @@ -244,9 +244,11 @@

I have just uploaded a new snapshot to: http://www.mindrot.org/misc/openssh/openssh-SNAP-20001114.tar.gz This snapshot includes Markus Friedl's new SSH2 RSA authentication work and -R portforwarding for SSH2. Please give these a good test. The new RSA authentications works similar to the current SSH2 DSA keys, but requires a little modification to config files. Currently RSA key cannot be

http://bugzilla.mindrot.org/show_bug.cgi?id=248 Summary: scp doesn't support ssh2 protocol Product: Portable OpenSSH Version: -current Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: liug

OpenSSH still has this feature, SSH-1.2.27 no longer has it. Admittedly it can be useful sometimes, even though I'd prefer this to be done using a trivial shell wrapper, which would be the UNIX way of doing things. Not being able to call OpenSSH's ssh by another name (say ``ssh1'') can get in the way when having to maintain two versions of ssh in parallel because the ``ssh ->

Hi! I was browsing through archives and found out that somebody else was having the same problem as I'm. http://bugzilla.mindrot.org/show_bug.cgi?id=248 from the client, when I run scp to the server, I get: scp: warning: Executing scp1 compatibility. scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in your PATH). There are more details about this problem here:

I have a curious problem connecting with OpenSSH (5.1p1 on FreeBSD, 6.0-beta on OpenBSD) to some managed switches running "IPSSH-6.6.0". When I connect to the switch with the SSH2 protocol, I can't use the switch's CLI, because I can't terminate a command line. I press <Enter> and nothing happens. Same for ^M (CR) and ^J (NL). When I connect to the switch with SSH1