Problem with scp and SSH on Arch Linux

[Stijn Segers-2]

Hello,

I tried to use scp today, and got this weird behaviour:

[stijn@hephaistos ~]$ scp -2 .ssh/id_rsa-olympos2.pub \
stijn@olympos:/home/stijn/.ssh/id_rsa-olympos2.pub
Enter passphrase for key '/home/stijn/.ssh/id_rsa-olympos':
Arch Linux (Duke) 2.6.21.4-cks-server
[stijn@hephaistos ~]$

So I enter the passphrase, get access, but the copy never gets done.

This is in /var/log/auth.log:

Jun 14 22:00:57 olympos sshd[3678]: Accepted publickey for stijn from
192.168.1.2 port 56900 ssh2
Jun 14 22:00:57 olympos sshd(pam_unix)[3680]: session opened for user
stijn by (uid=0)
Jun 14 22:00:57 olympos sshd[3680]: error: channel 0: chan_read_failed
for istate 3
Jun 14 22:00:57 olympos sshd[3680]: error: channel 0: chan_read_failed
for istate 3
Jun 14 22:00:57 olympos sshd(pam_unix)[3680]: session closed for user
stijn


Googling on the "chan_read_failed for istate 3" reveals a lot of links,
but there it seems it is only a 'random' error, and does not affect the
copy action itself. In my case the copying never gets done.

I have attached my sshd_config from the server, if this could be useful.
Password authentication is disabled, making sure one can only get in
when he has the RSA key.

OpenSSH version is 4.6p1-4.

Kind regards

Stijn Segers

# $OpenBSD: sshd_config,v 1.74 2006/07/19 13:07:10 dtucker Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
Protocol 2
#AddressFamily any
ListenAddress 0.0.0.0
#ListenAddress ::
AllowUsers stijn

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no

# no default banner path
#Banner /etc/motd

# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server

[Greg Wooledge]

On Thu, Jun 14, 2007 at 10:08:27PM +0200, Stijn Segers wrote:
> I tried to use scp today, and got this weird behaviour:
>
> [stijn@hephaistos ~]$ scp -2 .ssh/id_rsa-olympos2.pub \
> stijn@olympos:/home/stijn/.ssh/id_rsa-olympos2.pub
> Enter passphrase for key '/home/stijn/.ssh/id_rsa-olympos':
> Arch Linux (Duke) 2.6.21.4-cks-server
> [stijn@hephaistos ~]$

Your .bashrc (or analogous file for your login shell) on the remote
system is writing stuff to stdout.  You need to stop it from doing that.
If you still want it to do that when you open a regular interactive
shell (e.g. an xterm), then wrap all your output-producing commands in
a test, such as this:

if test -t 1; then
  uname ....
  stty ...
  echo ...
fi

The exact details will depend on just what you've got in the .bashrc.

[bgl]

> So I enter the passphrase, get access, but the copy never gets done.

please look in your /etc/passwd file and check, if the required user has a working shell (last entry on the line) and not /bin/false.

If the shell is not there please enter

usermod -s /bin/bash <username>

So long

Bernd

[Guido Barosio]

Caught this message and I am currently wondering why a /bin/false'ed
passwd file should allow a scp to get in the host and attempt the
copy.

Bern, could you please help me understand this?

Thanks in advance,
gb.-

On 6/24/07, bgl <bernd.glueckert@...> wrote:

>
> > So I enter the passphrase, get access, but the copy never gets done.
>
> please look in your /etc/passwd file and check, if the required user has a
> working shell (last entry on the line) and not /bin/false.
>
> If the shell is not there please enter
>
> usermod -s /bin/bash <username>
>
> So long
>
> Bernd
>
> --
> View this message in context: http://www.nabble.com/Problem-with-scp-and-SSH-on-Arch-Linux-tf3924022.html#a11279417
> Sent from the SSH (Secure Shell) mailing list archive at Nabble.com.
>
>

--
Guido Barosio
-----------------------
http://www.globant.com
guido.barosio@...

[Derek Martin]

On Mon, Jun 25, 2007 at 11:18:00PM -0300, Guido Barosio wrote:
> Caught this message and I am currently wondering why a /bin/false'ed
> passwd file should allow a scp to get in the host and attempt the
> copy.

OpenSSH does the authentication... it doesn't need to care what your
shell is for the authentication to succeed.  All that matters for
login to be successful is for some configured authentication mechanism
to succeed; i.e. the user's supplied password matches what's CRYPTed
in the passwd file, or the user's private key matches the public key
stored in the user's authorized keys file, etc.  None of this requires
the shell to work.

For the scp to succeed, the user needs a working shell, because sshd
will start the user's shell in order to have it execute the scp
command on the remote system.  If the shell doesn't work, the scp
command will never run...

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D