scp to fedora 12

mbeattie · #1 8th April 2010, 10:01 PM

I recently upgraded my machine to fedora 12 and now when I try to scp anything to the machine, the scp just hangs forever. I have tested this from localhost, an ubuntu machine, and an os x machine. I grabbed the sshd debug and I don't see any errors in there. The last few lines are below. You can see where I left it hanging for a minute before I killed it.

Any idea what's going on here?

Code:

Apr  8 14:47:43 white sshd[10761]: debug1: PAM: establishing credentials
Apr  8 14:47:43 white sshd[10761]: debug1: permanently_set_uid: 500/501
Apr  8 14:47:43 white sshd[10761]: debug1: Entering interactive session for SSH2.
Apr  8 14:47:43 white sshd[10761]: debug1: server_init_dispatch_20
Apr  8 14:47:43 white sshd[10761]: debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768
Apr  8 14:47:43 white sshd[10761]: debug1: input_session_request
Apr  8 14:47:43 white sshd[10761]: debug1: channel 0: new [server-session]
Apr  8 14:47:43 white sshd[10761]: debug1: session_new: session 0
Apr  8 14:47:43 white sshd[10761]: debug1: session_open: channel 0
Apr  8 14:47:43 white sshd[10761]: debug1: session_open: session 0: link with channel 0
Apr  8 14:47:43 white sshd[10761]: debug1: server_input_channel_open: confirm session
Apr  8 14:47:43 white sshd[10761]: debug1: server_input_channel_req: channel 0 request env reply 0
Apr  8 14:47:43 white sshd[10761]: debug1: session_by_channel: session 0 channel 0
Apr  8 14:47:43 white sshd[10761]: debug1: session_input_channel_req: session 0 req env
Apr  8 14:47:43 white sshd[10761]: debug1: server_input_channel_req: channel 0 request exec reply 0
Apr  8 14:47:43 white sshd[10761]: debug1: session_by_channel: session 0 channel 0
Apr  8 14:47:43 white sshd[10761]: debug1: session_input_channel_req: session 0 req exec
Apr  8 14:48:33 white sshd[10761]: Connection closed by 69.59.255.6
Apr  8 14:48:33 white sshd[10761]: debug1: channel 0: free: server-session, nchannels 1
Apr  8 14:48:33 white sshd[10761]: debug1: session_close: session 0 pid 10762
Apr  8 14:48:33 white sshd[10761]: debug1: do_cleanup
Apr  8 14:48:33 white sshd[10761]: Transferred: sent 2264, received 2528 bytes
Apr  8 14:48:33 white sshd[10761]: Closing connection to 69.59.255.6 port 47787
Apr  8 14:48:33 white sshd[10759]: debug1: PAM: cleanup
Apr  8 14:48:33 white sshd[10759]: debug1: PAM: closing session
Apr  8 14:48:33 white sshd[10759]: pam_unix(sshd:session): session closed for user mbeattie
Apr  8 14:48:33 white sshd[10759]: debug1: PAM: deleting credentials

scott32746 · #2 8th April 2010, 10:36 PM

Hello,
Have you tried going from F12 to a different server ?
Not have a problem with the IP already being used ?
can you ping to and out from the F12 server ?
did this out before the upgrade ?

mbeattie · #3 9th April 2010, 03:50 AM

Quote:

Originally Posted by scott32746

Hello,
Have you tried going from F12 to a different server ?
Not have a problem with the IP already being used ?
can you ping to and out from the F12 server ?
did this out before the upgrade ?

I am able to go from the affected machine to another F12 machine as well as an Ubuntu machine.

The IP is unique. I am able to ssh in just fine.

I can ping just fine.

It worked before the upgrade. It might also be smart for me to note that this is a PPC installation.

smr54 · #4 9th April 2010, 04:05 AM

Is the IP listed in in the client's /etc/hosts file? This sometimes makes a difference.

One way to test this is in the server's /etc/sshd/sshd_config is take the commented line about using DNS, uncomment it, change the yes to no, restart the sshd daemon and see what happens.

If it no longer hangs, than that helps narrow down the problem.

mbeattie · #5 9th April 2010, 12:03 PM

I uncommented the UseDNS line and it still doesn't work. I dont think dns is an issue as I can ssh in but can't even scp to localhost.

scott32746 · #6 9th April 2010, 02:25 PM

try disable SElinux or maybe an iptable issues

#7 9th April 2010, 02:46 PM

Long shot,
Post the command you are using to scp to the fedora machine. Maybe someone will see something "wrong" with it.

Ky

mbeattie · #8 9th April 2010, 04:32 PM

Iptables and selinux are disabled.

Code:

