Control: reassign -1 unison-2.53 2.53.3-2
Control: retitle -1 when receiving a SIGINT, unison should send it to the
process group, not just to ssh
A summary of the issue: I'm using a wrapper to ssh in order to
call ssh-add before the real ssh, when needed. When I run unison
and type Ctrl-C when
Control: retitle -1 openssh-client: Ctrl-C does not kill a ssh-add run from a
script
(No issues with ssh-add is run directly from the shell, see below.)
On 2023-09-22 12:18:24 +0200, Vincent Lefevre wrote:
> On 2023-09-22 12:10:19 +0200, Vincent Lefevre wrote:
> > On 2023-09-22 11:28
On 2023-09-22 12:10:19 +0200, Vincent Lefevre wrote:
> On 2023-09-22 11:28:12 +0200, Vincent Lefevre wrote:
> > It seems that that ssh command runs ssh-add automatically.
> > While I did a Ctrl-C to interrupt ssh started by unison (for
> > synchronization with a remote machin
On 2023-09-22 11:28:12 +0200, Vincent Lefevre wrote:
> It seems that that ssh command runs ssh-add automatically.
> While I did a Ctrl-C to interrupt ssh started by unison (for
> synchronization with a remote machine) from mutt, ssh-add is
> still running and attached to the termin
Package: openssh-client
Version: 1:9.4p1-1
Severity: important
It seems that that ssh command runs ssh-add automatically.
While I did a Ctrl-C to interrupt ssh started by unison (for
synchronization with a remote machine) from mutt, ssh-add is
still running and attached to the terminal:
UID
Package: openssh-server
Version: 1:9.1p1-1
Severity: minor
The "LOGIN PROCESS" section of the sshd(8) man page starts with
"When a user successfully logs in", but this is unclear. For instance,
at step 3: "Checks /etc/nologin; if it exists, prints contents and
quits (unless root)." But if it
Package: openssh-client
Version: 1:8.4p1-2
Severity: normal
I get the following:
zira:~> /usr/bin/ssh -vvv gcc202.fsffrance.org
OpenSSH_8.4p1 Debian-2, OpenSSL 1.1.1h 22 Sep 2020
[...]
debug1: Authentication succeeded (publickey).
Authenticated to gcc202.fsffrance.org ([195.170.63.224]:22).
On 2020-07-02 23:04:02 +0200, Christoph Anton Mitterer wrote:
> Directing the users to just set their locale on the remote .profile or
> using tricky with intermediate envvars is obviously also no real
> solution.
Note that using the remote .profile is not a solution as it is read
only by login
Package: openssh-client
Version: 1:8.0p1-3
Severity: important
After the upgrade to OpenSSH 8.0, my SSH sessions are not stable.
Either they completely freeze (with some servers, but using a
gateway), or I get a "client_loop: send disconnect: Broken pipe"
message (with this gateway and with
On 2017-12-11 13:25:54 +0100, Vincent Lefevre wrote:
> On 2017-12-11 13:14:55 +0100, Vincent Lefevre wrote:
> > The downgrade had no effect. But I've found the cause of the problem,
> > which is in OpenSSH. What happened in the following: after the
> > upgrade, I had to re
Control: reopen -1
Control: found -1 1:7.3p1-1
On 2016-08-07 22:48:14 +, Colin Watson wrote:
> Source: openssh
> Source-Version: 1:7.3p1-1
>
> We believe that the bug you reported is fixed in the latest version of
> openssh, which is due to be installed in the Debian FTP archive.
[...]
>
On 2015-12-09 15:18:44 +, Colin Watson wrote:
> On Wed, Dec 09, 2015 at 10:06:32AM +0100, Vincent Lefevre wrote:
> > This from is a SSH server for Android (and the user doesn't seem
> > to have a choice for the type of the host key).
>
> Please report this to the maint
Control: reassign -1 openssh-client 1:7.1p1-1
Control: severity -1 normal
Control: retitle -1 openssh-client: ssh complains on host key type even when
host key checking is disabled
On 2015-12-06 16:48:35 +0100, Vincent Lefevre wrote:
> Package: lftp
> Version: 4.6.3a-1+b1
> Severi
Control: found -1 1:6.9p1-2
On 2015-12-03 09:09:10 +0100, Vincent Lefevre wrote:
> No such problem with openssh 6.*.
I also get this error from another machine with openssh-client 1:6.9p1-2,
but randomly. When typing Ctrl-D, I either get:
Connection to ypig.lip.ens-lyon.fr closed by remote h
Package: openssh-client
Version: 1:7.1p1-1
Severity: minor
For some remote hosts, I get the following message after typing Ctrl-D
to end the session:
packet_write_wait: Connection to UNKNOWN: Broken pipe
For these hosts, I use the following ProxyCommand:
ProxyCommand ssh -W %h:%p ens
but I
On 2015-08-21 11:35:08 +0200, bgr...@toplitzer.net wrote:
According to [1] special crafted filenames containing control characters
can cause scp to execute commands in the current shell.
It cannot execute arbitrary shell commands (except if the terminal has
an extension to do that via escape
Control: reassign -1 openssh-client
(ssh is just a metapackage for both the client and the server,
and is not necessarily installed).
On 2015-06-04 22:35:08 +0100, Jasper Wallace wrote:
When trying to use ssh-agent-filter or ssh-add -c it's very handy to have
meaningfull comments on sshkeys so
Package: openssh-client
Version: 1:6.7p1-6
Severity: important
Tags: security
Forwarded: https://bugzilla.mindrot.org/show_bug.cgi?id=2434
I have reported the following bug upstream (I don't think it is
specific to Debian):
When outputting filenames to the terminal, scp doesn't filter out
On 2015-06-30 15:04:17 +0100, Stephane Chazelas wrote:
Or use luit that has been designed for that:
However it doesn't work from non-UTF-8 terminals.
From a UTF-8 terminal:
luit -encoding 'ISO 8859-1' ssh host-known-to-use-latin1
This is not very good, because the default encoding on the
On 2015-06-30 16:09:29 +0100, Stephane Chazelas wrote:
2015-06-30 16:45:59 +0200, Vincent Lefevre:
On 2015-06-30 15:04:17 +0100, Stephane Chazelas wrote:
From a UTF-8 terminal:
luit -encoding 'ISO 8859-1' ssh host-known-to-use-latin1
This is not very good, because the default
On 2015-06-30 05:35:16 +0200, Christoph Anton Mitterer wrote:
On Tue, 2015-06-30 at 04:30 +0200, Vincent Lefevre wrote:
Well but there one knows / must assume at least that this can
happen:
When one remotely accesses a system and processes output from
there, it
must be assumed
On 2015-06-29 05:43:07 +0200, Christoph Anton Mitterer wrote:
We've had the same discussion last time when it was about LC_*.
It's generally a bad idea to change the secure default of not
forwarding/accepting anything.
I completely disagree that passing XTERM_VERSION is not secure
(this RFE
On 2015-06-29 22:50:59 +0200, Christoph Anton Mitterer wrote:
On Mon, 2015-06-29 at 20:55 +0100, Stephane Chazelas wrote:
Note that LANG/LC_* which Debian ssh already accepts is probably one
of the worst one as it affects so many commands. That also
affects bash shell grammar parsing which
On 2015-06-30 02:53:23 +0200, Christoph Anton Mitterer wrote:
On Tue, 2015-06-30 at 01:23 +0200, Vincent Lefevre wrote:
On the other hand, having the wrong charmap on the other side is a
security issue, because remote utilities could send characters that
they think to be printable
Source: openssh
Version: 1:6.7p1-6
Severity: wishlist
Passing the terminal version to the server side is useful for programs
that depend on some terminal features (for instance, to make sure that
some query escape sequence will receive an answer).
In the case of xterm, it is provided by
On 2015-03-23 01:09:33 +0100, Christoph Anton Mitterer wrote:
Maybe I've missed that since the discussion got quite long, but I don't
remember that Vincent actually explained what broke (i.e. I know nothing
that would use LC_CHARMAP or CODPAGE?)... and the others rather just
complained about
On 2015-03-23 01:19:17 +0100, Christoph Anton Mitterer wrote:
Again, I don't see that Vincent wrote that this is a complete
showstopper for him... even his bug title was about the modification of
the config file, not about the new value itself.
The new value is a problem too, but I can modify
On 2015-03-22 04:23:33 +0100, Christoph Anton Mitterer wrote:
On Sun, 2015-03-22 at 03:00 +0100, Vincent Lefevre wrote:
Bad example. The Firefox profile is not a config file.
Why not? it contains all my about:config settings, my bookmarks, etc.
It contains more than things related
On 2015-03-19 23:44:00 +0100, Christoph Anton Mitterer wrote:
On Thu, 2015-03-19 at 23:37 +0100, Vincent Lefevre wrote:
BTW, it's also annoying that the user can no longer pass env variables
(e.g. the charset) to the remote side for machines where the admin
just uses Debian's default
On 2015-03-19 19:02:14 +, Colin Watson wrote:
On Thu, Mar 19, 2015 at 07:18:38PM +0100, Christoph Anton Mitterer wrote:
and/or
- the migration been managed via e.g. debconf (and the user been
interactively asked)
Absolutely not. This is not a reasonable question to ask most users
On 2015-03-20 00:09:48 +0100, Christoph Anton Mitterer wrote:
On Thu, 2015-03-19 at 23:58 +0100, Vincent Lefevre wrote:
But at least the user could use non-standard (thus unused by the
system) variables to pass information to the remote side (in my case,
I used LC_CHARMAP). After
On 2015-03-19 16:31:22 +, Colin Watson wrote:
What did the file look like before this upgrade?
I've attached the file with some settings hidden (the AllowUsers line
was at least modified, as I just put local users).
--
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100%
On 2015-03-20 01:44:06 +0100, Christoph Anton Mitterer wrote:
On Fri, 2015-03-20 at 00:46 +0100, Vincent Lefevre wrote:
The fact is that Debian doesn't use non-standard LC_* variables.
People may run *any* software, including their own homebrewed stuff.
So, it's even easier: when the admin
Package: openssh-server
Version: 1:6.7p1-4
Severity: serious
I made local changes to the /etc/ssh/sshd_config file, and the
openssh-server modified this file, breaking my configuration.
I now have:
AcceptEnv LANG LC_ADDRESS LC_COLLATE LC_CTYPE LC_IDENTIFICATION LC_MEASUREMENT
LC_MESSAGES
Package: openssh-sftp-server
Version: 1:6.5p1-5
Severity: serious
Justification: Policy 7.6.1
Unpacking openssh-sftp-server (1:6.5p1-5) ...
dpkg: error processing archive
/var/cache/apt/archives/openssh-sftp-server_1%3a6.5p1-5_amd64.deb (--unpack):
trying to overwrite
On 2014-02-12 11:23:56 +, Colin Watson wrote:
On Wed, Feb 12, 2014 at 03:32:06AM +0100, Marco d'Itri wrote:
getsockname failed: Bad file descriptor
Thanks - tracked down a little and forwarded as
https://bugzilla.mindrot.org/show_bug.cgi?id=2200.
I also get this error between two
Package: openssh-client
Version: 1:6.4p1-1
Severity: wishlist
I got the following error with a svn command:
OpenSSL version mismatch. Built against 1000105f, you have 10001060
svn: E210002: Unable to connect to a repository at URL 'svn+ssh://mysvn'
svn: E210002: To better debug SSH connection
Control: reassign -1 openssh-client
Control: merge 732940 -1
Control: found -1 1:6.4p1-1
On 2013-12-23 01:31:43 +0100, Vincent Lefevre wrote:
Actually, that's ssh this new libssl1.0.0 version breaks, not svn
(svn as a consequence).
and that's the same bug as 732940.
--
Vincent Lefèvre vinc
Package: openssh-client
Version: 1:6.2p2-3
Severity: important
There's a regression in openssh-client. I can no longer connect to
some account.
In particular, I have the following in my .ssh/config file:
IdentityFile ~/.ssh/id_rsa-internal
IdentityFile ~/.ssh/id_rsa
Host ens ssh.ens-lyon.fr
On 2005-12-31 16:05:59 +, Colin Watson wrote:
Recent versions of the Linux kernel support an IUTF8 flag (see
http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod) which allows the
character-erase function in cooked mode to handle UTF-8 characters
correctly. I would like to allow this mode to be
found 351489 1:5.9p1-1
thanks
On 2006-02-05 03:23:42 -0500, Justin Pryzby wrote:
But it doesn't work when transferring between distinct remote hosts:
scp justinpryzby.com:s.php cyberia.stlawu.edu:/tmp
scp -v indicates that authentication is successful for j/p.com, but
fails for cyberia.
Package: openssh-client
Version: 1:5.5p1-4
Severity: normal
Until the master was restarted, the ssh connection was freezing:
$ strace -f -o strace.out ssh -vvv gforge
OpenSSH_5.5p1 Debian-4, OpenSSL 0.9.8n 24 Mar 2010
debug1: Reading configuration data /home/vinc17/.ssh/config
debug1:
Package: openssh-client
Version: 1:5.3p1-3
Severity: wishlist
The SendEnv directive is particular in the fact that it cannot be
overriden, and the feature is documented. Indeed the ssh_config(5)
man page says:
SendEnv
Specifies what variables from the local environ(7)
Package: openssh-client
Version: 1:5.3p1-3
Severity: minor
The ssh_config(5) man page says:
For each parameter, the first obtained value will be used.
but this doesn't apply to SendEnv. It should say:
For each parameter, the first obtained value will be used,
unless specified otherwise.
Package: openssh-client
Version: 1:5.3p1-2
Severity: wishlist
ssh outputs messages to the terminal after other processes have
been started on the server side. As ssh doesn't write its name
and it isn't the only process, it may be difficult to know where
messages like that come from.
For
Package: openssh
Version: 1:5.3p1-2
Severity: minor
It seems that by default (i.e. without -t or -T ssh option), tty
allocation is done only when one doesn't provide a command. If
the user provides a command, no tty allocation occurs by default:
ypig:~ ssh localhost echo \$TERM
ypig:~ ssh -t
severity 506115 grave
thanks
On 2008-11-18 22:44:02 +0900, Hideki Yamane wrote:
package: openssh
servity: grave
I assume this is a typo (severity, not servity).
--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog:
Package: openssh-client
Version: 1:5.1p1-1
Severity: grave
(Setting to grave because this is a serious regression that prevents
from using ssh with some hosts without any workaround and this bug
must be fixed before lenny is released.)
For a host for which I have a ProxyCommand:
vin:~ echo
On 2008-06-04 16:59:09 +0200, Raphael Hertzog wrote:
non-default because ssh-keygen does generate 2048 bits keys for
RSA by default since quite some time and the postinst doesn't
give an explicit size when it creates the keys.
openssh (1:4.2p1-1) unstable; urgency=low
[...]
- Increase
severity 481860 normal
thanks
On 2008-06-05 14:33:55 +0200, Raphael Hertzog wrote:
On Thu, 05 Jun 2008, Vincent Lefevre wrote:
I installed the machine on 2008-01-30 (from a CD) then upgraded
to sid. The dpkg log says concerning the upgrades:
What CD? An Etch CD?
Sorry, I mixed up
Package: openssh-client
Version: 1:4.7p1-9
Severity: important
First, the blacklists from testing don't contain all vulnerable keys
used in practice: one needs openssh-blacklist-extra, which exists
only in sid. But ssh-vulnkey from the lenny's openssh-client package
can't find these blacklists:
On 2008-05-19 10:35:58 +0200, Vincent Lefevre wrote:
On 2008-05-19 07:26:29 +0100, Colin Watson wrote:
On Mon, May 19, 2008 at 04:28:46AM +0200, Vincent Lefevre wrote:
When I upgraded openssh-server, ssh_host_dsa_key has been replaced
because it was compromised, but not ssh_host_rsa_key
On 2008-05-19 07:26:29 +0100, Colin Watson wrote:
On Mon, May 19, 2008 at 04:28:46AM +0200, Vincent Lefevre wrote:
When I upgraded openssh-server, ssh_host_dsa_key has been replaced
because it was compromised, but not ssh_host_rsa_key, but this one
was compromised too!
What does 'grep -i
Package: openssh-server
Version: 1:4.7p1-10
Severity: grave
Tags: security
Justification: user security hole
When I upgraded openssh-server, ssh_host_dsa_key has been replaced
because it was compromised, but not ssh_host_rsa_key, but this one
was compromised too!
$ ll /etc/ssh
-rw-r--r-- 1 root
On 2008-05-11 21:00:55 -0500, Nicolas Williams wrote:
On Mon, May 12, 2008 at 02:00:56AM +0200, Vincent Lefevre wrote:
default one at the system level. Perhaps you mean that the SSH client
should propagate the locale (more precisely, the charmap) to the
SunSSH 1.1 does (by having
On 2008-05-12 09:35:46 -0500, Nicolas Williams wrote:
What if the user reads three languages and doesn't know which the remote
server has localizations for? What if the user doesn't have dot files
on the server?
There's also the problem that if the user shell is bash, the .bashrc
(or
On 2006-01-02 18:20:50 -0500, Jeffrey Hutzelman wrote:
One could argue that an SSH server running on such a system should look
at the configured locale and configure the PTY appropriately, and that's
probably even a good idea.
What configured locale? The user may use a locale which is not
Package: openssh
Severity: normal
When I do a ssh from a terminal with IUTF8 flag set, this flag is
no longer set on the other side. The easiest way to test this is
to do a ssh to localhost.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500,
On 2005-11-02 18:13:32 +, Colin Watson wrote:
Sorry, I'm not familiar with the IUTF8 flag; as far as I know, the
terminal emulator I generally use (pterm) doesn't support it. What
terminal are you using?
xterm, with the patch I posted here:
Package: openssh-client
Version: 1:4.2p1-5
Severity: wishlist
The OpenSSH client should have an option to open an independent master
connection automatically when there isn't one already, and close it
when the last slave ssh connection closes.
The problem with ControlMaster auto is that closing
On 2005-10-25 15:39:40 +0200, Vincent Lefevre wrote:
The OpenSSH client should have an option to open an independent master
connection automatically when there isn't one already, and close it
when the last slave ssh connection closes.
The problem with ControlMaster auto is that closing
Package: openssh-client
Version: 1:4.1p1-6
Severity: wishlist
When pasting text containing a newline followed by a tilde, the tilde
is interpreted as an escape character. The ssh client should provide a
way so that the escape character is interpreted as a normal character
when the delay between
Package: ssh
Version: 1:3.8.1p1-8
Severity: normal
The -l option of scp is useful so that not all the available bandwidth
is taken by scp. Thus, when compression is enabled, it should be the
bandwidth limit on the compressed data (i.e. data that will really be
sent).
Currently, this is not the
Package: ssh
Version: 1:3.8.1p1-4
Severity: normal
When stderr is redirected (e.g. for filtering), the scp progress meter
doesn't appear on the terminal (in fact, neither on the tty, nor in
stderr). There's no reason to disable it in this case, therefore this
is a bug.
-- System Information:
severity 243012 normal
retitle 243012 Confusing error message when the server closed the connection
thanks
On 2004-05-04 10:49:51 +0200, Vincent Lefevre wrote:
So, I suppose that the Bad packet length may be due to the fact
that the connection was being closed by the server, i.e. it may
On 2004-04-30 03:43:38 +0200, Vincent Lefevre wrote:
Also, I could notice that all the ssh sessions where data were
transmitted are closed at the same time when the problem occurs
(e.g. 2004-04-29 12:38:25). Sleeping connections (where no data
transmissions occur at this time, because
On 2004-04-15 01:35:52 +0100, Colin Watson wrote:
On Thu, Apr 15, 2004 at 02:09:36AM +0200, Vincent Lefevre wrote:
My ssh connections close after being idle for 10 minutes exactly.
Seems more likely to be a network problem (e.g. NAT timeout) at your
client end than anything else, as it's
Package: ssh
Version: 1:3.8p1-3
Severity: normal
My ssh connections close after being idle for 10 minutes exactly.
For instance:
ay:~ ssh -vvv loria 1:49:15
OpenSSH_3.8p1 Debian 1:3.8p1-3, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar
2004
On 2004-04-10 12:08:22 +0200, Vincent Lefevre wrote:
I have no problem starting ssh connections, but after some time
(several hours), ssh closes the connection with an error like:
Disconnecting: Bad packet length 4138966086.
Well, this seems to occur only in sessions where a program
Package: ssh
Version: 1:3.8p1-3
Severity: important
I have no problem starting ssh connections, but after some time
(several hours), ssh closes the connection with an error like:
Disconnecting: Bad packet length 4138966086.
Well, this seems to occur only in sessions where a program is sending
On 2004-01-13 22:09:53 +, Colin Watson wrote:
That's strange. I can't find that message anywhere in the openssh
source code ...
for i in /usr/bin/*; strings -a $i|grep No value for echo $i
said that this comes from /usr/bin/tput, called from my .zshenv.
I've just reported a wishlist bug
On 2004-01-14 00:21:45 +, Colin Watson wrote:
On Wed, Jan 14, 2004 at 12:00:46AM +0100, Vincent Lefevre wrote:
Concerning ssh, why isn't TERM passed to the remote side? IMHO, this
would make sense and would be very useful. This is just the opposite
of rlogin, which passes TERM
72 matches
Mail list logo
