On Saturday 2015-01-10 01:41, Linda Walsh wrote:
xm and machinectl are used on the host. The securetty issue occurs in the guest.
---- So in a non-vm setup with securetty being used to monitor specify TTY's available for remote login from a client, there is no 'guest', so how would you manage things in a "remote", non-vm setup, wouldn't the pam module still apply (more than one person has noticed the drop in remote compatibility in more recent versions 12.x+ of OSuse, perhaps using 'vm's, predominantly or solely for testing is related to that? Just a thought...
Nah, the presence/absence of a VM does not change the issue. I pondered a bit, and conclude: * /etc/pam.d/remote tells us the file is used by `/bin/login -h`. rsh, being a remote login capability, should invoke that. * Given login(8) apparently uses two distinct PAM service configuration files, /etc/pam.d/login is now purely for LOCAL logins. * In the distribution, we defined local logins to be always secure. Therefore, pam_securetty.so's presence in /etc/pam.d/login is a bug.
I see it used in /etc/pam.d/remote as well as /etc/pam.d/rlogin.
rlogin is clear, but what progs use 'remote'?
Ever bothered to look at the file?
Nope -- doesn't exist:
which remote -bash: type: remote: not found
LOOK AT THE FILE, /etc/pam.d/remote.
Sorry, but I have all the same programs and features available using 'rlogin' on a 'closed-network', as using ssh. If you find DOS to provide the exact same features at 3-5x the speed, I suggest you reconsider it.
When CPU is the bottleneck for network activity in a closed network, that hints to file copying. For which I would consider using rsync:// transport (it is unencrypted) rather than rcp. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org