MacOS – Don’t get password prompt when ssh-ing from fedora

macospasswordssh

I can ssh successfully with password from one mac running Yosemite to another, but when I try to use password authentication for ssh from fedora to either Yosemite system, I never get a password prompt – even if I disable key exchange and explicitly require password authentication. All are on the same local network.

Looking at the differences between ssh -vvv from Fedora and Yosemite, the difference seems to be that Fedora has disabled md5 authentication by default (see Redhat bugzilla 1373835, whereas Yosemite the successful login from Yosemite uses it. However nothing changes if I add

-o MACs=hmac-md5-etm@openssh.com

to the Fedora command line. Upgrading from Yosemite is infeasible (hardware limitations). Do you have any suggestions?

PS could someone with enough points please add Fedora/Redhat, or even linux, tags to this to make it more discoverable (unix, which is the narrowest I can add, is far too broad to be useful)?

When I enter

ssh -vvv -o PreferredAuthentications=keyboard-interactive -o PubkeyAuthentication=no user@host

this is the end of the output I get from Fedora (everything before corresponds fairly accurately between Fedora and Yosemite logins, modulo slightly differing available encryptions and diagnostic formats):

debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32
debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32
debug3: send packet: type 34
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent
Connection closed by 192.168.2.12 port 22

Whereas this is what I see in the corresponding Yosemite output:

debug2: mac_setup: found hmac-md5-etm@openssh.com
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug2: mac_setup: found hmac-md5-etm@openssh.com
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 132/256
debug2: bits set: 512/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 28:0d:78:e3:61:3a:72:5e:e5:17:b9:27:0b:ad:33:5f
debug3: load_hostkeys: loading entries for host "192.168.2.12" from file "/Users/rim/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/rim/.ssh/known_hosts:7
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.2.12' is known and matches the RSA host key.
debug1: Found key in /Users/rim/.ssh/known_hosts:7
debug2: bits set: 519/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/rim/.ssh/id_rsa (0x0),
debug2: key: /Users/rim/.ssh/id_dsa (0x0),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred keyboard-interactive
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: 
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:

Best Answer

It turns out that this is due to a bug in the implementation of openssh in OSX Yosemite (too small message buffers to accommodate the modern range of available cyphers - please see Redhat Bugzilla bug 1373835 for details). The workaround given there, to limit the cypher list by specifying it explicitly, as for instance

ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc -o MACs=hmac-md5,hmac-sha1 user@host

works for me.

Related Solutions

Changing Terminal colors when ssh-ing into remote machine and back

I'm using the following.

Have a shell command, called myssh, with content:

PROFILE="$1";shift;
DEF="Basic" #the default profile name
echo "tell app \"Terminal\" to set current settings of first window to settings set \"${PROFILE}\""|osascript
ssh $@
echo "tell app \"Terminal\" to set current settings of first window to settings set \"${DEF}\""|osascript

and use bash aliases for the connect, like:

alias ssweb='myssh Homebrew user@web.example.com'
alias ssmail='myssh Ocean me@mail.example.com'

When I want to ssh into the web server, I simply write ssweb in the Terminal and I got the "Homebrew" profile. When the ssh session ends, the AppleScript sets back to the "Basic".

The aliases should go into your $HOME/.profile or similar bash-startup file.

The "Homebrew", "Ocean" etc. are the setting profiles from the Terminal.app preferences. You can also set up different fonts, encodings, etc.

Of course, you can use it directly (without aliases) like:

myssh Pro user@another.machine.example.com
       ^        ^
       |        ssh command arguments
       terminal profile name

Keychain won’t remember the SSH password when connecting to server

There is a lot of conflicting information I've read whenever I look up information on using ssh-agent (passphrase saving/reusing process) under Mac OS X. Most resources seem to suggest that simply issuing ssh-add -K will let you store your passphrase, and will automatically configure OS X to launch ssh-agent automatically and load your stored passphrase.

Note: Running ssh-add -K will only work if you have your private key file in one of the common locations, those locations being limited to: ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/identity. If the file is located anywhere else you should specify that path after the -K in the command above.

The reason you are getting the key file passphrase dialog when connecting to the second (key-less) server is likely because the default configuration of SSH servers is to use public key authentication first, and 'keyboard interactive' authentication second.

Because you have a public key with a standard name/location (~/.ssh/id_rsa), your OpenSSH client helpfully submits the private key in order to allow the server to match it against an allowed authorized_keys file.

There are a small handful of ways to prevent this, the easiest two being to pass a flag on the command line, or add it as a permanent configuration item in your ~/.ssh/config file.

When connecting to the secondary/key-less server, you can add -o "PubkeyAuthentication=no" when connecting. Something like ssh -o "PubkeyAuthentication=no" me@devserver2.
Open up ~/.ssh/config in your favorite text editor, create it first if you must, and enter the following:
```
Host devserver2  
    User me  
    PubkeyAuthentication no
```

Now, if you simply type ssh devserver2 the username and pubkey configuration will be read in and used, and you should be prompted for your password and nothing else.

(Note: Replace devserver2 with the actual hostname of the server. Alternatively, pick a nice hostname, such as devserver2, and add a property between User and PubkeyAuthentication called 'Hostname' and put the name or IP address of the server there. Afterwards, you actually can simply type 'ssh devserver2' and all the configuration properties will work their respective magic.)

Best Answer

Related Solutions

Changing Terminal colors when ssh-ing into remote machine and back

Keychain won’t remember the SSH password when connecting to server

Related Question