SCP error due to backslash in username - scp

I am using SCP to transfer a folder from a remote server (RS1) to another remote server (RS2). My command is:
scp PEM\username#RS1:/home/local/PEM/folderName1/ PEM\username#RS2:/home/local/PEM/foldername2
Final errors I get after putting the password for PEM\username is:
Permission denied, please try again
Permission denied, please try again
Received disconnect from RS2. Too many authentication failures for PEMusername
As you can see, the error message quotes PEMusername as my username and not PEM\username.
Is there a way to explicitly mention the username for SCP protocol?

The \ is an escape character in *nix shell.
If you need to specify backslash explicitly, either double it:
scp PEM\\username#RS1:/home/local/PEM/folderName1/ ...
or wrap whole parameter to single-quotes:
scp 'PEM\username#RS1:/home/local/PEM/folderName1/' ...

Related

Tectia SSH Logon via CMD with password as argument

hello I'm trying out Tectia 6.4 via cmd but I'm having trouble login in with password as argument. I always get the error "too many argument"
I tried
sftpg3.exe host password
sftpg3.exe host --password=password
sftpg3.exe host -p password
If i just enter host-name i get the prompt for the password in order to login. there no way to use password as argument in order to log in via cmd? I look into help and they have option for password but it does not seems to be working for me
Thanks
sftp3.exe --password=yourpassword username#host
Make sure your options are first and you are including your username#host in the command also.
optional -B file.txt where file.txt includes your FTP command to execute after connecting.
NOTE: Having your password in cleartext is considered a security risk.

scp error--syntax, or something else?

I am trying to use scp to copy various files from my work machine to my personal. I use the code:
scp usernamework#workcomputer:~/directory/to/file \
usernamepersonal#personalcomputer:~/Directory/to/copied/file
When I enter the code I am prompted for my work computer password. I enter the password and the error is:
could not resolve hostname(personal computer)
Is there a syntax error in my code-or is there something else going on?
If you specify two remote hosts, it will connect to the first one and from there it will connect to the second one. The second hostname is probably not resolvable/visible from the first one and therefore it fails. There are few possibilities you can do:
Connect to your personal computer and do a transfer with only one remote:
scp usernamework#workcomputer:~/directory/to/file ~/Directory/to/copied/file
Use -3 switch, which will connect to both of the ends from your current computer:
scp -3 usernamework#workcomputer:~/directory/to/file \
usernamepersonal#personalcomputer:~/Directory/to/copied/file

Prevent rsync from trying to ask for a password

How do I prevent rsync from trying to ask for a password for the remote server login?
Note: I am not asking how to set up public key authenticated SSH. I know how to set up public key authenticated SSH. What I am asking is how to prevent rsync from trying to ask for a password if public key authentication fails, like what scp's -B flag does. I am using rsync in a script here, so if it tries to ask for a password, my script will hang, waiting for input that will never come. I want the rsync command to instead fail, so my script can detect the failure and exit gracefully.
Just pass options to the underlying ssh command used by rsync:
rsync -e 'ssh -oBatchMode=yes [other ssh options]' [rest of rsync command]
From the rsync manual:
-e, --rsh=COMMAND specify the remote shell to use
From the ssh manual:
BatchMode
If set to “yes”, passphrase/password querying will be disabled.
This option is useful in scripts and other batch jobs where no
user is present to supply the password. The argument must be
“yes” or “no”. The default is “no”.
This emulates the bahavior os scp -B.

plink ssh as root, access denied

I'm trying to connect to a server via plink. However, I'm getting the following error:
C:\>plink -ssh -pw password root#server-name
Using username "root".
Access denied
My sshd_config file contains PermitRootLogin yes, even though that's the default value, just to be sure. Is there some other configuration I need to set to allow this type of connection?
Please post or check contents of the log probably found at /var/log/auth.log.
Another question would be if you have a password added for your root account?
Otherwise you can try and set this using sudo passwd root.
My password contained special characters (!##$%^). I needed to add double-quotes around them to get it to not complain. Silly me!

why is the `tcgetattr` error seen when ssh is used for dumping the backup file on another server?

I want to dump a tables backup on another server and I am using ssh for doing it.
when I run the below command, it gives an error but dump file is copied to destination.
mysqldump -u username -ppassword dbname tablename | ssh -t -t servers_username#domain_name 'cat > /tmp/bckp.sql';
tcgetattr: Invalid argument
If I press CTRL+c then it appends error message with Killed by signal 2.
Why is this error?
I've seen this error when forcing pseudo-terminal allocation using ssh -t -t or ssh -tt.
The tcgetattr function is used to look up the attributes of the pseudoterminal represented by a file descriptor; it takes a file descriptor and a pointer to a termios structure to store the terminal metadata in. It looks to me from the stub code in glibc that this error represents a null pointer for the termios struct. I am not sure whether these same error handling semantics are in place for the platform-specific implementations of tcgetattr.
If you want to suppress this error, invoke ssh like so:
ssh 2>/dev/null
This will redirect STDERR to /dev/null; you won't see the error when invoking with this redirection. Note that this will mask other errors with ssh; you may need to remove this for debugging purposes.
In my case, forcing pty allocation on the outer ssh of a two-level ssh invocation fixed the problem.
Details:
When you provide a command for ssh to run ( e.g. ssh some_server "do_some_command" ), then ssh assumes you won't need an interactive session, and it will not allocate a pty as it submits the "do_some_command" job you asked it to.
However, things get interesting if you have two layers of ssh (e.g. let's say you want to ssh into a "gateway" machine first, and from there you ssh into an "inner" machine and run some "inner_command").
The thing is, with a two-layer ssh'ing job, from the perspective of the outer ssh, you are requesting that the outer ssh run a non-interactive command, hence the outer ssh will not allocate a tty.
If the command you are running in the inner ssh is meant to be interactive, it will probably want to query tty attributes and it will (righteously) complain that it is not being run on a tty.
The solution in my case was to force the outer ssh to allocate a pty, by using the -t argument. So it looked like this:
ssh -t <gateway_machine> "ssh <inner_machine> \"<inner_interactive_command>\" "
Greetings to the sysadmins out there