[mbeattie@white ~]$ sudo iptables -L
[sudo] password for mbeattie: 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
[mbeattie@white ~]$ sudo cat /etc/selinux/config 
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#	enforcing - SELinux security policy is enforced.
#	permissive - SELinux prints warnings instead of enforcing.
#	disabled - SELinux is fully disabled.
SELINUX=disabled
#SELINUX=permissive
# SELINUXTYPE= type of policy in use. Possible values are:
#	targeted - Only targeted network daemons are protected.
#	strict - Full SELinux protection.
SELINUXTYPE=targeted

This is what happens when I scp the file from the same machine

Code:

[mbeattie@white ~]$ scp test.file 192.168.91.23:test.file2
Enter passphrase for key '/home/mbeattie/.ssh/id_rsa': 
^CKilled by signal 2.
[mbeattie@white ~]$ scp 192.168.91.23:test.file ./test.file2
Enter passphrase for key '/home/mbeattie/.ssh/id_rsa': 
C0644 20 test.file
[mbeattie@white ~]$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0D:93:7A:C7:EA  
          inet addr:192.168.91.23  Bcast:192.168.91.255  Mask:255.255.255.0
          inet6 addr: fe80::20d:93ff:fe7a:c7ea/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33660 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26020 errors:0 dropped:0 overruns:0 carrier:11
          collisions:11 txqueuelen:1000 
          RX bytes:25571763 (24.3 MiB)  TX bytes:6320243 (6.0 MiB)
          Interrupt:41 Base address:0xb000

Notice the error code when I try to scp a file FROM the "remote" host. You will also notice that I am using a passworded ssh key. The same thing happens when I don't use that.

---------- Post added at 11:32 AM CDT ---------- Previous post was at 11:24 AM CDT ----------

Here's the whole secure log from sshd while the loglevel is set to DEBUG and trying to scp from the remote machine (the case that gave me the C0644 umask thing in the last post)

Code:

