Multiple commenters (#19, #43) have posted the workaround. In my
~/ssh/.config I now have
Host *
# Workaround for the dreaded 'connection reset by peer' bug, openssh >=5.7:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
and I no longer see this problem.
--
You received this bug notification because
Confirmed that this is broken again in Lucid, and I agree with yota:
the purpose of /etc/default/* is to provide supported ways for
administrators to modify services' behavior without having to modify
their startup scripts. It's a regression to stop supporting
/etc/default/ssh.
--
X11 forwarding
Also, the revised workaround in #20 does not work for me. I edited
/etc/init/ssh.conf as suggested, then ran
initctl reload-configuration
restart ssh
but for some reason the -4 parameter isn't taking effect. ps shows sshd
running as just /usr/sbin/sshd with no argument, netstat shows sshd
liste
Setting
AddressFamily inet
in /etc/ssh/sshd_config and restarting sshd does work around this
problem.
** Description changed:
I had a proper configuration on jaunty (sshd_config) so I could ssh into
that machine and run X11 applications there with X11 forwarding, so I
could use apps from
Can anyone else confirm that #20 does not work for them? That is, if
you do the following:
* remove "AddressFamily inet" from sshd_config
* add "-4" after "exec /usr/sbin/sshd" in /etc/init/ssh/conf
* run
initctl reload-configuration
restart sshd
then do you still have this problem? Does
pgr
yota, you're correct. stop + start > restart. So #20 does also work
for me now. Thanks, Andrew.
--
X11 forwarding via SSH does not work after upgrade to karmic
https://bugs.launchpad.net/bugs/434799
You received this bug notification because you are a member of Ubuntu
Server Team, which is sub
Public bug reported:
I just upgraded from Lucid to Maverick, and now slapd won't start. From
syslog:
Oct 11 06:10:31 helium slapd[12130]: @(#) $OpenLDAP: slapd 2.4.23 (Aug 7 2010
01:39:36)
$#012#011bui...@yellow:/build/buildd/openldap-2.4.23/debian/build/servers/slapd
Oct 11 06:10:32 helium s
** Attachment added: "Dependencies.txt"
https://bugs.launchpad.net/bugs/658227/+attachment/1684127/+files/Dependencies.txt
--
won't start after Maverick upgrade; bdb "Program version 4.8 doesn't match
environment version 4.7"
https://bugs.launchpad.net/bugs/658227
You received this bug noti
This appears to be the same as http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=595672 . A fix appears to have been released to
that, but again I don't understand the cause or solution, or what I
should do to recover at this point.
** Bug watch added: Debian Bug tracker #595672
http://bugs.d
OK, per https://bbs.archlinux.org/viewtopic.php?id=84077 and then
http://dbaspot.com/forums/berkeley-db/265933-how-upgrade-4-2-4-3-a.html,
I installed db4.7-utils and ran
cd /var/lib
cp -a ldap ldap.bak
cd ldap
db4.7_checkpoint -1
db4.7_recover
After that, slapd started normally.
--
won't start
Here are excerpts from apt/term.log. Note that this is in a different
apt log because my dist-upgrade was a little unusual - interrupted, then
completed in a second session. I'm attaching the complete apt log file
in case it's of interest.
Log started: 2010-10-11 03:59:04
Restarting services p
Yay!
Thanks guys, that was fast work.
--
upgrade process does not upgrade underlying BDB format from 4.7 to 4.8 (so
slapd aborts with "Program version 4.8 doesn't match environment version 4.7"
error message)
https://bugs.launchpad.net/bugs/658227
You received this bug notification because you
This is definitely a bug, and a serious one. On a new installation of
slapd, there is no apparent way to set the admin password!
** Changed in: openldap (Ubuntu)
Status: Invalid => New
--
dpkg-reconfigure slapd does not let enter password
https://bugs.launchpad.net/bugs/495306
You receiv
Public bug reported:
Binary package hint: openssh-client
ssh X11 forwarding to my intrepid client from my openssh server used to
work, but it always fails now, with "Invalid MIT-MAGIC-COOKIE". Please
see the example session log below.
Forwarding succeeds to a Windows client running PuTTY, so th
Bernie, thanks. You are correct, XAuthLocation wasn't correctly set,
and this was the cause of the problem.
I didn't set XAuthLocation at all, so ssh used the default value, which
ssh_config(5) says is /usr/bin/X11/xauth. But in Ubuntu xauth is
/usr/bin/xauth. Setting XAuthLocation /usr/bin/xau
OK. Yes, AFAIK it's properly installed. Still, I just ran 'apt-get
--reinstall install x11-common', and that recreated the symlink, which
will solve the problem. Not sure why the symlink was missing in the
first place.
So this is a solution to this bug. I guess the bug should be closed,
althou
16 matches
Mail list logo