Thread: Connection closed by server with exitcode 1
Brought to you by:
xystrus
Menu
▾
▴
rssh-discuss
|
From: Zachary B. <zbu...@gm...> - 2011-12-05 16:57:38
|
RHEL just updated its rssh package on last Wednesday (at least that's when Rackspace upgraded our server) and it appears to have broken something. When attempting to connect via FileZilla, I get the following (logging turned up to Debug): Command: open "us...@ho..." 22 Trace: Server version: SSH-2.0-OpenSSH_4.3 Trace: Using SSH protocol version 2 Trace: We claim version: SSH-2.0-PuTTY_Local:_Nov__8_2011_21:41:54 Trace: Doing Diffie-Hellman group exchange Trace: Doing Diffie-Hellman key exchange with hash SHA-1 Trace: Host key fingerprint is: Trace: ssh-rsa 2048 e4:0b:2b:90:84:55:b4:07:5a:f4:99:e9:a9:b3:75:c4 Trace: Initialised AES-256 SDCTR client->server encryption Trace: Initialised HMAC-SHA1 client->server MAC algorithm Trace: Initialised AES-256 SDCTR server->client encryption Trace: Initialised HMAC-SHA1 server->client MAC algorithm Trace: Pageant is running. Requesting keys. Trace: Pageant has 1 SSH-2 keys Trace: Successfully loaded 1 key pair from file Trace: Trying Pageant key #0 Trace: Server refused public key Trace: Offered public key from "/Users/user/id_rsa.ppk" Trace: Server refused public key Command: Pass: *********** Trace: Sent password Trace: Access granted Trace: Opened channel for session Trace: Started a shell/command Trace: Server sent command exit status 1 Status: Connected to host.com Error: Connection closed by server with exitcode 1 Trace: CControlSocket::DoClose(64) Trace: CSftpControlSocket::ResetOperation(66) Trace: CControlSocket::ResetOperation(66) Error: Could not connect to server Trace: CFileZillaEnginePrivate::ResetOperation(66) And in the server - side secure log I only have the following: Dec 5 11:33:08 webhost sshd[5551]: Accepted password for user from xxx.xxx.xxx.xxx port 62567 ssh2 Dec 5 11:33:08 webhost sshd[5551]: pam_unix(sshd:session): session opened for user lansing by (uid=0) Dec 5 11:33:08 webhost sshd[5555]: subsystem request for sftp Dec 5 11:33:08 webhost sshd[5551]: pam_unix(sshd:session): session closed for user lansing No further information and nothing in the syslog from rssh. What else can I check? This is rssh 2.3.3 . |
|
From: Werner F. <wer...@uf...> - 2011-12-23 15:50:29
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Zachary Burnham [05.12.2011 17:57]:
> RHEL just updated its rssh package on last Wednesday (at least
> that's when Rackspace upgraded our server) and it appears to have
> broken something.
>
> When attempting to connect via FileZilla, I get the following
> (logging turned up to Debug):
[...]
>
> And in the server - side secure log I only have the following:
>
> Dec 5 11:33:08 webhost sshd[5551]: Accepted password for user
> from xxx.xxx.xxx.xxx port 62567 ssh2 Dec 5 11:33:08 webhost
> sshd[5551]: pam_unix(sshd:session): session opened for user lansing
> by (uid=0) Dec 5 11:33:08 webhost sshd[5555]: subsystem request
> for sftp Dec 5 11:33:08 webhost sshd[5551]:
> pam_unix(sshd:session): session closed for user lansing
>
> No further information and nothing in the syslog from rssh. What
> else can I check? This is rssh 2.3.3 .
I have this even without using rssh, so it may not be related. This
occurs when ~/.ssh and its contents have wrong owners or rights, or
when the shell profiles have wrong owner/rights, or whenever sshd
thinks something is wrong. At least the latter is my guess...
For me, when I try to authenticate via key, there is no chance to
enter a password if the key is wrong ("Server refused public key"). I
tried to debug with "ssh -vvv ...", and found the wrong owner of
~/.bash_profile, but still have a problem with another user.
Cheers,
Werner
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk70mw4ACgkQk33Krq8b42OSxACfQ+6ccA1DhJINvU/gwMijGQAX
0qQAn0SROyixNP/rwmOdML2TfpfASUEA
=VCLw
-----END PGP SIGNATURE-----
|
|
From: Werner F. <wer...@uf...> - 2011-12-25 08:44:37
|
Am 25.12.2011 04:37, schrieb Aurelin:
>> I have this even without using rssh, so it may not be related. This
>> occurs when ~/.ssh and its contents have wrong owners or rights, or
>> when the shell profiles have wrong owner/rights, or whenever sshd
>> thinks something is wrong. At least the latter is my guess...
> This is a possibility. You may not have some of the files with 777
> permissions in ~/.ssh/, and I _think_ it's the same for the directory.
> Can't tell it by heart now. It's also true that a wrong owner will make
> ssh go failing.
There is no file with 777 permissions in .ssh. I am not mad, you know?
;-) The rights of the directory itself, and most of its content, must be
0600. Only the public keys should be world readable. And everything must
belong to the right owner.
There is no problem with that. But why doesn't sshd tell me in its log
the reason for closing the connection? Why do I have to resort to "ssh
-vvv" to discover it?
>>
>> For me, when I try to authenticate via key, there is no chance to
>> enter a password if the key is wrong ("Server refused public key"). I
>> tried to debug with "ssh -vvv ...", and found the wrong owner of
>> ~/.bash_profile, but still have a problem with another user.
>>
> When you've got the wrong key, ssh will fail. It could be that, if you
> have 4 keys in your file and only the 4th is ok, ssh will fail to. There
> is a setting in sshd_conf (I suppose it's there) that tells the server
> how any times he shall try. If it's told to try 3 times, it will fail
> after figuring out that the first 3 keys used by the client are wrong,
> _even though the user had a password that would match_!
> Check this setting and change it or rearrange the order of the keys or
> unload them, if this thing is the case.
I give one key. And I allow logon via password. I know from older
versions of ssh, that the password was asked after thze key failed. At
least with the RH 6 servers, this is not the case any more.
>
> I had this problem when I had a user a wanting to log in as user b on a
> server. When user a connected to the server as b, the server said "Wrong
> public key" because the first 3 keys didn't match (since they were for
> different connections..).
In my user a's ~./.ssh/config, there is exactly one key per server. And
this key is used.
> It is the same with ESX where I had the problem that ESX found out I was
> using Private/Public-Key login in general.
> It then failed when I tried to log in via ILO, because I had 3 keys
> loaded and none of them was ok (obviously.. I never have a root-key for
> ILO-login..)
> Solution was to unload all keys (which made it possible to login with a
> password).
Another possibility is to use a ~./.ssh/config with correct definitions ;-)
And please don't PM me as a response to a list posting. Thank you.
Best Regards,
Werner
|
|
From: Nico Kadel-G. <nk...@gm...> - 2011-12-25 16:03:31
|
On Sun, Dec 25, 2011 at 3:44 AM, Werner Flamme <wer...@uf...> wrote:
> Am 25.12.2011 04:37, schrieb Aurelin:
>
>>> I have this even without using rssh, so it may not be related. This
>>> occurs when ~/.ssh and its contents have wrong owners or rights, or
>>> when the shell profiles have wrong owner/rights, or whenever sshd
>>> thinks something is wrong. At least the latter is my guess...
>> This is a possibility. You may not have some of the files with 777
>> permissions in ~/.ssh/, and I _think_ it's the same for the directory.
>> Can't tell it by heart now. It's also true that a wrong owner will make
>> ssh go failing.
>
> There is no file with 777 permissions in .ssh. I am not mad, you know?
> ;-) The rights of the directory itself, and most of its content, must be
> 0600. Only the public keys should be world readable. And everything must
> belong to the right owner.
This is incorrect. flatly incorrect.
The typical permissions are:
$HOME/. 0700 (or possibly 0775, tastes vary and other settings can
work, write permission is *optional*)
$HOME/.ssh 0700 (or possibly 0750, again, tastes can vary and other
settings in between can work, write permission is *optional*)
"others" should not have access to this
$HOME/.ssh/authorized_keys 0600 (or possibly 0400, tastes vary)
*No one else*, either group members or "other", should have access
to this file.
Private keys can be stored however the heck you want them. SSH clients
*do not care*, and they can be anywhere you want with whatever
permissions you want, including $HOME/.ssh/privatekey with permissions
7777 if you feel like it.
> There is no problem with that. But why doesn't sshd tell me in its log
> the reason for closing the connection? Why do I have to resort to "ssh
> -vvv" to discover it?
Because some sone of a !@#$ can overwhelm your SSH log files with
failed connections if it's too verbose, and the balance between useful
information and log spew is a tricky one.
Sorry if I seem a bit cranky about this, I've been dealing with SSH
for a long time, and I get a bit touchy when errors get posted as "it
has to be this way".
>>> For me, when I try to authenticate via key, there is no chance to
>>> enter a password if the key is wrong ("Server refused public key"). I
>>> tried to debug with "ssh -vvv ...", and found the wrong owner of
>>> ~/.bash_profile, but still have a problem with another user.
>>>
>> When you've got the wrong key, ssh will fail. It could be that, if you
>> have 4 keys in your file and only the 4th is ok, ssh will fail to. There
>> is a setting in sshd_conf (I suppose it's there) that tells the server
>> how any times he shall try. If it's told to try 3 times, it will fail
>> after figuring out that the first 3 keys used by the client are wrong,
>> _even though the user had a password that would match_!
>> Check this setting and change it or rearrange the order of the keys or
>> unload them, if this thing is the case.
>
> I give one key. And I allow logon via password. I know from older
> versions of ssh, that the password was asked after thze key failed. At
> least with the RH 6 servers, this is not the case any more.
>
>>
>> I had this problem when I had a user a wanting to log in as user b on a
>> server. When user a connected to the server as b, the server said "Wrong
>> public key" because the first 3 keys didn't match (since they were for
>> different connections..).
>
> In my user a's ~./.ssh/config, there is exactly one key per server. And
> this key is used.
>
>> It is the same with ESX where I had the problem that ESX found out I was
>> using Private/Public-Key login in general.
>> It then failed when I tried to log in via ILO, because I had 3 keys
>> loaded and none of them was ok (obviously.. I never have a root-key for
>> ILO-login..)
>> Solution was to unload all keys (which made it possible to login with a
>> password).
>
> Another possibility is to use a ~./.ssh/config with correct definitions ;-)
And this is a very useful approach indeed, especially if you have
multiple SSH access to one server. (One key for backups, one key for
shell access is useful.)
> And please don't PM me as a response to a list posting. Thank you.
>
> Best Regards,
> Werner
You too, and have a good holiday.
|
|
From: Derek M. <co...@pi...> - 2011-12-30 01:11:53
|
On Sun, Dec 25, 2011 at 11:03:24AM -0500, Nico Kadel-Garcia wrote: > Private keys can be stored however the heck you want them. SSH clients > *do not care*, and they can be anywhere you want with whatever > permissions you want, including $HOME/.ssh/privatekey with permissions > 7777 if you feel like it. Since we're being so flamboyantly and aggressively pedantic, I guess I'll point out that this is utterly false. $ chmod 777 ident $ ssh-add ident @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0777 for 'ident' are too open. It is recommended that your private key files are NOT accessible by others. This private key will be ignored. IIRC it's possible to force ssh to ignore this problem with an option, however doing so is fairly asinine in most instances. Having writable private keys is not a good idea, to put it mildly. Though, very rarely, it might be useful/necessary. > > There is no problem with that. But why doesn't sshd tell me in its log > > the reason for closing the connection? Why do I have to resort to "ssh > > -vvv" to discover it? > > Because some sone of a !@#$ can overwhelm your SSH log files with > failed connections if it's too verbose, and the balance between useful > information and log spew is a tricky one. Also false, though there be a kernel of truth there. First, just to be clear, ssh -vvv has no impact whatsoever on the log files. It only controls how much information *the client* reports to the user. More to the point, the reason why you need to see it in the client, in this case, is because only the client knows that it was ignoring particular files, and why it did that. The server doesn't and can't know that. All the server knows is that no key was presented that matches anything in authorized_keys. It could reasonably log that, but that information alone is only marginally useful, at best. You still need to see what the client is doing to figure out *why*. However, when debugging a tricky issue, you can run a stand-alone sshd on a separate port and enable copious debugging when you run it, also having it send the output to stderr instead of the system logs, so as not to clutter them up (you can still capture stderr to a file). When you connect to that port, sshd will log detailed info, which may or may not help, depending on what the problem actually is. Often enough, you really do need both the server side debugging AND the client side debugging turned on in order to figure out what went wrong. And that's just the way it is. For what it's worth, I have no guesses as to what's wrong with the OP's setup (Zachary Burnham). Well actually I do have one: he's using a chroot jail, and didn't rebuild the jail after updating his system. The fact that rssh didn't log *anything* is curious, and would seem to suggest that something else is wrong. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
|
From: Werner F. <wer...@uf...> - 2011-12-30 19:47:56
|
[25.12.2011 17:03] [Nico Kadel-Garcia]: > On Sun, Dec 25, 2011 at 3:44 AM, Werner Flamme <wer...@uf...> wrote: >> Am 25.12.2011 04:37, schrieb Aurelin: >> >>>> I have this even without using rssh, so it may not be related. This >>>> occurs when ~/.ssh and its contents have wrong owners or rights, or >>>> when the shell profiles have wrong owner/rights, or whenever sshd >>>> thinks something is wrong. At least the latter is my guess... >>> This is a possibility. You may not have some of the files with 777 >>> permissions in ~/.ssh/, and I _think_ it's the same for the directory. >>> Can't tell it by heart now. It's also true that a wrong owner will make >>> ssh go failing. >> >> There is no file with 777 permissions in .ssh. I am not mad, you know? >> ;-) The rights of the directory itself, and most of its content, must be >> 0600. Only the public keys should be world readable. And everything must >> belong to the right owner. > > This is incorrect. flatly incorrect. > > The typical permissions are: > > $HOME/. 0700 (or possibly 0775, tastes vary and other settings can > work, write permission is *optional*) > $HOME/.ssh 0700 (or possibly 0750, again, tastes can vary and other > settings in between can work, write permission is *optional*) > "others" should not have access to this I wrote the last answer from a Loosedos sation an could not look properly) seems suicidal to me. > $HOME/.ssh/authorized_keys 0600 (or possibly 0400, tastes vary) > *No one else*, either group members or "other", should have access > to this file. > > Private keys can be stored however the heck you want them. SSH clients > *do not care*, and they can be anywhere you want with whatever > permissions you want, including $HOME/.ssh/privatekey with permissions > 7777 if you feel like it. >From my man page: ---snip--- ssh will simply ignore a private key file if it is accessible by others. ---pins--- So, you obviously have another version of ssh in use than me. I use SLES 11 SP1 and openSUSE 12.1 with their respective openssh versions at the office. None of them permits access by other users than me. > >> There is no problem with that. But why doesn't sshd tell me in its log >> the reason for closing the connection? Why do I have to resort to "ssh >> -vvv" to discover it? > > Because some sone of a !@#$ can overwhelm your SSH log files with > failed connections if it's too verbose, and the balance between useful > information and log spew is a tricky one. Hm. Yes, it is. However, I do not speak of setting a high debug level on a server that is accessible from the internet. I speak of the ssh daemon of a server that is inside a special, isolated subrange inside my comapny's network range. There are about 20 boxes in this range, and there is nearly no chance to blow a log. The speciality with the problem is, that there are 22 virtual servers with one user each that are allowed to log in via ssh key. This works fine for 21, but does not work for the 22nd. As far as I can see, all parameters (files, rights, ...) are identical. Where can I start to search? Even "ssh -vvv" at the client side only tells me that the server closes the connection. But why it does so is not given (that's OK, since I might use the given reason for creating an exploit). But why isn't this reason in the server's log? > Sorry if I seem a bit cranky about this, I've been dealing with SSH > for a long time, and I get a bit touchy when errors get posted as "it > has to be this way". Better watch this for your own post :-P - see the note about private keys above. Have a nice 2012! Werner |
|
From: Nico Kadel-G. <nk...@gm...> - 2011-12-30 22:10:55
|
On Fri, Dec 30, 2011 at 2:47 PM, Werner Flamme <wer...@uf...> wrote: > [25.12.2011 17:03] [Nico Kadel-Garcia]: >> On Sun, Dec 25, 2011 at 3:44 AM, Werner Flamme <wer...@uf...> wrote: >>> Am 25.12.2011 04:37, schrieb Aurelin: >>> >>>>> I have this even without using rssh, so it may not be related. This >>>>> occurs when ~/.ssh and its contents have wrong owners or rights, or >>>>> when the shell profiles have wrong owner/rights, or whenever sshd >>>>> thinks something is wrong. At least the latter is my guess... >>>> This is a possibility. You may not have some of the files with 777 >>>> permissions in ~/.ssh/, and I _think_ it's the same for the directory. >>>> Can't tell it by heart now. It's also true that a wrong owner will make >>>> ssh go failing. >>> >>> There is no file with 777 permissions in .ssh. I am not mad, you know? >>> ;-) The rights of the directory itself, and most of its content, must be >>> 0600. Only the public keys should be world readable. And everything must >>> belong to the right owner. >> >> This is incorrect. flatly incorrect. >> >> The typical permissions are: >> >> $HOME/. 0700 (or possibly 0775, tastes vary and other settings can >> work, write permission is *optional*) >> $HOME/.ssh 0700 (or possibly 0750, again, tastes can vary and other >> settings in between can work, write permission is *optional*) >> "others" should not have access to this > > I wrote the last answer from a Loosedos sation an could not look > properly) seems suicidal to me. > >> $HOME/.ssh/authorized_keys 0600 (or possibly 0400, tastes vary) >> *No one else*, either group members or "other", should have access >> to this file. >> >> Private keys can be stored however the heck you want them. SSH clients >> *do not care*, and they can be anywhere you want with whatever >> permissions you want, including $HOME/.ssh/privatekey with permissions >> 7777 if you feel like it. > > >From my man page: > ---snip--- > ssh will simply ignore a private key file if it is accessible by others. > ---pins--- > > So, you obviously have another version of ssh in use than me. I use SLES > 11 SP1 and openSUSE 12.1 with their respective openssh versions at the > office. None of them permits access by other users than me. I'd like to point you to CygWin. Windows file access gets..... *fascinating* when you have to re-interpret it inside CygWin. Also, Pageant has to deal with Windows permissions and could not care less about file ownership. So yes, it's a different client on a different filesystem, and I overshot. This is not the protocol that cares: this is intelligent default behavior written into the client. And there are some *HORRIBLE* clients out there. Ownership and permissions of the ".ssh" directory" are auto-built as 0700 when running SSH commands, but can be reset in quite open fashion. This includes 0777, allowing others to modify and replace your private keys or known_hosts file. It's the *daemon* that then gets picky about what it accepts for authorized_keys access. >>> There is no problem with that. But why doesn't sshd tell me in its log >>> the reason for closing the connection? Why do I have to resort to "ssh >>> -vvv" to discover it? >> >> Because some sone of a !@#$ can overwhelm your SSH log files with >> failed connections if it's too verbose, and the balance between useful >> information and log spew is a tricky one. > > Hm. Yes, it is. However, I do not speak of setting a high debug level on > a server that is accessible from the internet. I speak of the ssh > daemon of a server that is inside a special, isolated subrange inside my > comapny's network range. There are about 20 boxes in this range, and > there is nearly no chance to blow a log. And in that environment, you can crank up logging. >> Sorry if I seem a bit cranky about this, I've been dealing with SSH >> for a long time, and I get a bit touchy when errors get posted as "it >> has to be this way". > > Better watch this for your own post :-P - see the note about private > keys above. Fair enough. Note my followup. The permission checking is part of the particular client, not part of the protocol itself, and should be denoted accordingly. > > Have a nice 2012! > Werner > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > rssh-discuss mailing list > rss...@li... > https://lists.sourceforge.net/lists/listinfo/rssh-discuss |
Thanks for helping keep SourceForge clean.
X