headers
Scott Neugroschl | 1 Sep 2009 01:43

mput/mget misbehavior

A couple of notes about mget/mput in SFTP (5.1p1).

1.  They aren't documented in the SFTP man page
2   They misbehave --
        "mput a.txt b.txt"  copies a.txt to b.txt on the server
        "mput *.txt b.txt"  copies the first wildcard match to b.txt on
the server
        "mput a.txt b.txt c.txt"  copies a.txt to b.txt on the server
        "mput a.txt b.txt /tmp"   copies a.txt to b.txt on the server

----
Scott Neugroschl
XYPRO Technology Corporation
scott_n <at> xypro.com
805-583-2874
Permalink | Reply | 1 comment |
headers
Damien Miller | 1 Sep 2009 02:18
Favicon

Re: mput/mget misbehavior

this will be changing soon: there are some patches coming from Carlos Silva,
our Google Summer of Code Intern.

-d

On Mon, 31 Aug 2009, Scott Neugroschl wrote:

> A couple of notes about mget/mput in SFTP (5.1p1).
> 
> 1.  They aren't documented in the SFTP man page
> 2   They misbehave --
>         "mput a.txt b.txt"  copies a.txt to b.txt on the server
>         "mput *.txt b.txt"  copies the first wildcard match to b.txt on
> the server
>         "mput a.txt b.txt c.txt"  copies a.txt to b.txt on the server
>         "mput a.txt b.txt /tmp"   copies a.txt to b.txt on the server
> 
> 
> 
> ----
> Scott Neugroschl
> XYPRO Technology Corporation
> scott_n <at> xypro.com
> 805-583-2874
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev <at> mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
petesea | 2 Sep 2009 01:51
Picon

ssh_exchange_identification: Connection closed by remote host

I'm randomly getting the following error on a server from various remote 
hosts:

   ssh_exchange_identification: Connection closed by remote host

The server is running OpenSSH 4.5p1 w/GSSAPI Key Exchange patch.  The 
hosts connecting to it should all be using OpenSSH 5.0p1 w/GSSAPI Key 
Exchange patch and using gssapi-keyex authentication.

Normally, when I've seen this error, it means access to the SSH port is 
blocked by TCP wrappers or something like that, but I'm sure that's not 
the case here since /etc/hosts.allow and /etc/hosts.deny haven't changed 
for quite some time.  Also, the failures are random from many different 
remote hosts and I can try a connection from a host right after it's 
failed and it will work.

Under what other conditions might I get this error and how can I track 
down what's causing it?
Permalink | Reply | 1 comment |
headers
Tim Rice | 2 Sep 2009 06:36
Favicon

Re: ssh_exchange_identification: Connection closed by remote host

On Tue, 1 Sep 2009, petesea <at> bigfoot.com wrote:

> I'm randomly getting the following error on a server from various remote
> hosts:
> 
>   ssh_exchange_identification: Connection closed by remote host
> 
> The server is running OpenSSH 4.5p1 w/GSSAPI Key Exchange patch.  The hosts
> connecting to it should all be using OpenSSH 5.0p1 w/GSSAPI Key Exchange patch
> and using gssapi-keyex authentication.
> 
> Normally, when I've seen this error, it means access to the SSH port is
> blocked by TCP wrappers or something like that, but I'm sure that's not the
> case here since /etc/hosts.allow and /etc/hosts.deny haven't changed for quite
> some time.  Also, the failures are random from many different remote hosts and
> I can try a connection from a host right after it's failed and it will work.

I've seen this with DNS failures when my hosts.allow entry is a domain
rather than an IP.

> Under what other conditions might I get this error and how can I track down
> what's causing it?

--

-- 
Tim Rice				Multitalents	(707) 887-1469
tim <at> multitalents.net
Permalink | Reply | 0 comments |
headers
Jamie Beverly | 2 Sep 2009 07:24
Picon
Favicon

Re: ssh_exchange_identification: Connection closed by remote host

I frequently see this error when / goes away, e.g. hdd failure.

Sent from my iPhone

On Sep 1, 2009, at 9:36 PM, Tim Rice <tim <at> multitalents.net> wrote:

On Tue, 1 Sep 2009, petesea <at> bigfoot.com wrote:

I'm randomly getting the following error on a server from various remote
hosts:

 ssh_exchange_identification: Connection closed by remote host

The server is running OpenSSH 4.5p1 w/GSSAPI Key Exchange patch.  The hosts
connecting to it should all be using OpenSSH 5.0p1 w/GSSAPI Key Exchange patch
and using gssapi-keyex authentication.

