New answers tagged

3

If you're using password authentication, then SSH sends the password over the network. The connection is encrypted, so eavesdroppers can't see the password. The connection is authenticated, provided that you don't click blindly through a “The authenticity of … can't be established” message, so your password won't be sent to anyone except the legitimate ...


0

SSH does send the userid and password over the network in plain text inside an encrypted channel. This is why when you connect a new host you get prompted to accept the key. In the case of a man-in-the-middle attack with a known host, SSH will refuse to connect until you remove the old key. The plain text password is available at the end points, your ...


3

If you use a password based authentication scheme then, yes the password is passed over the network to the end point... But it is an encrypted channel. eg % ssh remotehost user@remotehost's password: bash$ logout In this scenario the password was sent encrypted over the network. This is why it is very important to handle known_hosts entries properly ...


11

Yes. The password is sent over the encrypted connection, but it's in plaintext to the remote server. The usual way to authenticate is for the server to calculate a hash of the password and to compare it to a value saved on the server. There are several ways of saving hashes, and with current implementations, the client doesn't know what the server uses. (...


2

Yes, ssh sends the password over the network, but after end-to-end encryption has been negotiated. See section 8 of RFC 4252 which says that a password authentication message contains plaintext password in ISO-10646 UTF-8 encoding [RFC3629]


1

can't create lock file /etc/mtab~60598: No space left on device (use -n flag to override) open("/etc/passwd.63618", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 ENOSPC (No space left on device) It's definitely a disk space problem. Most filesystems have two limits: a limit on file contents, and a limit on the number of files — the size of the inode table. Since ...


0

The best option is use Sudo rulles Safe passwords in text file is in top 10 wrong pratice IT. but if you want use you must rememebr parwd is not read from stdin but ftom tty so you can use expect(*1) but this is still wrong way . Beter option is use sudo or sshkey you can login to ssh account using public key to localhost address . do not try su - ...


0

Typically programs like su require passwords to be entered on the terminal and can't be bypassed. The root user doesn't need to enter a password to switch to another, so it's common to see solutions like sudo su user. However we might be able to cheat. If you have the expect command on your system then we can fake typing the password #!/usr/bin/expect -f ...


0

Looks like your sshd is configured to accept ecdsa key. You can either track down on the server-side why it's only looking for ecdsa keys instead of rsa, or you can resolve this from client side by providing an ecdsa key. The steps to create and use an ecdsa key from the client are as follows: ssh-keygen -t ecdsa -b 256 -N '' -f ~/.ssh/id_ecdsa ssh-copy-...


0

Hope this helps you: #!/usr/bin/expect spawn sftp USERNAME@ip_address:/path/to/folder expect "Password:" send "PASSWORD\n" expect "sftp>" send "put file1\n" expect "sftp>" send "bye\n" or if you don't want to dedicate the whole script to expect: #!/bin/sh expect << 'EOS' spawn sftp USERNAME@ip_address:/path/to/folder expect "Password:" send ...


0

echo "Sending files to destination" USER='(username)' PASSWD='(********)' sftp user@ip_address << EOF quote USER $USER quote PASS $PASSWD cd path put file1 bye EOF


-1

echo "ftping files to destination" USER='(username)' PASSWD='(********)' sftp user@ip_address << EOF quote USER $USER quote PASS $PASSWD cd path put file1 bye EOF



Top 50 recent answers are included