Apr  9 11:30:13 white sshd[3677]: debug1: Forked child 3682.
Apr  9 11:30:13 white sshd[3682]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Apr  9 11:30:13 white sshd[3682]: debug1: inetd sockets after dupping: 3, 3
Apr  9 11:30:13 white sshd[3682]: Connection from 192.168.91.23 port 53227
Apr  9 11:30:13 white sshd[3682]: debug1: Client protocol version 2.0; client software version OpenSSH_5.3
Apr  9 11:30:13 white sshd[3682]: debug1: match: OpenSSH_5.3 pat OpenSSH*
Apr  9 11:30:13 white sshd[3682]: debug1: Enabling compatibility mode for protocol 2.0
Apr  9 11:30:13 white sshd[3682]: debug1: Local version string SSH-2.0-OpenSSH_5.3
Apr  9 11:30:13 white sshd[3683]: debug1: permanently_set_uid: 74/74
Apr  9 11:30:13 white sshd[3683]: debug1: list_hostkey_types: ssh-rsa,ssh-dss
Apr  9 11:30:13 white sshd[3683]: debug1: SSH2_MSG_KEXINIT sent
Apr  9 11:30:13 white sshd[3683]: debug1: SSH2_MSG_KEXINIT received
Apr  9 11:30:13 white sshd[3683]: debug1: kex: client->server aes128-ctr hmac-md5 none
Apr  9 11:30:13 white sshd[3683]: debug1: kex: server->client aes128-ctr hmac-md5 none
Apr  9 11:30:13 white sshd[3683]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Apr  9 11:30:13 white sshd[3683]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
Apr  9 11:30:13 white sshd[3683]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
Apr  9 11:30:13 white sshd[3683]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
Apr  9 11:30:13 white sshd[3683]: debug1: SSH2_MSG_NEWKEYS sent
Apr  9 11:30:13 white sshd[3683]: debug1: expecting SSH2_MSG_NEWKEYS
Apr  9 11:30:13 white sshd[3683]: debug1: SSH2_MSG_NEWKEYS received
Apr  9 11:30:13 white sshd[3683]: debug1: KEX done
Apr  9 11:30:13 white sshd[3683]: debug1: userauth-request for user mbeattie service ssh-connection method none
Apr  9 11:30:13 white sshd[3683]: debug1: attempt 0 failures 0
Apr  9 11:30:13 white sshd[3682]: debug1: PAM: initializing for "mbeattie"
Apr  9 11:30:13 white sshd[3682]: debug1: PAM: setting PAM_RHOST to "192.168.91.23"
Apr  9 11:30:13 white sshd[3682]: debug1: PAM: setting PAM_TTY to "ssh"
Apr  9 11:30:13 white sshd[3683]: debug1: userauth-request for user mbeattie service ssh-connection method publickey
Apr  9 11:30:13 white sshd[3683]: debug1: attempt 1 failures 0
Apr  9 11:30:13 white sshd[3683]: debug1: test whether pkalg/pkblob are acceptable
Apr  9 11:30:13 white sshd[3682]: debug1: temporarily_use_uid: 500/501 (e=0/0)
Apr  9 11:30:13 white sshd[3682]: debug1: trying public key file /home/mbeattie/.ssh/authorized_keys
Apr  9 11:30:13 white sshd[3682]: debug1: fd 4 clearing O_NONBLOCK
Apr  9 11:30:13 white sshd[3682]: debug1: matching key found: file /home/mbeattie/.ssh/authorized_keys, line 8
Apr  9 11:30:13 white sshd[3682]: Found matching RSA key: d6:ac:5a:58:d7:26:3c:45:ca:e7:38:d2:0b:bb:df:fc
Apr  9 11:30:13 white sshd[3682]: debug1: restore_uid: 0/0
Apr  9 11:30:13 white sshd[3683]: Postponed publickey for mbeattie from 192.168.91.23 port 53227 ssh2
Apr  9 11:30:16 white sshd[3683]: debug1: userauth-request for user mbeattie service ssh-connection method publickey
Apr  9 11:30:16 white sshd[3683]: debug1: attempt 2 failures 0
Apr  9 11:30:16 white sshd[3682]: debug1: temporarily_use_uid: 500/501 (e=0/0)
Apr  9 11:30:16 white sshd[3682]: debug1: trying public key file /home/mbeattie/.ssh/authorized_keys
Apr  9 11:30:16 white sshd[3682]: debug1: fd 4 clearing O_NONBLOCK
Apr  9 11:30:16 white sshd[3682]: debug1: matching key found: file /home/mbeattie/.ssh/authorized_keys, line 8
Apr  9 11:30:16 white sshd[3682]: Found matching RSA key: d6:ac:5a:58:d7:26:3c:45:ca:e7:38:d2:0b:bb:df:fc
Apr  9 11:30:16 white sshd[3682]: debug1: restore_uid: 0/0
Apr  9 11:30:16 white sshd[3682]: debug1: ssh_rsa_verify: signature correct
Apr  9 11:30:16 white sshd[3682]: debug1: do_pam_account: called
Apr  9 11:30:16 white sshd[3682]: Accepted publickey for mbeattie from 192.168.91.23 port 53227 ssh2
Apr  9 11:30:16 white sshd[3682]: debug1: monitor_child_preauth: mbeattie has been authenticated by privileged process
Apr  9 11:30:16 white sshd[3682]: debug1: temporarily_use_uid: 500/501 (e=0/0)
Apr  9 11:30:16 white sshd[3682]: debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
Apr  9 11:30:16 white sshd[3682]: debug1: restore_uid: 0/0
Apr  9 11:30:16 white sshd[3682]: debug1: SELinux support disabled
Apr  9 11:30:16 white sshd[3682]: debug1: PAM: establishing credentials
Apr  9 11:30:16 white sshd[3682]: pam_unix(sshd:session): session opened for user mbeattie by (uid=0)
Apr  9 11:30:16 white sshd[3682]: User child is on pid 3684
Apr  9 11:30:16 white sshd[3684]: debug1: PAM: establishing credentials
Apr  9 11:30:16 white sshd[3684]: debug1: permanently_set_uid: 500/501
Apr  9 11:30:16 white sshd[3684]: debug1: Entering interactive session for SSH2.
Apr  9 11:30:16 white sshd[3684]: debug1: server_init_dispatch_20
Apr  9 11:30:16 white sshd[3684]: debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768
Apr  9 11:30:16 white sshd[3684]: debug1: input_session_request
Apr  9 11:30:16 white sshd[3684]: debug1: channel 0: new [server-session]
Apr  9 11:30:16 white sshd[3684]: debug1: session_new: session 0
Apr  9 11:30:16 white sshd[3684]: debug1: session_open: channel 0
Apr  9 11:30:16 white sshd[3684]: debug1: session_open: session 0: link with channel 0
Apr  9 11:30:16 white sshd[3684]: debug1: server_input_channel_open: confirm session
Apr  9 11:30:16 white sshd[3684]: debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0
Apr  9 11:30:16 white sshd[3684]: debug1: server_input_channel_req: channel 0 request env reply 0
Apr  9 11:30:16 white sshd[3684]: debug1: session_by_channel: session 0 channel 0
Apr  9 11:30:16 white sshd[3684]: debug1: session_input_channel_req: session 0 req env
Apr  9 11:30:16 white sshd[3684]: debug1: server_input_channel_req: channel 0 request exec reply 1
Apr  9 11:30:16 white sshd[3684]: debug1: session_by_channel: session 0 channel 0
Apr  9 11:30:16 white sshd[3684]: debug1: session_input_channel_req: session 0 req exec
Apr  9 11:30:16 white sshd[3684]: debug1: channel 0: forcing write
Apr  9 11:30:16 white sshd[3684]: debug1: Received SIGCHLD.
Apr  9 11:30:16 white sshd[3684]: debug1: session_by_pid: pid 3685
Apr  9 11:30:16 white sshd[3684]: debug1: session_exit_message: session 0 channel 0 pid 3685
Apr  9 11:30:16 white sshd[3684]: debug1: session_exit_message: release channel 0
Apr  9 11:30:16 white sshd[3684]: Received disconnect from 192.168.91.23: 11: disconnected by user
Apr  9 11:30:16 white sshd[3684]: debug1: do_cleanup
Apr  9 11:30:16 white sshd[3682]: debug1: do_cleanup
Apr  9 11:30:16 white sshd[3682]: debug1: PAM: cleanup
Apr  9 11:30:16 white sshd[3682]: debug1: PAM: closing session
Apr  9 11:30:16 white sshd[3682]: pam_unix(sshd:session): session closed for user mbeattie
Apr  9 11:30:16 white sshd[3682]: debug1: PAM: deleting credentials

