| View previous topic :: View next topic |
| Author |
Message |
KarlisRepsons
Apprentice
Joined: 03 Nov 2008
Posts: 229
Location: Latvia
|
 Posted: Wed Jan 21, 2009 11:02 am Post subject: ssh-only login accounts? |
 |
|
Is there some good way to make a user able to login only via ssh, not locally?
Currently I have to set up a random local password and found out, passwd is not going to take stdin as an argument, which forbids a decent automation... |
|
| Back to top |
|
 |
TNorthover
Guru
Joined: 25 Jan 2004
Posts: 434
Location: Edinburgh, UK
|
| Posted: Wed Jan 21, 2009 11:12 am Post subject: |
|
|
Don't you just set the password field in /etc/shadow to a single *? That disallows local logins. I think ssh should still work if you use the id certificates method, but I've never tried it.
Edit: The -l option of passwd seems to do this. Might be safer than a cobbled script. |
|
| Back to top |
|
|
KarlisRepsons
Apprentice
Joined: 03 Nov 2008
Posts: 229
Location: Latvia
|
| Posted: Wed Jan 21, 2009 11:16 am Post subject: |
|
|
Is there some way to include it in useradd options or call some command for that later?
By the way, what is this doing:
usermod -p "encrypted-password" username
? |
|
| Back to top |
|
|
TNorthover
Guru
Joined: 25 Jan 2004
Posts: 434
Location: Edinburgh, UK
|
| Posted: Wed Jan 21, 2009 11:22 am Post subject: |
|
|
| KarlisRepsons wrote: | | Is there some way to include it in useradd options or call some command for that later? |
Looks like it's the default in useradd if no password is specified. And "passwd -l" does it manually (as I edited).
| Quote: | | usermod -p "encrypted-password" username? |
"man usermod" will tell you a fair bit. Basically there's a particular way to "encrypt" passwords that used to be used in unix. usermod allows you to specify the password in that form. It's largely been superceded now (the algorithm has dubious security), so I'd avoid that. |
|
| Back to top |
|
|
KarlisRepsons
Apprentice
Joined: 03 Nov 2008
Posts: 229
Location: Latvia
|
| Posted: Wed Jan 21, 2009 12:31 pm Post subject: |
|
|
> Looks like it's the default in useradd if no password is specified.
Then it doesn't work: I had to set some password just to allow login... |
|
| Back to top |
|
|
TNorthover
Guru
Joined: 25 Jan 2004
Posts: 434
Location: Edinburgh, UK
|
| Posted: Wed Jan 21, 2009 12:41 pm Post subject: |
|
|
| KarlisRepsons wrote: | > Looks like it's the default in useradd if no password is specified.
Then it doesn't work: I had to set some password just to allow login... |
So you've got a user with no password, and put an ssh public key in the appropriate area of his home directory (~/.ssh/authorized_keys) but he can't login? That's odd, because it works for me.
The output of "ssh -v wherever" could well be useful (you may want to sanitise it first in case there's data you don't want leaking). |
|
| Back to top |
|
|
KarlisRepsons
Apprentice
Joined: 03 Nov 2008
Posts: 229
Location: Latvia
|
| Posted: Wed Jan 21, 2009 1:05 pm Post subject: |
|
|
Looks like my useradd is putting ! by default. If put "*", it is possible to login through ssh.
BUT: how can I be sure, that '*' is not interpreted as encrypted single character password, so its NOT possible to hit with not so many tries? (still I don't want to try and consider it "verified") |
|
| Back to top |
|
|
think4urs11
Bodhisattva
Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud
|
| Posted: Wed Jan 21, 2009 10:06 pm Post subject: |
|
|
| KarlisRepsons wrote: | | BUT: how can I be sure, that '*' is not interpreted as encrypted single character password, so its NOT possible to hit with not so many tries? |
Simply because '*' is not a valid character for the hashed password, means no password will ever be hashed to '*whatever' thus no password can match the hash in /etc/shadow.
| man 5 shadow wrote: | | The encrypted password consists of 13 to 24 characters from the 64 character alphabet a thru z, A thru Z, 0 thru 9, \. and /. Optionally it can start with a "$" character. This means the encrypted password was generated using another (not DES) algorithm |
.
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
| Back to top |
|
|
TNorthover
Guru
Joined: 25 Jan 2004
Posts: 434
Location: Edinburgh, UK
|
| Posted: Wed Jan 21, 2009 10:25 pm Post subject: |
|
|
| Think4UrS11 wrote: | | Simply because '*' is not a valid character for the hashed password, means no password will ever be hashed to '*whatever' thus no password can match the hash in /etc/shadow. |
True but that doesn't explain the distinction he's seeing between "!" and "*" being in that field. I didn't notice anything in the manpage about that when I looked. |
|
| Back to top |
|
|
think4urs11
Bodhisattva
Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud
|
| Posted: Wed Jan 21, 2009 11:50 pm Post subject: |
|
|
'!' is not mentioned as valid character as well
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
| Back to top |
|
|
KarlisRepsons
Apprentice
Joined: 03 Nov 2008
Posts: 229
Location: Latvia
|
| Posted: Thu Jan 22, 2009 8:51 am Post subject: |
|
|
| Think4UrS11 wrote: | | Simply because '*' is not a valid character for the hashed password, means no password will ever be hashed to '*whatever' thus no password can match the hash in /etc/shadow. |
It is strictly speaking not a proof, there is no password matching to what turns out when '*' is tried to decrypt and compare.
Well, but there is this in manual:
| man 5 shadow wrote: | If the password field contains some string that is not valid result of
crypt(3), for instance ! or *, the user will not be able to use a unix
password to log in, subject to pam(7). |
I could not find the difference between "!" and "*" in pam(7) as I have no such manual at all. |
|
| Back to top |
|
|
desultory
Bodhisattva
Joined: 04 Nov 2005
Posts: 9410
|
| Posted: Fri Jan 23, 2009 7:39 am Post subject: |
|
|
| Moved from Off the Wall to Networking & Security. |
|
| Back to top |
|
|
|
Networking & Security