Normally, when I've seen this error, it means access to the SSH port is
blocked by TCP wrappers or something like that, but I'm sure that's not the
case here since /etc/hosts.allow and /etc/hosts.deny haven't changed for quite
some time.  Also, the failures are random from many different remote hosts and
I can try a connection from a host right after it's failed and it will work.

I've seen this with DNS failures when my hosts.allow entry is a domain
rather than an IP.

Under what other conditions might I get this error and how can I track down
what's causing it?

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Allen | 4 Sep 2009 15:46
Picon
Picon

Re: PermitUserEnvironment in sshd match block?

Daniel Allen wrote:

 > Would the best answer be a patch that adds PermitUserEnvironment  
support
 > inside match blocks?

Darren Tucker wrote:

 > The approach to adding things to Match has been on a case by case  
basis,
 > checking if the thing is a) useful and b) safe.  It's a lot easier to
 > evaluate these thing one at a time than in a large batch of them.

Damien Miller wrote:

 > We could make PermitUserEnvironment accept a pattern-list to match
 > environment variables, while retaining "yes", "no", "true" and  
"false"
 > as their current meanings of allow/deny-all.

Both (or either) of these options would meet our current needs very  
well.  The pattern-list would seem the more elegant approach for our  
use.  I am sorry that I don't have the wherewithal to submit a patch  
now, though if it helps things along I'd be happy to submit a bugzilla  
request.  Or not, if you prefer.

Thanks for your work,
Daniel Allen

Computing Technology Specialist
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Stuge | 4 Sep 2009 16:13
Picon

Re: PermitUserEnvironment in sshd match block?

Daniel Allen wrote:
> Our campus environment would find it very useful to pass
> user-environment variables for certain login ssh connections,

I guess it's arbitrary variables? If only a limited set you could
sprinkle some AcceptEnv into sshd_config.

//Peter
Permalink | Reply | 8 comments |
headers
Damien Miller | 4 Sep 2009 22:13
Favicon

Re: PermitUserEnvironment in sshd match block?

On Fri, 4 Sep 2009, Peter Stuge wrote:

> Daniel Allen wrote:
> > Our campus environment would find it very useful to pass
> > user-environment variables for certain login ssh connections,
> 
> I guess it's arbitrary variables? If only a limited set you could
> sprinkle some AcceptEnv into sshd_config.

AcceptEnv only applies to environment variables passed by the ssh(1)
client, not to ~/.ssh/environment.

-d
Permalink | Reply | 0 comments |
headers
lauri | 6 Sep 2009 17:53
Picon
Gravatar

Integration of streamlocal patch

Hello,

there is a patch which allows redirecting UNIX domain sockets here:

http://www.25thandclement.com/~william/projects/streamlocal.html<http://www.25thandclement.com/%7Ewilliam/projects/streamlocal.html>

We really need it in our institution.
It's for OpenSSH 4.4 but I managed to adopt it for 4.7p1 included in Ubuntu
8.04.

http://v6sa.itcollege.ee/shared/patches/openssh-4.7p1-streamlocal-20090831-v6sa-for-ubuntu-8.04.patch

It would be very nice if you guys would integrate it upstream.

--

-- 
Lauri Võsandi
tel: +372 53329412
e-mail: lauri.vosandi <at> gmail.com
university: Estonian IT College
please share: http://windows7sins.org/
Permalink | Reply | 1 comment |
headers
Steeve BARBEAU | 8 Sep 2009 00:08
Picon
Favicon

Question about Server Authentication


Hi guys,

I'm working on a project which concern SSH and there is something i don't understand about server
authentication. So I explain my problem:

- When you authorize only RSA keys in the sshd_config on the server, you need to have the RSA public key of this
server in the known_hosts file of the client. This is absolutely normal.

- When you authorize only DSA keys in the sshd_config on the server, you need to have the DSA public key of this
server in the known_hosts file of the client. This is also absolutely normal.

- But when you authorize both RSA and DSA keys, you are obliged to have the RSA public key in the known_hosts
file, without it fails. If there is only DSA in the known_hosts file it fails, and this is that I don't
understand. Why the server authentication doesn't work with the DSA key when both DSA and RSA are
authorize. (Of course if both are present in the known_host file, it works). So if somebody can help me
about this, it will be nice ;)
I've read lot of documentation, a little the 4 RFC but I haven't found the answer to my question.

Steeve
Permalink | Reply | 9 comments |

Gmane