scott32746 · #9 9th April 2010, 04:47 PM

Need to tell it where you would like to have it put
EXAMPLE: scp test.file 192.168.91.23:/tmp/test.file2

Are you getting asked to enter passphrase and then you kill it ?
Have you tried to recreate ssh_key / passphrase ?

mbeattie · #10 9th April 2010, 04:56 PM

Quote:

Originally Posted by scott32746

Need to tell it where you would like to have it put
EXAMPLE: scp test.file 192.168.91.23:/tmp/test.file2

putting a host name or IP with a : at the end means to scp to drop the file in whatever the home directory of the user you are connecting as is.

Quote:

Originally Posted by scott32746

Are you getting asked to enter passphrase and then you kill it ?
Have you tried to recreate ssh_key / passphrase ?

Well, in the first example I am asked the passphrase, I enter it, I wait a minute or five and then I kill it. (It's hanging and not working)

---------- Post added at 11:56 AM CDT ---------- Previous post was at 11:49 AM CDT ----------

I figured it out.

http://blogs.sun.com/janp/entry/how_...protocol_works

This section: scp just hangs after the password is entered when I try to copy to the remote side

I made a change to my bashrc that causes the title bar to change to the name of the host I am connected to on this machine instead of the path and all of that.

echo -ne "\033]0;white\007"

I guess scp sees this and gets confused. Probably because of the special characters.

gthill · #11 9th April 2010, 05:06 PM

You can also use scp's own debug using the v or vv flag for more information
scp -v

mbeattie · #12 9th April 2010, 05:08 PM

That doesn't help a lot with this

scp -vv

Code:

Enter passphrase for key '/home/mbeattie/.ssh/id_rsa': 
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug2: fd 4 setting O_NONBLOCK
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: scp -v -t test.file2
debug2: channel 0: request exec confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0

gthill · #13 9th April 2010, 05:28 PM

Yeah, well it should help
because it should look something like this.

[user@tc4 ~]$ touch asdf
[user@tc4 ~]$ scp -vv asdf localhost:~/asdg
Executing: program /usr/bin/ssh host localhost, user (unspecified), command scp -v -t ~/asdg
OpenSSH_5.2p1, OpenSSL 0.9.8k-fips 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
.
.
.
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 1936, received 2248 bytes, in 0.2 seconds
Bytes per second: sent 10834.0, received 12580.0
debug1: Exit status 0

jpollard · #14 9th April 2010, 06:33 PM

I think I see part of the problem - When you are doing an scp you are not initializing
a terminal interface.

Normally, this isn't a problem - but if the login/profile output things ASSUMING a
terminal connection, then things can get strange.

It just will work if you use ssh (terminal is connected). scp may work for
some versions (where the client ignores/recognizes that terminal output is present)
but... not recommended.

Usually conditional output to a terminal is bracked by something like

Code:

if [ "$PS1" ne "" ]; then
   <send stuff to the terminal, set terminal characteristics...>
fi

This prevents trying to set things that don't exist, and cause an error response
from the shell - which in turn may be misinterpreted by the daemon that executes
the shell.

This is particularly noticable with rsh/krsh (remote shell) and rcp/krcp (remote copy).

Part of the reason for the problem is that rcp/krcp and scp are designed to perform
an optimized transfer when given a command like:

Code:

scp remotehost:remote_file remotetarget:remote_file

I believe scp establishes the equivalent of:

Code:

ssh remotehost scp remote_file remotetarget:remote_file

for the purpose of copying a file from one remote host to another.

aleph · #15 10th April 2010, 04:02 AM

Quote:

Originally Posted by jpollard

Usually conditional output to a terminal is bracked by something like

Code:

if [ "$PS1" ne "" ]; then
   <send stuff to the terminal, set terminal characteristics...>
fi

I guess this is probably better a test:

Code:

if tty -s; then
  <do stuff you should do only on a tty>
fi