SCP/SFTP problem

tpe · 03-10-2005, 02:19 PM

Hallo,
First of all please let me explain my situation. I have a web site at which I need to upload (automatically) a large number of small files. I have created a set of php/bash scripts in order to to that. Since I want to automatically upload the files I opted to use scp.

My configuration:
1 Suse Linux 8.2 Desktop PC behind the firewall (named:desktop)
1 Suse Linux 8.2 Server WITHOUT X subsystem (named:server)
DSL connection

From the desktop:
I can login to my web server via ssh account@www.webserver.com
I can sftp to the web server with account@www.webserver.com
I CANNOT use scp because the remote shell is echoing a message from the ISP.

From the firewall/server
I can login to my web server via ssh ONLY when I log to the server as root(!) (ssh account@www.webserver.com)

I CANNOT sftp to the server from any account
I CANNOT scp to the server for the same reason as sftp
When I try to use scp/sftp I receive either of the following messages:
Message B:

Code:

   Error: Can't open display: desktop:0.0
   9984: Host key verification failed.
   9983: Couldn't read packet: Connection reset by peer

Message A:

Code:

    Xlib: connection to "peter:0.0" refused by server
    Xlib: No protocol specified
    Error: Can't open display: desktop:0.0
    10459: Host key verification failed.

I tried to figure out what the problem was, using ssh -vvv. It seems that the problem is on those lines:

Code:

10793: debug3: check_host_in_hostfile: filename /home/tpe.ssh/known_hosts
10793: debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
10793: debug3: check_host_in_hostfile: filename /home/tpe/.ssh/known_hosts
10793: debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
10793: debug3: check_host_in_hostfile: filename /home/tpe/.ssh/known_hosts
10793: debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
10793: debug2: no key of type 0 for host www.webserver.com
10793: debug3: check_host_in_hostfile: filename /home/tpe/.ssh/known_hosts2
10793: debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2
10793: debug3: check_host_in_hostfile: filename /home/tpe/.ssh/known_hosts
10793: debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
10793: debug2: no key of type 2 for host www.webserver.com

Please note that
a) I receive the Xlib message when I use ssh to connect from my dekstop to server adn from there to my web server not when I login directcly to the firewall.
b) I have not installed X subsystem on the server.
c) This is not a firewall problem (remember I can use ssh this root account. Additionaly, even with stoped firewall normal users cannot ssh to the web server.)

I would appreciate any help on this problem (and mostly why I can ssh with root account and I cannot ssh .

Thank you in advance and I my apologies for the length of this message.

merana · 03-11-2005, 03:13 PM

Hmmm... First drop back and simplify:

1. su to the account you are running the task from.
2. make sure that account can make a successful SSH connection.
- if NOT then start troubleshooting that
- if SO then check out the SSH config and make sure that there is no limitation on who can run sftp. You make need to sudo that.

Also, part of the error was talking about a host key verification failure... Are you using a host auth method? That opens a door from any process on the host to the remote end. Why not run the job as a user and limit the scope of access? Just the paranoid part of me there... BUT I'd make sure that the host keys are valid also. You may be able to SSH in as root (should disable that...) because it auths the user differently... Just a WAG (Wild Ass Guess) on that though...

g'luck

tpe · 03-12-2005, 12:17 PM

After a lot of searching, I think that I found the solution (sorry I do not remember the name of the person that suggested the following)

The Xlib error was generated because NORMAL USERS, had no write access to /dev/tty (SuSE's paranoid(!) security options), thus ssh was trying to open the openssh-askpass which requires X subsystem.

Now, since I do not want to run X on the firewall, I simpy changed the permitions on /dev/tty to 660 root.users adn voila... the problem was gone.

I have to thank merana for his/her suggestions.

I hope that someone in the future will find this helpfull.

merana · 03-12-2005, 06:58 PM

Glad I could be of some assistance!