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]


0

A similar problem Another possible lead I had the same problem using ~/.ssh/authorized_keys with permitopen. As I use autossh to create a tunnel, I need two ports: one for connection (10000), one for monitoring (10001). On client side This gave me a similar problem with monitoring port: autossh -M 10001 -o GatewayPorts=yes -o ServerAliveInterval=...


1

This probably isn't the answer you want to hear, but you can't do what you're trying to do. The ProxyCommand option in ssh expects to STDIN & STDOUT of the command to be connected directly to the destination host (%h) and port (%p). Thus it is the local ssh process which is talking to the remote sshd, not the proxy host's ssh process. And since it's the ...


1

you can enable verbose more logging for sshd: sudo nano /etc/ssh/sshd_config add line LogLevel VERBOSE and restart sshd sudo systemctl restart ssh view log entry journalctl -u sshd |tail -100


0

The SSH configuration file does not take or evaluate shell code. The reason your first thing works is that it's executed by the shell as part of the invocation of the proxy command. But I suppose LocalCommand may be used in a similar way as your proxy command to invoke ssh -f -L.... I've never done this or seen it done though. See also PermitLocalCommand.


0

Just found out that I had a space after the IP address in "HostName x.x.x.x{space_here}" and had this error too: channel 0: open failed: administratively prohibited: open failed However it could be seen in logs that there was something strange: debug1: Executing proxy command: exec ssh -A some-jump -W x.x.x.x\302\240:22 as those \302\240 were quite ...


2

Yes, rsync is your best bet. Something like this should work: rsync -vr --size-only --times <source> <dest> --size-only tells rsync not to copy the files again, --times tells it to update timestamps.



Top 50 recent answers are included